Subject: past IAB statement about IPv6 Addressing Architecture

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 12:15:26 -0400

<http://www.iab.org/appeals/2003-2/iab-response-to-appeal-against-iesg-action-raised-by-mr-r-elz-appeal-text-february-2003/>

The Internet Architecture Board (IAB) does multiple things,
including Internet Architecture, handling appeals of IESG
decisions, overseeing the RFC publication process, and other matters.

There was an appeal from Robert Elz to the IAB about a decade ago
that related to IPv6 and IESG handling of some IPv6 document(s).  
The IAB response is at the URL above.

I was an IAB member at that time and directly participated
in the IAB's review of the claims and also in the IAB's
decisions about that appeal.  I was not the author of the 
precise wording used in the IAB's formal response at the
URL above.

The IAB definitely had consensus that the IPv6 architecture
and engineering specifications required a 64-bit IID, that
this was a fundamental part of the IPv6 architecture, and
made specific recommendations to the IESG to clarify documents
accordingly.

Quoting from part of that IAB statement, specifically from Section:
> X) The IAB considers that the separation of the Interface-ID from the 
> Subnet Identifier in IPv6 unicast addresses not starting with binary 000 
> is a fundamental property of the IPv6 addressing and routing architecture 
> and should be retained.

Quoting from part of that IAB statement, specifically from Section 2.3:
> d) We recommend that, as an update to this document, and via a recommendation
> to the IESG, that the IPv6 Working Group uses clearer specification language
> as per RFC-2026 and RFC-2119 to describe the requirement for a 64-bit
> Interface-ID in IPv6 unicast addresses not starting with binary 000.
> 
> e) We recommend that, via a recommendation to the IESG, that the
> IPv6 Working Group expeditiously revise RFC-2461 to:
> 
> specifically note that it is not valid to configure an IPv6 router such
> that the ‘autonomous configuration’ bit is set to TRUE AND the advertised
> IPv6 prefix length exceeds 64 bits AND the advertised IPv6 prefix does not
> start with binary 000,
>  
> and also expeditiously revise RFC-2462 to:
> specifically require that a host ignore a Prefix Advertisement Option 
> when the first three bits of the advertised IPv6 prefix do not start 
> with binary 000 AND the advertised IPv6 prefix-length exceeds 64-bits.

This IAB Appeal Response is specific confirmation that the 
IPv6 architecture always has had a 64-bit IID.  This IAB response 
should be cited as a normative reference on this topic in the
"Why /64" Internet-draft.

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 06:46:03 +1300

Ran,

>> Interface-ID in IPv6 unicast addresses not starting with binary 000.

The language in the addressing architecture is very explicit on this,
and has been since RFC 3513 (April 2003). Furethermore, the explicit
language is in the archived version of draft-ietf-ipngwg-addr-arch-v3-10.txt
which is *earlier* than the mysterious version 11 mentioned in
kre's appeal. So I find this part of the appeal mysterious.

>> with binary 000 AND the advertised IPv6 prefix-length exceeds 64-bits.

This was not done. Apart from anything else, there's no such thing
as a "Prefix Advertisement Option", but even if we replace it by PIO,
RFC 4862 does not appear to say this. I don't recall, but I assume
that there was no consensus for this change in the IPv6 WG.

The evidence is that implementations that support PIO do in fact
accept whatever prefix length is advertised, which conforms
to RFC 4862 IMHO. I don't see this as harmful, because it's
orthogonal to the choice that 64 bits is the IID length in
IPv6-over-foo specs.

> "Why /64" Internet-draft.

We can mention it in the historical summary, but it isn't part
of the normative history of IPv6 (sorry, IAB ;-).

    Brian

> 
> Yours,
> 
> Ran
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: David Farmer <[email-masked]>
Date: Sun, 16 Mar 2014 23:27:02 -0500

>> <http://www.iab.org/appeals/2003-2/iab-response-to-appeal-against-iesg-action-raised-by-mr-r-elz-appeal-text-february-2003/>
...
> kre's appeal. So I find this part of the appeal mysterious.

I'm sure this is an unadvisable string to pull on, BUT.

1. RFC2373 had a RFC2119 reference.
2. RFC2373 has the text "The format prefixes 001 through 111, except for 
Multicast Addresses (1111 1111), are all required to have to have 64-bit 
interface identifiers..."
3. For some reason unknown to me; In draft-ietf-ipngwg-addr-arch-v3-03 
the reference to RFC2119 was dropped.
3. The text "For all unicast addresses, except those that start with 
binary value 000, Interface IDs are required to be 64 bits long..." is 
introduced in draft-ietf-ipngwg-addr-arch-v3-06, this is essentially 
equivalent to the text in #2
4. RFC3513 and RFC4291 have NO reference to to RFC2119 and the text "For 
all unicast addresses, except those that start with binary value 000, 
Interface IDs are required to be 64 bits long..."

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Mar 2014 21:01:41 +1300

David,

RFC 2119 is beside the point. In a standards track document
that does not cite RFC 2119, the normal English interpretation
of words like "must" applies. iirc the addressing architecture
and the basic IPv6 spec do not cite RFC 2119.

The fact that there was some flapping in the architecture
in the early years also seems to be beside the point; things
became clearer as time (and running code) moved on.

    Brian