<div dir="ltr"><div>I'm still not convinced /64 isn't a waste. For instance, in multitenant environments, it would be beneficial (in some implementations) to reserve subnet bits to code for QoS, and be able to write access lists that will hit TCAM.<br><br></div>Paul Wilkins<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 January 2015 at 15:56, Paul Wilkins <span dir="ltr"><<a href="mailto:paulwilkins369@gmail.com" target="_blank">paulwilkins369@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Mark,<br></div>Thanks for posting this.<span class="HOEnZb"><font color="#888888"><br><br>Paul Wilkins<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 15 January 2015 at 15:43, Mark ZZZ Smith <span dir="ltr"><<a href="mailto:markzzzsmith@yahoo.com.au" target="_blank">markzzzsmith@yahoo.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
New IPv6 RFC just published that people might be interested in - it explains why IPv6 Interface Identifiers (i.e., the lower 64 bits of the IPv6 address) are 64 bits (mainly, with only a few exceptions) and also discusses the issues there would be if they were changed in size or made variable in size.<br>
<br>
<br>
"The IPv6 unicast addressing format includes a separation between the<br>
prefix used to route packets to a subnet and the interface identifierused to specify a given interface connected to that subnet.<br>
Currently, the interface identifier is defined as 64 bits long for<br>
almost every case, leaving 64 bits for the subnet prefix.  This<br>
document describes the advantages of this fixed boundary and analyzes<br>
the issues that would be involved in treating it as a variable<br>
boundary."<br>
<br>
<a href="https://www.rfc-editor.org/info/rfc7421" target="_blank">https://www.rfc-editor.org/info/rfc7421</a><br>
<br>
<br>
(I was quite flattered when I was asked to be one of the final detailed reviewers of it before it was escalated out of the IETF 6man working group upon the path towards publication as an RFC.)<br>
<br>
Regards,<br>
Mark.<br>
<br>
<br>
<br>
----- Forwarded Message -----<br>
From: "<a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a>" <<a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a>><br>
To: <a href="mailto:ietf-announce@ietf.org" target="_blank">ietf-announce@ietf.org</a>; <a href="mailto:rfc-dist@rfc-editor.org" target="_blank">rfc-dist@rfc-editor.org</a><br>
Cc: <a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org</a>; <a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a><br>
Sent: Thursday, 15 January 2015, 9:43<br>
Subject: RFC 7421 on Analysis of the 64-bit Boundary in IPv6 Addressing<br>
<br>
<br>
A new Request for Comments is now available in online RFC libraries.<br>
<br>
<br>
        RFC 7421<br>
<br>
        Title:      Analysis of the 64-bit Boundary<br>
                    in IPv6 Addressing<br>
        Author:     B. Carpenter, Ed.,<br>
                    T. Chown, F. Gont,<br>
                    S. Jiang, A. Petrescu,<br>
                    A. Yourtchenko<br>
        Status:     Informational<br>
        Stream:     IETF<br>
        Date:       January 2015<br>
        Mailbox:    <a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</a>,<br>
                    <a href="mailto:tjc@ecs.soton.ac.uk" target="_blank">tjc@ecs.soton.ac.uk</a>,<br>
                    <a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>,<br>
                    <a href="mailto:jiangsheng@huawei.com" target="_blank">jiangsheng@huawei.com</a>,<br>
                    <a href="mailto:alexandru.petrescu@cea.fr" target="_blank">alexandru.petrescu@cea.fr</a>,<br>
                    <a href="mailto:ayourtch@cisco.com" target="_blank">ayourtch@cisco.com</a><br>
        Pages:      24<br>
        Characters: 60469<br>
        Updates/Obsoletes/SeeAlso:   None<br>
<br>
        I-D Tag:    draft-ietf-6man-why64-08.txt<br>
<br>
        URL:        <a href="https://www.rfc-editor.org/info/rfc7421" target="_blank">https://www.rfc-editor.org/info/rfc7421</a><br>
<br>
The IPv6 unicast addressing format includes a separation between the<br>
prefix used to route packets to a subnet and the interface identifier<br>
used to specify a given interface connected to that subnet.<br>
Currently, the interface identifier is defined as 64 bits long for<br>
almost every case, leaving 64 bits for the subnet prefix.  This<br>
document describes the advantages of this fixed boundary and analyzes<br>
the issues that would be involved in treating it as a variable<br>
boundary.<br>
<br>
This document is a product of the IPv6 Maintenance Working Group of the IETF.<br>
<br>
<br>
INFORMATIONAL: This memo provides information for the Internet community.<br>
It does not specify an Internet standard of any kind. Distribution of<br>
this memo is unlimited.<br>
<br>
This announcement is sent to the IETF-Announce and rfc-dist lists.<br>
To subscribe or unsubscribe, see<br>
  <a href="https://www.ietf.org/mailman/listinfo/ietf-announce" target="_blank">https://www.ietf.org/mailman/listinfo/ietf-announce</a><br>
  <a href="https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist" target="_blank">https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist</a><br>
<br>
For searching the RFC series, see <a href="https://www.rfc-editor.org/search" target="_blank">https://www.rfc-editor.org/search</a><br>
For downloading RFCs, see <a href="https://www.rfc-editor.org/rfc.html" target="_blank">https://www.rfc-editor.org/rfc.html</a><br>
<br>
Requests for special distribution should be addressed to either the<br>
author of the RFC in question, or to <a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a>.  Unless<br>
specifically noted otherwise on the RFC itself, all RFCs are for<br>
unlimited distribution.<br>
<br>
<br>
The RFC Editor Team<br>
Association Management Solutions, LLC<br>
<br>
<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org</a><br>
Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6" target="_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>