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

[David Farmer <[e-mail]>]

On Mon, Jan 16, 2017 at 10:52 PM, Lorenzo Colitti <[e-mail]>
wrote:

> 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.
>

What happens if they are not 64 bits long, do the proverbial Internet
police write a ticket?  Do I have to return my addresses to ARIN?  This
seems to be a false imperative to me.  If 64 bit IIDs are really required,
I'd like to see better motivation for this as a requirement.  I only see
motivation for this to be a recommendation, and I'm not the only one.

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.
>

What breaks if all IIDs in global unicast are not 64 bits?  Especially
other than SLACC?  I would hope such a REQUIREMENT has a better motivation
that "we said so".  Citing the "rest of the specifications" was simply my
shorthand for I don't see what else breaks.


>   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?
>

I never said there was a conflict between conflict between RFC5942 and
RFC4291, I was very careful about that.  I said there was a "conflict with
section 2.4 and RFC6164, BCP198/RFC7608".

I was saying that the need for RFC5942 and BCP198/RFC7608 are evidence that
the text in question is faulty[1], I think you would prefer misunderstood,
but in my opinion its more that, so I went with faulty.

[1} fault·y - adjective - working badly or unreliably because of
imperfections.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================