[arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

[hostmaster at uneedus.com]

---------- Forwarded message ---------- Date: Wed, 17 Jan 2018 07:31:05 
As for the disease reference, I assume the networks are not real, and only 
for the purposes of this discussion.

There are good technical reasons for the example networks to share address 
space, if they are not multihomed and share an upstream.  The routing 
tables and hardware are often simpler for more non technical volunteers to 
set up and maintain. Often the network upstream points are chosen to be 
points within the territory where the upstream connections are available, 
often in/near a nearby town, and may be the location of a home or business 
of one or more members of the Community network.

Every Community network should have the option to use its own backbone, or 
link up with another community network that can provide access to a 
backbone and numbering resources, especially if is highly remote.  Policy 
should not put a roadblock in the way of doing this.

I would guess such arrangements might happen because the larger community 
network does not provide access to more remote locations, and another 
group gets together to link one or more of the served sites of the larger 
network with the remaining locations which are unserved, effectively 
extending the reach of the larger network to the more remote points.

While the goal of a /48 for each end user site is a good goal, network 
operators are free to make a different choice if that meets their needs. 
Do be aware that the larger network may not even be aware of the extension 
of their network to additional users.  Ball Mountain might be a group of 
people living on the other side of the mountain from Rocky Mountain 
Spotted IPv6 Community Network who are blocked from direct connection. 
To get around this problem, they may recruit one of the Rocky Mountain 
members that are line of sight to both Rocky Mountain, and the Ball 
Mountain to set up a "backbone" there.  At some future date, another 
community network may become available, or a commercial circuit becomes 
available at one of the Ball Mountain sites, and they change the routing 
to match.  Since they are effectively sharing the /48 from the original 
Rocky Mountain user, this group might divide that /48 into individual 
/56's for each of the Ball Mountain users.

A good Community Network Policy should help people, especially in remote 
areas with many options to obtain Internet access.  Chaining connections 
via more than one such network should not be forbidden by ARIN policy.

Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Tue, 16 Jan 2018, Owen DeLong wrote:

> 
>> On Jan 16, 2018, at 16:41 , hostmaster at uneedus.com wrote:
>> 
>> I really never considered until this was brought up that community networks 
>> might want to band together to provide backbone connectivity or otherwise 
>> associate with each other.  I do not think the Community network provisions 
>> of policy should forbid this.
> 
> Agreed. It doesn’t. However, it does not (currently) lend itself to them 
> doing so with a single IPv6 aggregate prefix. Is there a need or desire to do 
> so?
> 
>> Based on the discussion around 2017-5, it appears that the most important 
>> thing for accountability is the registration of blocks routed differently or 
>> assigned to others, which in this example are other community networks for 
>> specific areas unless the Community Network holding the space manages abuse 
>> for the smaller Community Networks below it. Since the end users would have 
>> a /48 or less, there is no need to register the end users. under the adopted 
>> 2017-5, unless they have requested registration.
> 
> Really, once they get to the point of providing this level of service, I see 
> no reason (or advantage to them) of not being a regular LIR.
> 
>> In the example, Rocky Mountain Spotted IPv6 community network might apply 
>> for a /40 from ARIN for $250/year. It could do this, or obtain an allocation 
>> from Colorado IPv6 cooperative to use. Instead of operating this entire 
>> network itself, it might choose to allow other existing smaller groups to 
>> operate parts of the network such as the Ball Mountain community and Mount 
>> Lincoln. I have no heartburn with these delegations as long as they are 
>> SWIP'ed, so we know who is managing each segment of the overall network.
> 
> Sure, but you’ve now got 4 networks crammed into a /40 meaning that each 
> can be no bigger than a /42 and with rational allocation policy, no bigger 
> than a /44, ignoring the fact that one of the networks is named after a 
> disease.
> 
>> While some might argue that it is no big deal to become a full LIR and get 
>> more space, that space comes at a greater cost which may not be affordable. 
>> Many of these groups just manage the network, with the end users providing 
>> their own access nodes at their own expense, often using some sort of point 
>> to point wireless connectivity.  The amount of "cash" for things such as 
>> ARIN fees may in fact be quite limited.
> 
> You’re talking about a cooperative of 4 networks having to pay $500 instead 
> of a single network paying $250 (or $100) per year. Under older fee 
> structures, it was a significant hurdle. Under the current fee structure, 
> it’s a lot less of an issue.
> 
>> While it is not the "recommended" way to do it, some of these community 
>> networks may "find" more space for end users by assigning less than a /48 to 
>> most of its end users, assigning that smaller value by default, and only 
>> giving a /48 to end users upon a specific request.  This allows more users, 
>> without more cost for annual fees.
> 
> Here I have real heartburn. I really want to avoid writing policy that 
> provides any incentive to do this if at all possible. Part of ARIN’s 
> mission is to promote the development of the internet. Encouraging ISPs to 
> give out less than a /48 to end users is contrary to that mission IMHO.
> 
>> I therefore go along with the proposed rewrite of 6.5.9.3.  I do not see a 
>> valid reason to prevent community networks from banding together.
> 
> I don’t think we are preventing any such thing.
> 
> Owen
> 
>> 
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>> 
>> 
>> On Tue, 16 Jan 2018, David Farmer wrote:
>> 
>>> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <jschiller at google.com>
>>> wrote:
>>> 
>>>> I support the proposal with the exclusion of section 6.5.9.3.
>>>> I support the proposal with the inclusion of section 6.5.9.3.
>>>> I ask what is the purpose of section 6.5.9.3?
>>>> Is section 6.5.9.3 needed?
>>>> Is section 6.5.9.3 restricting the right thing?
>>>> 
>>>> Without section 6.5.9.3 the policy clearly defines a community network,
>>>> and allows what would otherwise be an LIR  getting a /32 (or /36 upon
>>>> request)
>>>> get instead a /40.
>>>> 
>>>> This would reduce there fees from X-small $1,000 annunally
>>>> (or upon request 2X-small $500 annually)
>>>> to 3X-small $250 annually.
>>>> 
>>>> Sounds well and good.
>>>> 
>>>> 
>>>> Section 6.5.9.3 adds a further restriction of there shall be no no
>>>> re-allocations,
>>>> suggesting they cannot have a user of their space which in turn has its
>>>> own users.
>>>> 
>>>> (for the record I think you can drop the text "to other organizations."
>>>> and just have "However, they shall not reallocate resources.")
>>>> 
>>>> 
>>>> What behavior are you intending to prevent?
>>>> 
>>> 
>>> Section 6.5.9.3 has two parts.
>>> 
>>> The first part says community networks are like other LIRs, they make
>>> reassignments to end-users and makes it abundantly clear that section 6.5.4
>>> and 6.5.5 apply to community networks. I don't want anyone arguing that
>>> those sections don't apply to community networks.
>>> 
>>> The second part is the restriction on making reallocations. This comes back
>>> to a couple of arguments; (A.) If community networks can make
>>> reallocations, then there is no difference between them and a regular
>>> ISP/LIR, and some participants in earlier discussions were adamant there
>>> needed to be a difference between community networks and regular ISPs/LIRs.
>>> (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some
>>> participants in that discussion were adamant that a /40 was too small of an
>>> allocation for an ISP, especially if that ISP was to make any
>>> reallocations.
>>> 
>>> Doesn't the definition already have the required limits on behavior in the
>>>> form of:
>>>> 
>>>> "A community network is deployed, operated, and governed by its users,
>>>> for the purpose of providing free or low-cost connectivity to the
>>>> community it services."
>>>> 
>>>> It appears what you are preventing are the cases below.  I ask is this
>>>> what you
>>>> intend to prevent?  and if so why?
>>>> 
>>>> Should the Colorado IPv6 cooperative be prevented from providing transit
>>>> to the
>>>> Rocky Mountain Spotted IPv6 community network because they in turn assign
>>>> IPv6 addresses to community members?
>>>> 
>>>> 
>>>> What if this is all within one community network?  What if the Rocky
>>>> Mountain
>>>> Spotted IPv6 community network has a part of the network that is managed 
>>>> by
>>>> a group in Ball Mountain community and another part is managed by a group
>>>> in
>>>> Mount Lincoln.  Wouldn't it make sense to re-allocate some of the Rocky
>>>> Mountain
>>>> Spotted IPv6 community network's /40 to Ball Mountain community and let
>>>> them
>>>> handle the assignments to users in their locale?
>>>> 
>>> 
>>> Personly, I'd be fine with removing the restriction on community networks
>>> making reallocations, but I'd still want to have section 6.5.9.3 I'd
>>> rewrite is as follows;
>>> 
>>> *6.5.9.3. Reassignments by Community Networks*
>>> 
>>> *Similar to other LIRs, Community Networks shall make reassignments and
>>> reallocations in accordance with applicable policies, in particular, but
>>> not limited to sections 6.5.4 and 6.5.5. *
>>> 
>>> What do others think should community networks be allowed to make
>>> both reassignments and reallocations, or just reassignments?
>>> 
>>> Thanks.
>>> 
>>> --
>>> ===============================================
>>> David Farmer               Email:farmer at umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE        Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>