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.
