> On Sep 19, 2017, at 1:28 PM, Leif Sawyer <[email protected]> wrote: > > The majority of devices no longer register on SLAAC with MAC-bound addresses.
Technically, this isn’t true. The majority of devices now register both one or more privacy addresses _AND_ a MAC-bound address. The MAC-bound address on such devices is not used as a preferred or primary address for originating sessions, but can be used (if known by the remote device) as a stable address to connect to services provided by the host. > Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, which is > codified in RFC 4941 > means randomly generated addresses on a rotating basis. > > You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's > really not. I think the better consideration is that when we talk of allocation and/or assignment, we are talking of the allocation/assignment of network numbers end not of host-portions to end devices. As such, I don’t think that the blurring Albert perceives as being created by SLAAC truly exists regardless of whether it is static or not. Owen > > Leif > > > From: ARIN-PPML [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of [email protected] > <mailto:[email protected]> > Sent: Tuesday, September 19, 2017 3:25 AM > To: [email protected] <mailto:[email protected]> > Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements > > [External Email] > > Placing ISP/LIR in place of ISP might be the best way to avoid confusion. > As has been pointed out, they are really one and the same. > > Otherwise, I think that everything else about the draft is good and > support. > > One thing to consider for future discussion is that because of the nature > of IPv6, and its end-to-end nature, and assignment of public addresses, > that the difference between allocate and assign using IPv6 on a specific > /64 segment used for public wifi or otherwise is becoming more fluid. > > With SLAAC, an address is formed in part using a MAC address, which > according to the rules for MAC addresses is supposed to be unique. It > could be argued that these addresses are in effect "static", which could > be argued is an assignment of part of the host network's /64, in effect a > static /128 of that network. Due to the rules of SLAAC this happens > without involvement of the host network, other than router advertisements, > since the MAC originates from the guest device, as a different device will > have a different MAC address. > > The requirement of at least a /64 in the proposed 6.5.5.4 is good in that > end user networks that have SLAAC cannot be required to register the /128 > associated with someones MAC address on their request. Since this limit > is in the proposal, I think we do not need to address the fact that end > user networks running IPv6 and SLAAC in effect are assigning addresses to > end user devices, even though they are not supposed to do this unless the > addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has > a time limit, one could argue that SLAAC addresses are static. > > Something to think about. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Mon, 18 Sep 2017, Owen DeLong wrote: > > > I refer you to section 6.5.1… > > > > 6.5.1. Terminology > > > > The terms ISP and LIR are used interchangeably in this document and any use > > of either term shall be construed to include both meanings. > > The term nibble boundary shall mean a network mask which aligns on a 4-bit > > boundary (in slash notation, /n, where n is evenly divisible by 4, allowing > > unit quantities of X such that 2^n=X where n is evenly divisible by 4, such > > as 16, 256, 4096, etc.) > > > > While it is a little unusual to have definitions outside of section 2, > > these were placed here in section 6.5.1 in order to avoid potential > > conflicts with certain language that was in section 4 at the time of > > writing. > > > > Owen > > > >> On Sep 18, 2017, at 1:14 PM, John Santos <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> > >> > >> On 9/18/2017 10:37 AM, ARIN wrote: > >>> The following has been revised: > >>> > >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > >> [snip] > >> > >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the > >>> NRPM, to read: "If the downstream recipient of a static assignment of /64 > >>> or more addresses requests publishing of that assignment in ARIN's > >>> registration database, the ISP should register that assignment as > >>> described in section 6.5.5.1." > >> > >> I have been under the impression that a common goal of most people > >> proposing NRPM changes is to eliminate the use of the term "ISP", since it > >> is not defined in the policy and most or all the relevant sections also > >> apply to other organizations that, while they re-allocate or reassign > >> address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" > >> or "provider" or some other more generic term? > >> > >> > >> [snip] > >> > >> -- > >> John Santos > >> Evans Griffiths & Hart, Inc. > >> 781-861-0670 ext 539 > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List ([email protected] > >> <mailto:[email protected]>). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> <http://lists.arin.net/mailman/listinfo/arin-ppml> > >> Please contact [email protected] <mailto:[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.
_______________________________________________ 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.
