First of all, ALL changes to v4 have been withdrawn from this proposal.
This proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or
more) and this is unequal with v4 that has an 8 or more address standard
for SWIP.
I think that drawing the SWIP boundary for IPv6 based upon residential/non
residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would
treat v6 and v4 differently. Currently in v4, it is 8 or more addresses.
Residential or Non Residential does not change the SWIP requirement in
IPv4 in any way.
Thus, whatever boundary is chosen for v6, I think it should be a fixed
value, just like in IPv4. I would like to hear the exact reasons why it
has been proposed that there should be a residential/non residential
difference in SWIP policy, and what this difference in policy is meant to
address. If it is a valid reason, this should carry over to IPv4.
Some commenters have suggested that routeability should be a factor in
determining if SWIP is needed. In IPv4, it is not possible to route
anything smaller than a /24, but the current SWIP v4 standard is /29 or
more, much smaller than the routability standard. In IPv6, nothing
smaller than a /48 is routable, so I kinda think that IPv4 /29 is very
close to equal to IPv6 more than a /56, and also not independently
routable.
The comments I have been watching have strongly supported setting the SWIP
level for IPv6 at more than a /56. This is only one nibble away from /60
in the current proposal. I also note that it seems quite universal that
most commenters think that a /64 is wrong, and everyone, even dynamic
residential customers deserve to have at least a /60 so that they can
route packets in v6.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Tue, 11 Jul 2017, Owen DeLong wrote:
On May 30, 2017, at 06:41 , William Herrin <[email protected]> wrote:
On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <[email protected]
<mailto:[email protected]>> wrote:
Hello all,
I am avidly following this discussion and based on my daily observances (daily
swips /subnets ), I would say Andy is closest to being practical.
Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT
DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total
chaos.
With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56
OR LARGER NETWORK assignment be swiped.
That would still leave /60 to /64 assignments as minimum assignment or for
dynamic usage for either residential or other usage.
Howdy,
I don't like putting the SWIP requirement at /56 or larger because I think that
would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read
seem to have a pretty strong consensus that the minimum assignment to an end
user should be either /48 or /56. Setting ARIN policy that encourages
assignments smaller than -both- of these numbers would be a bad idea IMHO.
This is one of those rare occasions when I absolutely agree with Bill. If
we???re going to do this, I would support a requirement as follows:
1. For customers fitting the definition in NRPM 2.13, /47 or
shorter.
2. For customers not fitting the definition in NRPM 2.13 /63 or
shorter.
Again I remind everyone that a /64 assignment to an end user, even for dynamic
or residential use, is absolutely positively 100% wrong. Doing so prevents the
end user from configuring their local lans as IPv6 is designed. They need at
least a /60 for that. If you are assigning /64's to end users, you are doing it
wrong.
Yes??? The only place I can imagine assigning /64s to customers as a legitimate
practice is for single-LAN datacenter installations where the customer has no
router.
If the customer might have a router, a /48 is the best and safest default
choice and shorter should be possible with reasonable justification.
Owen
_______________________________________________
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.
