Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

[Lorenzo Colitti <[e-mail]>]

On Tue, Jan 17, 2017 at 1:32 PM, David Farmer <[e-mail]> wrote:

> reinserting "required" back in the phrase above just brings back the
> conflict with section 2.4 and RFC6164, BCP198/RFC7608, because the
> statement isn't scoped to SLACC.  64 bit IIDs are clearly the consensus
> RECOMMENDATION, other than for point-to-point links, but saying they are
> REQUIRED for other than SLACC is plainly false.
>

Required for what purpose? For things to work on a particular
implementation? Or required by the standards? As far as the current
standards are concerned, with the exception of /127, IIDs for global
unicast addresses outside ::/0 are required to be 64 bits long, period. If
we change that, we're making a substantive change to the standard.

As for what is required for things to work on your favourite
implementation, the list of of things that will work depends solely on your
definition of work. For some people, things work "work" might "client
applications can reach external servers", and the list of things that will
work (even though it violates various standards) include numbering a
10000-person office with ULA and putting it behind a full-cone NAT66 that
translates everything to one IPv6 address.


> Manual configuration and DHCPv6 with other than 64 bit IIDs or /64
> subnets, are in operational use in many places, this is clearly NOT
> RECOMMENDED, but it is completely consistent with all the rest of
> specifications of IPv6.
>

Citing the "rest of the specifications" here is not germane to the
discussion. Using non-/64 IIDs conflicts with precisely the RFC that is
authoritative on that topic, which is RFC 4291. Saying that it doesn't
conflict with any other RFCs is a bit like saying that tax evasion is not
prohibited by any other law than tax law: (in first approximation) true,
but not really relevant.


>   Furthermore, if the old text was correctly understood we would not have
> needed RFC5942 and BCP198/RFC7608, therefore the old text is clearly faulty.
>

"Not clear" != "faulty". As explained before, there is no conflict between
RFC 4291 and RFC 7608. RFC 7608 applies to forwarding, RFC 4291 applies to
link addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can
you clarify what you mean?