[arin-ppml] Community Networks IPv6 Assignment (2008-3 update)
George, Wes E [NTK]
Wesley.E.George at sprint.com
Tue Aug 18 17:53:18 EDT 2009
Comments inline
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lea Roberts
Sent: Monday, August 17, 2009 4:21 PM
To: ppml at arin.net
Subject: [arin-ppml] Community Networks IPv6 Assignment (2008-3 update)
dear PPML community -
at the last meeting, ARIN XXIII, my perception was that the majority of
the opposition to Policy Proposal 2008-3 seemed to be a concern that the
inclusion of paid staff and a large budgetary number for network
operations could lead to its misuse as a "secret business plan" or other
abuse.
from the original definition, the text:
"the community network staff is at least 50% volunteer and that the annual
budget for community network activities is less than $250,000."
has been replaced with:
"the community network staff is 100% volunteers."
<snip>
I think that this perhaps swings too far the other way. We're now requiring that any org like this have essentially no paid staff, which is probably not realistic. Even non-profits pay a few people to keep the trains running on time and coordinate the volunteer efforts. However, I'm not overly worried about abuse. My problem with this proposal comes in the sections I've snipped out below. I still do not see a strong justification for PI space to be available for networks such as these.
I will restate here at the beginning that it is not expected for these
assignments to be globally routed, since that was also a concern.
<snip>
If the intent is to have these not be globally routed, why would ULA not suffice as a stable address assignment?
6.5.9.1 Qualification Criteria
To qualify for a direct assignment, a community network must
demonstrate it will immediately provide sustained service to at least
100 simultaneous users and must demonstrate a plan to provide
sustained service to at least 200 simultaneous users within one
year.
6.5.9.2. Initial assignment size
The minimum size of the assignment is /48.
<snip>
I'm having trouble with the rationale of allocating a /48 for 100-200 users. Since this is not going to be globally routed, the concerns about blowing up the routing table should not figure into the discussion, so why not allocate something more appropriate for this size of network, even a /64?
Rationale:
this policy was originally proposed by community network operators to
provide them with the ability to receive a direct assignment of IPv6
address resources from ARIN. the operators of such networks have
expressed their need to have a stable and globally unique address
assignment with which to number their network infrastructure. many
such networks are not able to meet the current criteria for a PI IPv6
assignment from ARIN. in an environment where connections to outside
networks may come and go, a stable internal address structure would be
very valuable. additionally, the ability to exchange routes with
others, whether locally or tunneled, and thereby have native IPv6
connectivity, would be quite beneficial.
<snip>
As to the globally unique requirement - if it's not globally routed, what would be the need for this? This proposal wouldn't cover the so-called Grey nets, which are large (mainly "black helicopter"/Gov't) networks that must be unique because they talk to each other but don't talk to the Internet, so I'm struggling to understand global uniqueness as a requirement. Yes, it would need to be unique among any interconnected networks, but I think that the likelihood of multiple community networks interconnected without some intermediary that would not be able to loosely organize the allocation of space to ensure uniqueness between the networks' gateways is pretty low. Alternatively, PA space could be used for the interconnection.
It would be extremely helpful for one or more of the operators of such networks to come forward with a presentation at ARIN explaining the specific problem that having PI space would solve for them that PA or ULA space would not, rather than simply being cited in this way. Case studies are very helpful for those of us who are skeptical as to the application of this policy.
there could also be a number of potential benefits to allowing
community network participants to begin using IPv6 addressing. some of
these networks have many technically capable and adventurous members
who would be motivated to begin developing and/or experimenting with
the software extensions which will be needed to support IPv6 prefix
selection among multiple IPv6 prefixes when establishing remote
connections. also, participants in networks receiving such assignments
will have the necessary global-ID to experiment with the various
proposals currently being developed for separating network locater
from network ID.
<snip>
This is more like a justification for a Class E style "experimental" address reservation in IPv6, but perhaps without the behavior of being utterly useless because it can't be configured on any standard router, host, or network element. ;-)
I'd support a reservation of this type if it was explicitly defined as not to be treated any differently than normal IPv6 addresses, but simply a special block for research and other limited uses, perhaps still allocated via ARIN with explicit requirements around experimentation as the justification to qualify. However, I don't think that it helps to justify community network allocations as "community networks" are defined within this proposal. I think that it would be possible to write a proposal/RFC reserving space for experimental use that could be broad enough to cover a number of possible community network uses, but I don't think that trying to justify it in the opposite direction is realistic.
Thanks,
Wes George
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
More information about the ARIN-PPML
mailing list