[AusNOG] Fw: RFC 7421 on Analysis of the 64-bit Boundary in IPv6 Addressing
Mark ZZZ Smith
markzzzsmith at yahoo.com.au
Fri Jan 16 12:41:02 EST 2015
________________________________
From: Paul Wilkins <paulwilkins369 at gmail.com>
To: "ausnog at ausnog.net" <ausnog at ausnog.net>
Sent: Friday, 16 January 2015, 11:03
Subject: Re: [AusNOG] Fw: RFC 7421 on Analysis of the 64-bit Boundary in IPv6 Addressing
>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.
So the official IPv6 QoS field - the traffic class field - is the first field after the 4 bit version field, which makes it faster/easier to look at than the IPv6 addressing fields. Even equipment with the 144 bit limited TCAMs mentioned that can't look at the complete IPv6 addressing fields would easily be able to look at the TC field.
I'd be interested to know more details of your use case regarding encoding QoS in addresses, and why that would be better than using the TC field.
Still, there is nothing to prevent you from encoding locally significant information in the IPv6 IID fields (or the subnet fields too), and in fact it is IPv6's 64 bit IIDs that give you so much more ability to do that compared to what you could do with with IPv4. RFC7136, "Significance of IPv6 Interface Identifiers" discusses and makes some clarifications on the significance (or not) of bits in IIDs.
If you're arguing that 64 bit IIDs are too big, and those bits should be used for something else, then really you're saying that those bits shouldn't be addressing bits at all and should be moved to another field e.g., you want a 16 bit TC field rather than an 8 bit one.
More addressing bits are better in a number of scenarios (which is fundamentally what this RFC is about) - subnets are always large enough, so no need to renumber or add secondary subnets to add more devices; addresses containing the results of hashes (e.g., CGAs), and resistance to address probing attacks if the addresses are sparsely allocated and unpredictable, as described in RFC7217, "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" and ID "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".
>Paul Wilkins
On 15 January 2015 at 15:56, Paul Wilkins <paulwilkins369 at gmail.com> wrote:
Mark,
>Thanks for posting this.
>
>Paul Wilkins
>
>
>
>On 15 January 2015 at 15:43, Mark ZZZ Smith <markzzzsmith at yahoo.com.au> wrote:
>
>Hi,
>>
>>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.
>>
>>
>>"The IPv6 unicast addressing format includes a separation between the
>>prefix used to route packets to a subnet and the interface identifierused to specify a given interface connected to that subnet.
>>Currently, the interface identifier is defined as 64 bits long for
>>almost every case, leaving 64 bits for the subnet prefix. This
>>document describes the advantages of this fixed boundary and analyzes
>>the issues that would be involved in treating it as a variable
>>boundary."
>>
>>https://www.rfc-editor.org/info/rfc7421
>>
>>
>>(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.)
>>
>>Regards,
>>Mark.
>>
>>
>>
>>----- Forwarded Message -----
>>From: "rfc-editor at rfc-editor.org" <rfc-editor at rfc-editor.org>
>>To: ietf-announce at ietf.org; rfc-dist at rfc-editor.org
>>Cc: ipv6 at ietf.org; rfc-editor at rfc-editor.org
>>Sent: Thursday, 15 January 2015, 9:43
>>Subject: RFC 7421 on Analysis of the 64-bit Boundary in IPv6 Addressing
>>
>>
>>A new Request for Comments is now available in online RFC libraries.
>>
>>
>> RFC 7421
>>
>> Title: Analysis of the 64-bit Boundary
>> in IPv6 Addressing
>> Author: B. Carpenter, Ed.,
>> T. Chown, F. Gont,
>> S. Jiang, A. Petrescu,
>> A. Yourtchenko
>> Status: Informational
>> Stream: IETF
>> Date: January 2015
>> Mailbox: brian.e.carpenter at gmail.com,
>> tjc at ecs.soton.ac.uk,
>> fgont at si6networks.com,
>> jiangsheng at huawei.com,
>> alexandru.petrescu at cea.fr,
>> ayourtch at cisco.com
>> Pages: 24
>> Characters: 60469
>> Updates/Obsoletes/SeeAlso: None
>>
>> I-D Tag: draft-ietf-6man-why64-08.txt
>>
>> URL: https://www.rfc-editor.org/info/rfc7421
>>
>>The IPv6 unicast addressing format includes a separation between the
>>prefix used to route packets to a subnet and the interface identifier
>>used to specify a given interface connected to that subnet.
>>Currently, the interface identifier is defined as 64 bits long for
>>almost every case, leaving 64 bits for the subnet prefix. This
>>document describes the advantages of this fixed boundary and analyzes
>>the issues that would be involved in treating it as a variable
>>boundary.
>>
>>This document is a product of the IPv6 Maintenance Working Group of the IETF.
>>
>>
>>INFORMATIONAL: This memo provides information for the Internet community.
>>It does not specify an Internet standard of any kind. Distribution of
>>this memo is unlimited.
>>
>>This announcement is sent to the IETF-Announce and rfc-dist lists.
>>To subscribe or unsubscribe, see
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>
>>For searching the RFC series, see https://www.rfc-editor.org/search
>>For downloading RFCs, see https://www.rfc-editor.org/rfc.html
>>
>>Requests for special distribution should be addressed to either the
>>author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless
>>specifically noted otherwise on the RFC itself, all RFCs are for
>>unlimited distribution.
>>
>>
>>The RFC Editor Team
>>Association Management Solutions, LLC
>>
>>
>>--------------------------------------------------------------------
>>IETF IPv6 working group mailing list
>>ipv6 at ietf.org
>>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>--------------------------------------------------------------------
>>_______________________________________________
>>AusNOG mailing list
>>AusNOG at lists.ausnog.net
>>http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
More information about the AusNOG
mailing list