Subject: Reserved interface identifier registry

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Mar 2007 20:42:35 -0400

Hi Folks,
   Some RFCs (I know of at least 2, RFC2526 and RFC4214) reserve a set 
of interface identifiers on all prefixes. These identifiers need to be 
excluded when a node autoconfigures an address. This problem occurs with 
privacy addresses but is equally applicable to other address assigment 
methods like dhcpv6, cga etc. As Bernie suggested in a mail it would be 
good to maintain a list of such identifiers. This is possible by either 
listing the currently assigned IIDs in a document, or by creating an 
IANA registry. The former is useful if there will be no such allocations 
in the future and the later is useful if there will be future 
allocations. I have written a draft regarding this and I was wondering 
if the wg considers this to be useful work worth pursuing. I would also 
like to know if there are any other RFCs/drafts which depend on using 
specific IIDs.

Thanks
Suresh

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

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 21 Mar 2007 04:00:46 -0400

I second the idea of an IANA registry for that. This would be
very useful and would provide be the easiest way to update that
list later.

   - Alain. 

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 1:43 AM
> To: [email-masked]
> Subject: Reserved interface identifier registry
> 
> Hi Folks,
>    Some RFCs (I know of at least 2, RFC2526 and RFC4214) 
> reserve a set of interface identifiers on all prefixes. These 
> identifiers need to be excluded when a node autoconfigures an 
> address. This problem occurs with privacy addresses but is 
> equally applicable to other address assigment methods like 
> dhcpv6, cga etc. As Bernie suggested in a mail it would be 
> good to maintain a list of such identifiers. This is possible 
> by either listing the currently assigned IIDs in a document, 
> or by creating an IANA registry. The former is useful if 
> there will be no such allocations in the future and the later 
> is useful if there will be future allocations. I have written 
> a draft regarding this and I was wondering if the wg 
> considers this to be useful work worth pursuing. I would also 
> like to know if there are any other RFCs/drafts which depend 
> on using specific IIDs.
> 
> Thanks
> Suresh
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 21 Mar 2007 09:39:17 +0100

Agree.

Regards,
Jordi

> De: "Durand, Alain" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 21 Mar 2007 04:00:46 -0400
> Para: Suresh Krishnan <[email-masked]>, <[email-masked]>
> Conversación: Reserved interface identifier registry
> Asunto: RE: Reserved interface identifier registry
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 21 Mar 2007 11:21:06 +0200

On Wednesday 21 March 2007 02:42:35 Suresh Krishnan wrote:
> good to maintain a list of such identifiers.

In practice, there is going to be a nasty problem if we reserve extra IIDs 
that are currently not reserved, as older implementations will not consider 
them as reserved.

Shouldn't we rather define a "large" set of reserved addresses that cannot be 
used as normal IIDs - or do we have this already?

Of course, we'd still need an IANA registry at the end of the day to keep 
track of which addresses in the reserved set actually have a semantic.

-- 
Rémi Denis-Courmont

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 21 Mar 2007 05:48:36 -0400

No disagreement here.

However, this is NOT the fault of the list. Any RFC that defines a new restricted range would need to point out the issue that existing implementations may configure an address in this restricted range.

But, having an IANA registry at least gives us a mechanism by which implementers can learn about this list without having to potentially review thousands of RFCs. Or, if the allocation technique provides a way to administratively adjust the list, they have a source from which to do it.

- Bernie

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 5:21 AM
To: [email-masked]
Cc: Suresh Krishnan
Subject: Re: Reserved interface identifier registry

-- 
Rémi Denis-Courmont

---

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Mar 2007 10:55:41 +0100

Suresh,

On Mar 21, 2007, at 1:42 AM, Suresh Krishnan wrote:

> Hi Folks,
>   Some RFCs (I know of at least 2, RFC2526 and RFC4214) reserve a  
> set of interface identifiers on all prefixes. These identifiers  
> need to be excluded when a node autoconfigures an address. This  
> problem occurs with privacy addresses but is equally applicable to  
> other address assigment methods like dhcpv6, cga etc. As Bernie  
> suggested in a mail it would be good to maintain a list of such  
> identifiers. This is possible by either listing the currently  
> assigned IIDs in a document, or by creating an IANA registry. The  
> former is useful if there will be no such allocations in the future  
> and the later is useful if there will be future allocations. I have  
> written a draft regarding this and I was wondering if the wg  
> considers this to be useful work worth pursuing. I would also like  
> to know if there are any other RFCs/drafts which depend on using  
> specific IIDs.
>

I agree with the discussion that this sounds like a good idea.  Could  
you provide a summary of the current IID forms?  It would help for  
everyone to understand the issue.  Or better, could you write an ID  
that describes the issue and defines the initial IANA registry.

Thanks,
Bob

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Mar 2007 16:34:44 +0200

Suresh Krishnan wrote:
> Hi Folks,
>   Some RFCs (I know of at least 2, RFC2526 and RFC4214) reserve a set of 
> interface identifiers on all prefixes. These identifiers need to be 

Not sure whether Teredo 64bit Node Identifier qualifies as something to 
be reserved by IANA, because it's variably derived from IPv4 address and 
port number.  But the same is true with ISATAP as well, and you consider 
ISATAP.

I think two things are here:
-hardcoded IIDs: anycast rfc2526, maybe IPv6-over-linkswoMAC, other(?)
-list of methods to derive 64bit IIDs (EUI64, ISATAP, TEREDO, maybe
  IPv6-over-foo, maybe others).

I think only the hardcoded IIDs can be concerned by IANA reservation. 
The list of methods to derive 64bit IIDs is very good to maintain 
centrally, it's useful knowledge to many local designs.

Finally, isn't rfc2526 anycast address already assigned by IANA?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Mar 2007 11:55:17 -0700

> >   Some RFCs (I know of at least 2, RFC2526 and RFC4214) reserve a
set
> of
> > methods like dhcpv6, cga etc. 

Aren't we putting the cart before the horse?

An IANA registry cannot be the only way to avoid collisions. An address
allocation program may take into account the state of the registry at
the time the code is written, but is seldom updated after that. Just
getting a number allocated by IANA will not prevent competing use of
that number for other purposes.

There is a well established way to reserve MAC addresses, using a range
of identifiers assigned to IANA. There is also a well established way to
derive IPv6 interface identifiers from MAC addresses. It has been
specified for over 10 years, and you can be sure that all IPv6
implementations abide by it. If RFC 2526 and RFC 4214 followed that
framework, there would not be any problem. So, should we not instead go
update these two RFC?

-- Christian Huitema

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Mar 2007 18:33:12 -0400

> that number for other purposes.

Agreed. But there is not much we can do about this.

> framework, there would not be any problem. So, should we not instead go

Not really. You are assuming here that all IIDs are generated from MAC 
addresses. IIDs can be generated using other methods like CGA, Privacy 
Addresses etc. Hence reserving a range of MACs/OUIs is not sufficient.

Thanks
Suresh

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Mar 2007 21:38:14 -0700

> Addresses etc. Hence reserving a range of MACs/OUIs is not sufficient.

Actually, the non Mac derived identifier include a bit that indicate
that "this is not a reserved value", and thus don't conflict with
MAC-derived identifiers.

-- Christian Huitema

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 27 Mar 2007 09:31:28 -0400

Correct. That is NOT the issue. 3041 and 3041 bis use "randomly"
generated identifiers that are "local" (not "global" as mac-derived
identifiers are) and there are some RFCs that RESERVE certain ranges
within this "local" space. We need some place to document that list of
reserved ranges so that a "randomly" generated identifiers don't use
those reserved ranges. Any future assignment of reserved local
identifiers always run the risk of having existing implementations
generate identifiers that may conflict.

- Bernie

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 12:38 AM
To: Suresh Krishnan
Cc: Alexandru Petrescu; [email-masked]
Subject: RE: Reserved interface identifier registry

-- Christian Huitema

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Mar 2007 06:57:24 -0700

In the case of RFC4214 at least, I'm not so sure now that
there needs to be a reserved local range. From Section 6.1,
the text:

   "When the IPv4 address is known to be globally unique, the "u" bit
   (universal/local) is set to 1; otherwise, the "u" bit is set to 0.
   "g" is the individual/group bit, and "m" are the bits of the IPv4
   address."

But, I think now that we have sufficient operational experience
it could be said that this text is unnecessary and unnecessarily
causing us to keep a registry in the IANA. Reason being is that
ISATAP will never cross NATs, and so it doesn't matter whether
the IPv4 addresses are privacy addresses, global addresses or
some mix of both because all nodes on the ISATAP link will be
in the same site by definition.

So, as long as the document states clearly that ISATAP interfaces
MUST assign addresses of the form specified in section 6 (and no
other types of addresses) I don't see the need to maintain an
IANA registry.

Fred
[email-masked] 

> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 6:31 AM
> To: Christian Huitema; Suresh Krishnan

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 27 Mar 2007 14:55:46 -0400

Hi Folks,
   I am attaching the draft I wrote regarding this. Can you please comment.

Thanks
Suresh

> that "this is not a reserved value", and thus don't conflict with

Network Working Group                                        S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Standards Track                          March 20, 2007
Expires: September 21, 2007

                  Reserved IPv6 Interface Identifiers
                   draft-krishnan-ipv6-reserved-iids

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 21, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Krishnan               Expires September 21, 2007               [Page 1]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

Abstract

   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.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Issues with reusing reserved Interface Identifiers . . . . . .  5
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10

Krishnan               Expires September 21, 2007               [Page 2]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Krishnan               Expires September 21, 2007               [Page 3]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

2.  Introduction

   An IPv6 unicast address is composed of two parts.  A subnet prefix
   and an interface identifier (IID) that identifies an unique interface
   within the subnet prefix.  The structure of an IPv6 unicast address
   is depicted in the IPv6 Addressing Architecture [RFC4291] and is
   replicated here for clarity.

   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | interface ID   |
   +------------------------------------------------+----------------+

                   Figure 1: IPv6 Unicast Address Format

   For all unicast addresses, except those that start with binary value
   000, Interface identifiers are required to be 64 bits long (i.e.
   n==64) .  If the interface identifiers are generated from an unique
   token like an ethernet MAC address, they need to set bit 6 of the
   first octet to one.  If they are not generated from an unique token
   they need to set bit 6 to zero.  Examples of mechanisms that generate
   interface identifiers without an unique token include
   Cryptographically Generated Addresses [RFC3972], Privacy Addresses
   [PRIVACY], Hash Based Addresses [HBA] etc.  Non-unique interface
   identifiers can also be allocated using managed address assignment
   mechanisms like DHCPv6 [RFC3315].

Krishnan               Expires September 21, 2007               [Page 4]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

3.  Issues with reusing reserved Interface Identifiers

   Let us assume a node comes up with an interface identifier that has
   been reserved for use in some other capacity. e.g.  An IPv6 node that
   uses temporary IPv6 addresses [PRIVACY] comes up with an IID of fdff:
   ffff:ffff:fffe .  This node will receive requests from all nodes that
   are requesting a service from a MobileIPv6 home agent.  At best this
   is an annoyance to the node that came up with this address.  In the
   worst case scenario another node on the link would be denied service
   and may not look for other methods of acquiring a home agent.

Krishnan               Expires September 21, 2007               [Page 5]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

4.  IANA Considerations

   This document requests the creation of an IANA registry for reserved
   IPv6 Interface Identifiers.  Initial values for the reserved IPv6
   Interface Identifiers are given below.

   +-----------------------------------------+-------------------------+
   |        Interface Identifier Range       |       Description       |
   +-----------------------------------------+-------------------------+
   | 0000:0000:0000:0000-0000:0000:0000:0000 |  Subnet Router Anycast  |
   |                                         |        [RFC4291]        |
   |                                         |                         |
   | 0000:5efe:0000:0000-0000:5efe:ffff:ffff |     ISATAP [RFC4214]    |
   |                                         |                         |
   | fdff:ffff:ffff:ff80-fdff:ffff:ffff:fffd | Reserved Subnet Anycast |
   |                                         |        [RFC2526]        |
   |                                         |                         |
   | fdff:ffff:ffff:fffe-fdff:ffff:ffff:fffe |  MobileIPv6 Home Agents |
   |                                         |    Anycast [RFC2526]    |
   |                                         |                         |
   | fdff:ffff:ffff:ffff-fdff:ffff:ffff:ffff | Reserved Subnet Anycast |
   |                                         |        [RFC2526]        |
   +-----------------------------------------+-------------------------+

                       Table 1: Current Assignments

   It is possible that implementations might predate a specific
   assignment from this registry and hence not be cognizant of the
   reserved nature of the interface identifier.  Hence. future
   assignments from this registry are discouraged but in exceptional
   circumstances are to be made through Expert Review [IANABIS].
   Assignments consist of a single interface identifier or a range of
   interface identifiers.

Krishnan               Expires September 21, 2007               [Page 6]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

5.  Security Considerations

   Information that creates or updates a registration needs to be
   authenticated and authorized.  By utilizing one of the reserved
   interface identifiers an IPv6 node might receive requests that it is
   not authorized to receive.

Krishnan               Expires September 21, 2007               [Page 7]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
              Addresses", RFC 2526, March 1999.

   [RFC4214]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", RFC 4214, October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

6.2.  Informative References

   [HBA]      Bagnulo, M., "Hash Based Addresses (HBA)",
              draft-ietf-shim6-hba-02 (work in progress), October 2006.

   [IANABIS]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-05 (work in
              progress), September 2006.

   [PRIVACY]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", draft-ietf-ipv6-privacy-addrs-v2-05 (work in
              progress), October 2006.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

Krishnan               Expires September 21, 2007               [Page 8]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

Author's Address

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: [email-masked]

Krishnan               Expires September 21, 2007               [Page 9]

Internet-Draft     Reserved IPv6 Interface Identifiers        March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Krishnan               Expires September 21, 2007              [Page 10]

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Mar 2007 16:56:22 -0700

> > generate identifiers that may conflict.

Fred explained that ISATAP identifiers should really use the global bit as well.
As for anycast and multicast, these addresses supposedly set the "group" bit in the identifiers -- and if they don't they really should, since the L2 transmission is multicast. Setting the G bit differentiates these addresses from RFC3041 addresses.

I don't think that we have a real problem, and I believe that an additional registry would do more harm than good. It would create an avenue for groups to reserve more identifiers, in the naïve belief that implementations would magically be updated to avoid these numbers. And it would create an extra burden for implementers. Groups that want to reserve identifiers should really use the IEEE 802 processes.

-- Christian Huitema

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 27 Mar 2007 20:28:28 -0400

Then perhaps this should be mentioned in draft-ietf-ipv6-privacy-addrs-v2-05.txt?

  A randomized interface identifier is created as follows:

   1.  Take the history value from the previous iteration of this
       algorithm (or a random value if there is no previous value) and
       append to it the interface identifier generated as described in
       [ADDRARCH].

   2.  Compute the MD5 message digest [MD5] over the quantity created in
       the previous step.

   3.  Take the left-most 64-bits of the MD5 digest and set bit 6 (the
       left-most bit is numbered 0) to zero.  This creates an interface
       identifier with the universal/local bit indicating local
       significance only.

   4.  Compare the generated identifier against a list of reserved
       interface identifiers and to those already assigned to an address
       on the local device.  In the event that an unacceptable
       identifier has been generated, the node MUST restart the process
       at step 1 above, using the right-most 64 bits of the MD5 digest
       obtained in step 2 in place of the history value in step 1.

Instead of step 4, perhaps step 4 (or as part of 3) should state that the individual/group bit (bit 7) should be set to 0 to indiciate individual (unless a group identifier were being generated, which I don't think is the point of this draft). There is no mention of this bit in the document.

I'm not sure I fully understand Fred's statements with respect to ISATAP, but if these are not an issue then that's great.

- Bernie 

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 7:56 PM
To: Suresh Krishnan; Bernie Volz (volz)
Cc: Alexandru Petrescu; [email-masked]
Subject: RE: Reserved interface identifier registry

-- Christian Huitema

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 07:40:30 -0700

> Fred explained that ISATAP identifiers should really use the 

Hmm; not exactly what I said, but in (RFC4214, Section 6.1),
what if we were to change:

  "When the IPv4 address is known to be globally unique, the "u" bit
   (universal/local) is set to 1; otherwise, the "u" bit is set to 0."

to:

  "The "u" bit (universal/local) is set to 1 but the interface
   identifier is only known to be unique within the site, i.e.,
   it may or may not be unique on a global basis."

This would certainly ease some of the pressure Suresh may be
feeling, but would there be a backward-compatibility issue
for already-deployed implementations? (As long as the existing
implementationss treat the 'u' bit as "don't-care", there
should be no problem, right?)

Thanks - Fred

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 28 Mar 2007 12:01:03 -0400

Hi Bernie,

> Instead of step 4, perhaps step 4 (or as part of 3) should state 
 > that the individual/group bit (bit 7) should be set to 0 to
 > indiciate individual (unless a group identifier were being generated,
> which I don't think is the point of this draft). There is no mention
 > of this bit in the document.

I don't know if there is such a thing as a group identifier. I have 
always been uncomfortable with the meaning of this bit in the IID. 
RFC4291 refers to flipping a unique bit in the EUI-64 and EUI-64 does 
not mention a group/individual bit.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 28 Mar 2007 12:09:57 -0400

Hi Christian,

> As for anycast and multicast, these addresses supposedly set the "group" bit in the identifiers -- and if they don't they really should, since the L2 transmission is multicast. Setting the G bit di…

Agree. How do we go about doing this? erratum for the RFCs in question? 
bis versions of the RFCs? How about backward compatibility?

> I don't think that we have a real problem, and I believe that an additional registry would do more harm than good. It would create an avenue for groups to reserve more identifiers, in the naïve bel…

I think there is a real problem. The problem being documents "reserving 
" interface IDs for special use without actually taking them out of 
circulation. I agree in principle with you that this is a bad idea. If 
you look at the IANA considerations of my draft you would see the 
following text.

Thanks
Suresh

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 28 Mar 2007 12:32:47 -0400

4291 does mention it in Appendix A:

   where "c" is the bits of the assigned company_id, "0" is the value of
   the universal/local bit to indicate universal scope, "g" is
   individual/group bit, and "m" is the bits of the manufacturer-
   selected extension identifier.  The IPv6 interface identifier would
   be of the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   The only change is inverting the value of the universal/local bit.

- Bernie

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 12:01 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: Reserved interface identifier registry

Hi Bernie,

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 28 Mar 2007 14:16:42 -0400

Hi Bernie,

>    selected extension identifier.  The IPv6 interface identifier would

It mentions what the format of the EUI-64 is. Not what these bits mean 
in the IID. My take on this is that the format of the EUI-64 has nothing 
whatsoever to do with the format of the IID. If this were true we need 
to get OUIs assigned by IEEE (The 'c' bits in the figure) for each of 
the random IID generation techniques. Do you agree?

Cheers
Suresh

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 28 Mar 2007 14:27:41 -0400

Well, my interpretation is that EUI-64s always have the universal/local
bit set to universal. And, non-EUI-64's have the universal/local bit
"set" to local.  For local ones, I assume that the 'c' and 'm' bits are
"anything goes". The question then is whether the individual/group bit
applies.

If one looks at the anycast addresses, those are group (as well as
local). So, that seems to imply that this carries over.

But, the following appendix section:

   Links with Other Kinds of Identifiers

   There are a number of types of links that have link-layer interface
   identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs.  Examples
   include LocalTalk and Arcnet.  The method to create a Modified EUI-64
   format identifier is to take the link identifier (e.g., the LocalTalk
   8-bit node identifier) and zero fill it to the left.  For example, a
   LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in
   the following interface identifier:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

   Note that this results in the universal/local bit set to "0" to
   indicate local scope.

Does not mention the individual/group bit, just the universal/local.

So, it is a bit unclear.

- Bernie

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 2:17 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: Reserved interface identifier registry

Hi Bernie,

Bernie Volz (volz) wrote:
>    |0              1|1              3|3              4|4
6|
>    |0              5|6              1|2              7|8
3|

Cheers
Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 15:22:16 -0700

To correct myself, we verified under Microsoft Windows Vista
that the ISATAP interface sets the "u" bit to 1 when the
node is configured with a public IPv4 address and sets the
"u" bit to 0 when the node is configured with a private IPv4
address. Hence, there is no change to the text of RFC4214.

As to Suresh's issue, I don't see it as necessary to check
self-generated addresses to be sure they do not encode the
ISATAP "magic number", since self-generated addresses cannot
be assigned on ISATAP interfaces, and ISATAP addresses
cannot be assigned on ordinary IPv6 interfaces. Hence,
there is no ambiguity and no need for a special registry.

Fred

> From: Templin, Fred L 
> Sent: Wednesday, March 28, 2007 7:41 AM
> To: Christian Huitema; Suresh Krishnan; Bernie Volz (volz)

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 30 Mar 2007 18:44:46 -0400

>there is no ambiguity and no need for a special registry.
 
That makes the most sense so far.

So, that removes ISATAP addresses from consideration.

It does not however leave the all-zero's interface-identifier as that
has special meaning (see RFC 4291, 2.6.1.  Required Anycast Address). If
that is all, then draft-ietf-ipv6-privacy-addrs-v2-05.txt should state
that instead of the vague "Compare the generated identifier against a
list of reserved interface identifiers ...".

The draft could retain that language, as long as it defined what this
reserved list was. Leaving it unspecified just causes folks to wonder
what the list might be -- hence my original suggestion for having it an
IANA managed list.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, March 30, 2007 6:22 PM
To: Christian Huitema; Suresh Krishnan; Bernie Volz (volz)
Cc: Alexandru Petrescu; [email-masked]
Subject: RE: Reserved interface identifier registry

Fred