[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

Fri May 26 15:47:15 EDT 2017

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, hostmaster at uneedus.com 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 <jschiller at google.com> 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, <hostmaster at uneedus.com
> >> <javascript:_e(%7B%7D,'cvml','hostmaster at uneedus.com');>> 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 <info at arin.net
> >>>> <javascript:_e(%7B%7D,'cvml','info at arin.net');>> 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 ................ herrin at dirtside.com
> >>>> <javascript:_e(%7B%7D,'cvml','herrin at dirtside.com');>  bill at herrin.us
> >>>> <javascript:_e(%7B%7D,'cvml','bill at herrin.us');>
> >>>> Dirtside Systems ......... Web: <http://www.dirtside.com/>
> >>>>
> >>>> _______________________________________________
> >>> PPML
> >>> You are receiving this message because you are subscribed to
> >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
> >>> <javascript:_e(%7B%7D,'cvml','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
> >>> <javascript:_e(%7B%7D,'cvml','info at arin.net');> if you experience any
> >>> issues.
> >>>
> >>
> >>
> >>
> >> --
> >> _______________________________________________________
> >> Jason Schiller|NetOps|jschiller at google.com
> >> <javascript:_e(%7B%7D,'cvml','jschiller at google.com');>|571-266-0006
> >>
> >>
> >
> _______________________________________________
> 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.

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling