[ppml] Policy Proposal 2008-3: Community Networks IPv6 Allocation

[Sascha Meinrath]

Hi Matthew,

Thanks for the feedback.  Some comments are below.

> Date: Mon, 17 Mar 2008 18:20:57 -0700
> From: "Matthew Petach" <mpetach at netflight.com>
> Subject: Re: [ppml] Policy Proposal 2008-3: Community Networks IPv6
> 	Allocation
> To: "Member Services" <info at arin.net>
> Cc: ppml at arin.net
> 
> On 3/4/08, Member Services <info at arin.net> wrote:
>> On 21 February 2008, the ARIN Advisory Council (AC) concluded its review
>>  of "Community Networks IPv6 Allocation" and accepted it as a formal
>>  policy proposal with the condition that the policy text be revised by
>>  the author so that it can be put into the ARIN Number Resource Policy
>>  Manual. The author submitted a revised version of the proposal.
> ...
>>  Policy Proposal 2008-3
>>  Community Networks IPv6 Allocation
>>  Author: Joshua King
>>  Proposal Version: 1
>>  Date: 4 March 2008
>>  Proposal type: new
>>  Policy term: permanent
>>  Policy statement:
>>
>>  [Add Section 2.8 to the NRPM.]
>>  2.8 Community Network
>>
>>  A community network is a generic reference to any network that is
>>  operated by a group of people living in a particular local area
>>  organized for the purposes of delivery or provision of network services
>>  to the residents of an incorporated or unincorporated regional
>>  municipality, city, town, village, rural municipality, township, county,
>>  district or other municipality or other such geographic space, however
>>  designated.
>>
>>  [Modify 6.5.8.1b as follows.]
>>
>>  b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
>>  policy currently in effect or be a Community Network as defined in
>>  Section 2.8.
>>
>>  Rationale:
>>
>>  There are currently a number of projects globally that aim to develop
>>  community network infrastructure and related technologies. These are
>>  usually coordinated by volunteer-run, grassroots organizations which
>>  lack many of the resources of traditional internet service providers and
>>  other network operators. They have diverse goals, including public
>>  policy, software development, and implementation of community services
>>  and resources. Many of them provide services free of charge, and thus
>>  lack any paying user base. However, in order to create and maintain
>>  community networks that are often composed of hundreds if not thousands
>>  of inexpensive, commodity hosts and devices, a significant amount of
>>  address space will be required. Current-generation workarounds to this
>>  problem, such as NAT, not only make it difficult to develop
>>  next-generation decentralized network technology by segmenting the
>>  community's architecture from the Internet as a whole, but will cease to
>>  be as viable a stopgap as the Internet moves towards IPv6 integration.
>>
>>  Even now, common community networking software solutions such as
>>  CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at)
>>  have nascent IPv6 addressing support, but participating organizations
>>  lack the address space for widespread testing or adoption. As such, it
>>  is necessary to implement an procedure as soon as possible for these
> 
> That should be "implement a procedure" rather than "an procedure".

Correct.

>>  segregated networks to acquire address space. These organizations do not
>>  meet the criteria traditionally defined for LIR's, and thus cannot
>>  acquire address allocations through existing templates. By establishing
>>  a procedure by which these organizations can seek to acquire the
>>  resources they require for further development, ARIN can reach out to
>>  this active community and establish a small but definite space for them
>>  in the future of Internet.
> 
> If they are "segregated networks", would they require globally routable
> addresses, or would non-routed space be adequate for them?

One of the (admittedly myriad) reasons for globally routable addresses is that 
these segregated networks are rapidly being interconnected to form larger and 
larger systems.  Two examples of this process include the COMMONS Project (see: 
http://www.caida.org/projects/commons) and the Intercity VPN Project (see: 
http://wiki.freifunk.net/IC-VPN).  Globally routable addresses would greatly 
facilitate interconnectivity since internal IP space can conflict.

> It would seem that if they are obtaining external connectivity from
> an upstream provider, it would be more appropriate for their upstream
> provider to provide space for them; if they're not going to obtain
> external connectivity, but really are going to remain a "segregated
> network", then would they really need to obtain a public
> allocation from ARIN, or could they simply make use of the
> FC00::/7 prefix for Unique Local IPv6 Address space (ULA)
> and the SixXS registry to track their ULA space per RFC 4193
> <http://tools.ietf.org/html/rfc4193>?

Community wireless networks (CWNs) are often both standalone _and_ 
interconnected (i.e., they function as large-scale geographically-based LANS and 
integrate with the larger Internet).  Furthermore, CWNs often receive bandwidth 
from several (sometimes numerous) different ISPs -- as multi-gateway support 
gets proofed out (it's already being trialed on several networks), this will 
certainly increase.  Because of this, reliance on ISP-allocated IPs won't work. 
  In addition, device-as-infrastructure networking technologies are rapidly 
being developed that will automatically bridge between ad-hoc and interconnected 
(with the CWN) modes.  In ad-hoc mode these devices need a way to automatically 
assign IPs (thus also the reason for unique IPs) -- one can't always assume 
external connectivity (or stable external connectivity).

> It seems like this issue has already been solved; I'm not
> understanding why a new policy is needed to differentiate
> community networks from any other type of networks.

I hope this helps address your feedback, but let me know.

--Sascha

>>  Timetable for implementation: Immediate.
> 
> Matt