pardon top-post; on mobile the spec doesn't match operational reality, hence https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/
cheers, Joe On Fri, May 26, 2017 at 12:22:37AM -0400, [email protected] wrote: > RFC 4291, section 2.5.4 provide that the interface ID is /64 for all > global unicast addresses, which is the reason that all v6 lan networks are > set to /64, and this should include p2p links > > Network World at the time had quite a discussion about this and RFC 6164. > > They point out that we have no problems with waste when we use say 5000 > addreseses on a /64, but not with using 2 in a point to point link, > forgetting that the difference between 5000 and 2 is nothing when there is > 18 million trillion addresses on that subnet. > > It was also pointed out that using a /127 prevented certain attacks, but > simply turning off neighbor discovery (the true issue) on these links also > has the same effect. Maybe someone should update that RFC. I think the > advantages of /64 everywhere I think outweighs the value of using a /127 > p2p link. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Thu, 25 May 2017, Aaron Dudek wrote: > > > I don't believe a /64 is recommended for a p2p anymore. Rfc 6164 > > > > On Thursday, May 25, 2017, Jason Schiller <[email protected]> wrote: > > > >> I don't support a relaxation of SWIP requirements for IPv4. > >> > >> I do support updating the language for IPv4 for clarity (if that is > >> useful). > >> current IPv4 language: /29 or more > >> > >> possibly re-write for clarity: more than a /30. > >> > >> > >> As far as IPv6 goes, there are some who recommend a /64 for point-to-point. > >> One might argue that in the context of p-t-p an IPv4 /30 maps to a /64. > >> > >> I could certainly get behind SWIP requirements for "more than a /64" on > >> these grounds. > >> > >> Please make the requirement to SWIP be on a nibble boundary. > >> > >> > >> Nibbles being nice things, one could argue that end users are likely to > >> get a /64 > >> or the next size up which is a /60. If you want to catch all customers in > >> the > >> smallest size, you might make the boundary at "more than a /61" > >> > >> The next size up on the nibble boundary is a /56 putting the boundary at > >> "more than a /57" > >> > >> > >> Generally speaking any network that is sufficiently large to require > >> subnetting, > >> should have sufficient clue to support SWIP. Based on this reasoning > >> "more than > >> a /64" seems like an equable place to draw the line. Even "more than a > >> /61" > >> seems reasonable, as blocks are likely going to be assigned on nibbles. > >> My next preferred choice would be "more than a /57" > >> > >> Also don't forget that residential users can opt out of publicly providing > >> information. > >> > >> ___Jason > >> > >> > >> > >> > >> > >> > >> > >> On Tue, May 23, 2017 at 10:04 PM, <[email protected] > >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> > >>> Hello, > >>> > >>> The line has to be drawn somewhere, and the idea when I drafted this > >>> proposal was that it was wrong to treat IPv6 less favored than IPv6 as is > >>> the current case. It also bothered me that the average residential and > >>> small business account would have to go thru the SWIP process, just > >>> because > >>> they want to have a minimum or so assignment of IPv6 space for their > >>> network, when this was never a requirement for IPv4. As discussed, a /60 > >>> of v6 is much the same as a /32 of v4. > >>> > >>> I chose 16 addresses/networks as the only reasonable number to make the > >>> two protocols equal. As already discussed, 1 network is too small. If the > >>> community thinks it is wrong to relax the current IPv4 requirements, I am > >>> not opposed to removing 4.2.3.7.1 from the proposal, as long as the > >>> community is willing to do something about the "Register every network" > >>> problem that is the current policy in v6, and the changes to 6.5.5.1 that > >>> I > >>> propose. > >>> > >>> While I suggest that a /60 should not trigger registration, if the > >>> community would rather kick that up to a /56, I have no problem with this. > >>> This would seem to be the more future proof option. Of course such a > >>> change > >>> calls for a new title, maybe "New policy for IPv6 Assignment > >>> Registration", > >>> and cite it as allowing even the small networks with a /32 of IPv4 to > >>> obtain a reasonable assignment of IPv6 without registration requirements, > >>> as is the current case with IPv4. > >>> > >>> Albert Erdmann > >>> Network Administrator > >>> Paradise On Line Inc. > >>> > >>> > >>> > >>> On Tue, 23 May 2017, William Herrin wrote: > >>> > >>> On Tue, May 23, 2017 at 2:35 PM, ARIN <[email protected] > >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >>>> > >>>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration > >>>>> requirements between IPv4 and IPv6 > >>>>> > >>>>> Policy statement: > >>>>> > >>>>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change > >>>>> to > >>>>> "more than a /28". > >>>>> > >>>>> > >>>> Hello, > >>>> > >>>> In my opinion... > >>>> > >>>> Leave /29 alone or change it to "more than a single IP address." In these > >>>> days of IPv4 shortage, substantial networks sit behind small blocks of > >>>> public addresses. These networks should be documented with reachable POCs > >>>> lest the anti-spam/virus/malware folks slam down /24 filters for lack of > >>>> information about how misbehaving networks are partitioned. > >>>> > >>>> > >>>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to > >>>>> "more than a /60". > >>>>> > >>>>> > >>>> Change this to "more than a /56." Service providers should NOT be > >>>> assigning > >>>> /64's to end users. If you're doing that, you're doing it wrong. An IPv6 > >>>> customer should be able to have more than one /64 subnet without > >>>> resorting > >>>> to NAT so /60 should be the absolute minimum end-user assignment, > >>>> equivalent for all intents and purposes to an IPv4 /32. If we then want > >>>> "equivalence" to the /29 policy so that individuals with the minimum and > >>>> near-minimum assignment do not need to be SWIPed, it makes sense to move > >>>> the next subnetting level up. In IPv6, assignment is strongly recommended > >>>> on nibble boundaries, so that means /56. > >>>> > >>>> Regards, > >>>> Bill Herrin > >>>> > >>>> -- > >>>> William Herrin ................ [email protected] > >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> [email protected] > >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> > >>>> Dirtside Systems ......... Web: <http://www.dirtside.com/> > >>>> > >>>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to > >>> the ARIN Public Policy Mailing List ([email protected] > >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact [email protected] > >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> if you experience any > >>> issues. > >>> > >> > >> > >> > >> -- > >> _______________________________________________________ > >> Jason Schiller|NetOps|[email protected] > >> <javascript:_e(%7B%7D,'cvml','[email protected]');>|571-266-0006 > >> > >> > > > _______________________________________________ > 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. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ 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.
