Subject: Protocol Action: 'Reserved IPv6 Interface Identifiers' to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 12 Dec 2008 09:54:07 -0800 (PST)

The IESG has approved the following document:

- 'Reserved IPv6 Interface Identifiers '
   <draft-ietf-6man-reserved-iids-03.txt> as a Proposed Standard

This document is the product of the IPv6 Maintenance Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-reserved-iids-03.txt

Technical Summary

  Interface Identifiers in IPv6 unicast addresses are used
  to identify interfaces on a link.  They are required to be
  unique within a subnet.  Several RFCs have specified
  interface identifiers or identifier ranges that have a
  special meaning attached to them.  An IPv6 node
  autoconfiguring an interface identifier in these ranges
  will encounter unexpected consequences.  Since there is no
  centralized repository for such reserved identifiers, this
  document aims to create one.

Working Group Summary

  The 6MAN working group has done extensive reviews of this 
  document and it reflects the consensus of the working group.

Document Quality

  This document has been reviewed by numerous members of the
  [email-masked] mailing list and by the 6MAN WG chairs.
     
Personnel

  Brian Haberman is the Document Shepherd, and Jari Arkko is
  the responsible Area Director.

RFC Editor Note

  Make this change in Appendix A:

  OLD:
  The following RFCs that generate interface identifiers need to be
  updated if they wish to avoid conflicts with the reserved interface
  identifier ranges.
  NEW:
  Implementations of the following RFCs need to be aware of the 
  reserved interface identifier ranges when they allocate new
  addresses. Future revisions of these RFCs should ensure that
  this is either already sufficiently clear or that the text
  is amended to take this into account.

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

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Fri, 12 Dec 2008 21:18:11 -0500

Colleagues,

I have a question about the following language in section 2.0:

"For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format. "

Although I do not see a MUST in this sentence, it appears that the
proposed standard is mandating that all interface IDs be 64-bits long.
This is not a requirement in several RFCs listed below. As a result, I
believe that this requirement should be stricken from the document.

RFC 2460, 5095
RFC 2463, 4443, 4884
RFC 2461, 3971, 4861
RFC 2462, 4862, 4941
RFC 3315, 3633, 3736, 4361
RFC 1981
RFC 2526, 3879, 4007, 4291
RFC 2671, 3596, 3986
RFC 3493, 3542, 3678, 4584, 5014
RFC 2740, 4552
RFC 1772, 2545, 4271, 4760
RFC 3948, 4301, 4302, 4303, 4308, 4809
RFC 4306, 4307, 4945
RFC 4213
RFC 2573, 2784, 4891
RFC 4798
RFC 3411, 3412, 3413, 3414
RFC 3289, 4022, 4087, 4113, 4292, 4293, 4295, 4807
RFC 3810, 4604
RFC 4601, 4609
RFC 2474, 2475, 2597, 2983, 3086, 3140, 3168, 3246, 3247, 3260, 3494
RFC 5072

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
The IESG
Sent: Friday, December 12, 2008 12:54 PM
To: IETF-Announce
Cc: 6man chair; Internet Architecture Board; 6man mailing list; RFC
Editor
Subject: Protocol Action: 'Reserved IPv6 Interface Identifiers' to
Proposed Standard 

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-reserved-iids-03.tx
t

Technical Summary

Working Group Summary

Document Quality

Personnel

RFC Editor Note

  OLD:

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2008 15:42:54 +1300

Jeffrey,

> constructed in Modified EUI-64 format. "

This exact text is also present in RFC4291 section 2.5.1. As far as I know,
this has been part of the IPv6 address architecture since 1998 (RFC2373).

> believe that this requirement should be stricken from the document.

That would be a no-op, since it's already required by RFC4291.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Dec 2008 21:23:57 +0200

Brian, Jeffrey,

The picture and text that you quoted are in this RFC exactly as they are 
in RFC 4291. We did get some feedback on that text during the last call, 
but we decided that it would be confusing for this particular RFC to say 
something else than RFC 4291. RFC 4291 is, after all, the currently 
approved addressing architecture document.

If we ever decide to make a change in the addressing architecture, we 
should issue an RFC 4291bis, not change the text in the various other 
RFCs that quote 4291 for some reason.

Jari

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Mon, 15 Dec 2008 09:16:59 -0500

Jari and Brian,

Would the 6man group consider an update to RFC 4291 that is contains
less prescriptive language? If so, I would be happy to undertake that
task.  Please let me know.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, December 13, 2008 2:24 PM
To: Brian E Carpenter
Cc: Dunn, Jeffrey H.; [email-masked]; Internet
Architecture Board; 6man mailing list; IESG; RFC Editor
Subject: Re: Protocol Action: 'Reserved IPv6 Interface Identifiers' to
Proposed Standard

Brian, Jeffrey,

The picture and text that you quoted are in this RFC exactly as they
are 
in RFC 4291. We did get some feedback on that text during the last
call, 
but we decided that it would be confusing for this particular RFC to
say 
something else than RFC 4291. RFC 4291 is, after all, the currently 
approved addressing architecture document.

Jari

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Dec 2008 07:01:30 -0800

>From: Dunn, Jeffrey H. [mailto:[email-masked]]
>Sent: Friday, December 12, 2008 6:18 PM
>To: The IESG; IETF-Announce
>Cc: 6man chair; 6man mailing list; [email-masked];
Internet Architecture Board; RFC
>Editor
>Subject: RE: Protocol Action: 'Reserved IPv6 Interface Identifiers'
toProposed Standard
>believe that this requirement should be stricken from the document.

I respectfully disagree. Without a well-known 64-bit ID
requirement, there would be no way to prepare a prepare
a well-formed subnet router anycast address, for example.

Fred
[email-masked]

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Mon, 15 Dec 2008 10:38:26 -0500

Fred,

I am not suggesting that the requirement that a device support 64-bit
prefixes be relaxed. I am suggesting that the requirement that prefixes
only be 64-bit be relaxed.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, December 15, 2008 10:02 AM
To: Dunn, Jeffrey H.; The IESG; IETF-Announce
Cc: 6man chair; 6man mailing list; [email-masked];
Internet Architecture Board; RFC Editor
Subject: RE: Protocol Action: 'Reserved IPv6 Interface Identifiers'
toProposed Standard 

toProposed Standard

Fred

---

From: Thomas Narten <[email-masked]>
Date: Mon, 15 Dec 2008 15:23:42 -0500

[trimming the cc's a bit...]

> I am not suggesting that the requirement that a device support
> 64-bit prefixes be relaxed. I am suggesting that the requirement
> that prefixes only be 64-bit be relaxed.

Whether we like it or not, the 64 bit IID requirement is fairly deeply
ingrained within IPv6. It is not easy to change that requirement in a
meaningful way without impacting a number of basic documents (and
implementations). For example, all the IPv6 over Foo documents make
this assumption...

Saying an IPv6 prefix could be something other that a 64 turns out to
make little sense, if the IID is 64 bits. The sum of the IID and the
prefix simply has to add up to 128 bits. Relaxing that restriction is
much harder and would require implementations to change. Stateless
address autoconfiguration requires this today.

One has to go back and understand the history that led to 64-bit IIDs
to understand why we are where we are today. Knowing what we know
today, and given the option of a clean slide redesign, we'd surely do
it differently. :-) But given where we are today, given the
pain/cost/hassle of changing the specifications (and implementations),
it is my opinion that the benefits of doing so simply don't justify
the effort. We have more urgent places to invest our resources.

> >constructed in Modified EUI-64 format. "

All addresses would have been required to support 64 IIDs, but at the
time the change was made to switch from 48-bit IIDs to 64-bit ones,
some of the "funny" address formats were incompatable with a 64-bit
IID. For example, look at RFC 1888 & 4048.

Thomas