ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

2017-02-17 14:20:21
On Feb 16, 2017, at 14:21, james woodyatt <jhw(_at_)google(_dot_)com> wrote:
[…]
The challenge is to find text that enforces the 64-bit boundary policy 
(ignoring the technical arguments for a moment), and at the same time 
ensures implementors do the right thing and make their code handle any 
prefix length. Of course these are interdependent and doing the latter makes 
it harder to enforce the first.


I propose the following:

IPv6 unicast routing is based on prefixes of any valid length up to 128 
bits [BCP198]. However, as explained in [RFC7421], the Interface ID of 
unicast addresses is generally required to be 64 bits in length, with 
exceptions only provided in special cases where expressly recognized in 
IETF standards track documents.

In response to various comments to this message, I’d like to propose a 
refinement:

IPv6 unicast routing is based on prefixes of any valid length up to 128 bits 
[BCP198]. However, in accordance with the reasoning explained in [RFC7421], 
the Interface ID part of host interface addresses is generally 64 bits, with 
exceptions only provided in special cases expressly recognized in IETF 
standards track documents.

I disagree with the view that advancing RFC 4291 to standards track admits the 
opportunity to relax the applicability of the 64-bit boundary to only those 
cases where SLAAC is used. That would be a technical change to the 
specification that I’m not comfortable promoting at IETF Last Call. In support 
of that position, I note that the reasoning in RFC 7421 covers cases beyond 
just SLAAC, and I have previously written about a case not mentioned in RFC 
7421, the LOWPAN_IPHC header compression scheme, which is used in various LLN 
schemes, e.g. IEEE 802.15.4, for compressing IPv6 addresses using the 
assumption that network prefixes are 64 bits.

For my personal part, I’d prefer to see a clear statement here using RFC 2119 
requirements language keywords, but I recognize that consensus probably 
requires compromise on that point. Hence, the proposed refinement above, which 
does not use RFC 2119 keywords. (Here is how I would write this with keywords: 
“IPv6 unicast routing is based on network prefixes that MAY have any valid 
length up to 128 bits [BCP198]. However, in accordance with the reasoning 
explained in [RFC7421], the Interface ID part of host interface addresses 
SHOULD be 64 bits with exceptions only provided in special cases expressly 
recognized in IETF standards track documents.”)


--james woodyatt <jhw(_at_)google(_dot_)com <mailto:jhw(_at_)google(_dot_)com>>



<Prev in Thread] Current Thread [Next in Thread>