<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Linux (Fedora 25) and MacOS (Sierra) at least, it’s still using stable addresses based on MAC address.<div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 19, 2017, at 4:28 PM, David Farmer <<a href="mailto:farmer@umn.edu" class="">farmer@umn.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class=""><a href="https://tools.ietf.org/html/rfc8064" class="">https://tools.ietf.org/html/rfc8064</a><br class=""></div><div class=""><a href="https://tools.ietf.org/html/rfc7217" class="">https://tools.ietf.org/html/rfc7217</a><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong <span dir="ltr" class=""><<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 19, 2017, at 1:28 PM, Leif Sawyer <<a href="mailto:lsawyer@gci.com" target="_blank" class="">lsawyer@gci.com</a>> wrote:</div><br class="m_-3607967379300358636Apple-interchange-newline"><div class=""><div class="m_-3607967379300358636WordSection1" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="">The majority of devices no longer register on SLAAC with MAC-bound addresses.</span></div></div></div></blockquote><div class=""><br class=""></div>Technically, this isn’t true.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt" class=""> </span><br class=""><blockquote type="cite" class=""><div class="m_-3607967379300358636WordSection1" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="">Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, which is codified in RFC 4941<u class=""></u><u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="">means randomly generated addresses on a rotating basis.<u class=""></u><u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""><u class=""></u> <u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="">You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's really not.<u class=""></u><u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""></span></div></div></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><blockquote type="cite" class=""><div class="m_-3607967379300358636WordSection1" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""><u class=""></u> <u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="">Leif<u class=""></u><u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""><u class=""></u> <u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""><u class=""></u> <u class=""></u></span></div><div class=""><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in" class=""><div style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:'Times New Roman',serif" class=""><b class=""><span style="font-size:10pt;font-family:Tahoma,sans-serif" class="">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif" class=""><span class="m_-3607967379300358636Apple-converted-space"> </span>ARIN-PPML [<a href="mailto:arin-ppml-bounces@arin.net" style="color:purple;text-decoration:underline" target="_blank" class="">mailto:arin-ppml-bounces@<wbr class="">arin.net</a>]<span class="m_-3607967379300358636Apple-converted-space"> </span><b class="">On Behalf Of<span class="m_-3607967379300358636Apple-converted-space"> </span></b><a href="mailto:hostmaster@uneedus.com" style="color:purple;text-decoration:underline" target="_blank" class="">hostmaster@uneedus.com</a><br class=""><b class="">Sent:</b><span class="m_-3607967379300358636Apple-converted-space"> </span>Tuesday, September 19, 2017 3:25 AM<br class=""><b class="">To:</b><span class="m_-3607967379300358636Apple-converted-space"> </span><a href="mailto:arin-ppml@arin.net" style="color:purple;text-decoration:underline" target="_blank" class="">arin-ppml@arin.net</a><br class=""><b class="">Subject:</b><span class="m_-3607967379300358636Apple-converted-space"> </span>Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements<u class=""></u><u class=""></u></span></div></div></div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:'Times New Roman',serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="color:red" class="">[External Email]</span><span class="m_-3607967379300358636Apple-converted-space"> </span><br class=""><br class="">Placing ISP/LIR in place of ISP might be the best way to avoid confusion.<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">As has been pointed out, they are really one and the same.<br class=""><br class="">Otherwise, I think that everything else about the draft is good and<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">support.<br class=""><br class="">One thing to consider for future discussion is that because of the nature<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">of IPv6, and its end-to-end nature, and assignment of public addresses,<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">that the difference between allocate and assign using IPv6 on a specific<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">/64 segment used for public wifi or otherwise is becoming more fluid.<br class=""><br class="">With SLAAC, an address is formed in part using a MAC address, which<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">according to the rules for MAC addresses is supposed to be unique. It<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">could be argued that these addresses are in effect "static", which could<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">be argued is an assignment of part of the host network's /64, in effect a<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">static /128 of that network. Due to the rules of SLAAC this happens<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">without involvement of the host network, other than router advertisements,<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">since the MAC originates from the guest device, as a different device will<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">have a different MAC address.<br class=""><br class="">The requirement of at least a /64 in the proposed 6.5.5.4 is good in that<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">end user networks that have SLAAC cannot be required to register the /128<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">associated with someones MAC address on their request. Since this limit<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">is in the proposal, I think we do not need to address the fact that end<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">user networks running IPv6 and SLAAC in effect are assigning addresses to<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">end user devices, even though they are not supposed to do this unless the<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has<span class="m_-3607967379300358636Apple-converted-space"> </span><br class="">a time limit, one could argue that SLAAC addresses are static.<br class=""><br class="">Something to think about.<br class=""><br class="">Albert Erdmann<br class="">Network Administrator<br class="">Paradise On Line Inc.<br class=""><br class="">On Mon, 18 Sep 2017, Owen DeLong wrote:<br class=""><br class="">> I refer you to section 6.5.1…<br class="">><br class="">> 6.5.1. Terminology<br class="">><br class="">> The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.<br class="">> 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.)<br class="">><br class="">> 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.<br class="">><br class="">> Owen<br class="">><br class="">>> On Sep 18, 2017, at 1:14 PM, John Santos <<a href="mailto:JOHN@egh.com" style="color:purple;text-decoration:underline" target="_blank" class="">JOHN@egh.com</a>> wrote:<br class="">>><br class="">>><br class="">>><br class="">>> On 9/18/2017 10:37 AM, ARIN wrote:<br class="">>>> The following has been revised:<br class="">>>><br class="">>>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements<br class="">>> [snip]<br class="">>><br class="">>>> 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."<br class="">>><br class="">>> 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?<br class="">>><br class="">>><br class="">>> [snip]<br class="">>><br class="">>> --<br class="">>> John Santos<br class="">>> Evans Griffiths & Hart, Inc.<br class="">>> <a href="tel:(781)%20861-0670" value="+17818610670" target="_blank" class="">781-861-0670 ext 539</a><br class="">>><br class="">>> ______________________________<wbr class="">_________________<br class="">>> PPML<br class="">>> You are receiving this message because you are subscribed to<br class="">>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" style="color:purple;text-decoration:underline" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">>> Unsubscribe or manage your mailing list subscription at:<br class="">>><span class="m_-3607967379300358636Apple-converted-space"> </span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" style="color:purple;text-decoration:underline" target="_blank" class="">http://lists.arin.net/<wbr class="">mailman/listinfo/arin-ppml</a><br class="">>> Please contact<span class="m_-3607967379300358636Apple-converted-space"> </span><a href="mailto:info@arin.net" style="color:purple;text-decoration:underline" target="_blank" class="">info@arin.net</a><span class="m_-3607967379300358636Apple-converted-space"> </span>if you experience any issues.<br class="">><br class="">><span class="m_-3607967379300358636Apple-converted-space"> </span><u class=""></u><u class=""></u></div></div><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">______________________________<wbr class="">_________________</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">PPML</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">You are receiving this message because you are subscribed to</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Unsubscribe or manage your mailing list subscription at:</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a></span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.</span></blockquote></div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">
PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" class="">info@arin.net</a> if you experience any issues.<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature">===============================================<br class="">David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" class="">Email:farmer@umn.edu</a><br class="">Networking & Telecommunication Services<br class="">Office of Information Technology<br class="">University of Minnesota <br class="">2218 University Ave SE Phone: 612-626-0815<br class="">Minneapolis, MN 55414-3029 Cell: 612-812-9952<br class="">=============================================== </div>
</div></div>
</div></blockquote></div><br class=""></div></body></html>