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

[Matthew Petach]

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".

>  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?

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>?

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.

>  Timetable for implementation: Immediate.

Matt