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 , [email protected] 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. OwenAlbert 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 <[email protected]> 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 theform 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 MountainSpotted IPv6 community network has a part of the network that is managed bya 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:[email protected] 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 ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
