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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



---- Original Message -----
From: "james woodyatt" <jhw@xxxxxxxxxx>
Sent: Friday, February 17, 2017 8:20 PM

On Feb 16, 2017, at 14:21, james woodyatt <jhw@xxxxxxxxxx> 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.”)

<tp>
James

The issue of introducing RFC2119 keywords into a xxxxbis document for
which the original did not have them was a topic of discussion in the
WG; their absence reflects the consensus of the WG so to suggest them,
even obliquely, opens up another can of worms to add the ones we already
have on this set of I-Ds in these threads.

I think we already have enough cans open to keep me fishing for the rest
of my life!

Tom Petch

-james woodyatt <jhw@xxxxxxxxxx <mailto:jhw@xxxxxxxxxx>>







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]