Linux (Fedora 25) and MacOS (Sierra) at least, it’s still using stable addresses based on MAC address.
Owen > On Sep 19, 2017, at 4:28 PM, David Farmer <[email protected]> wrote: > > I don't know if its a majority of devices yet, but with RFC8064 the use of > IIDs based on MAC addresses are no longer recommended, and stable addresses > are recommended to be generated on based on RFC7217. > > https://tools.ietf.org/html/rfc8064 <https://tools.ietf.org/html/rfc8064> > https://tools.ietf.org/html/rfc7217 <https://tools.ietf.org/html/rfc7217> > > Now it will take a while for new code to completely permeate the industry, > but I believe the latest updated for Windows, MAC OS, iOS, and Android, all > use this new standard. I have anecdotal evidence, by playing with my iPhone > that was just upgraded to iOS11 that it support this standard. I don't > remember if this was a feature added iOS 10.X or not. > > I believe it is safe to say the majority of new devices no longer use an IID > based on a MAC address. Other than the MAC address of the interface is one > of the seeds into the pseudo-random algorithm. > > Thanks > > On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong <[email protected] > <mailto:[email protected]>> wrote: > >> On Sep 19, 2017, at 1:28 PM, Leif Sawyer <[email protected] >> <mailto:[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 <tel:(781)%20861-0670> >> >> >> >> _______________________________________________ >> >> 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] >> <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] > <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. > > > > -- > =============================================== > David Farmer Email:[email protected] > <mailto:email%[email protected]> > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > ===============================================
_______________________________________________ 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.
