Subject: Implementation specific Interface-ID

From: Vijayrajan ranganathan <[email-masked]>
Date: Wed, 24 Jun 2009 10:38:33 +0530

Hi Everyone,

I have an ethernet interface for which I am defining the Interface-ID
in a different manner.

For an ethernet interface with MAC "34-56-78-9A-BC-DE", I am defining
the Interface-ID to be "34-56-78-xy-zw-9A-BC-DE" instead of
"36-56-78-FF-FE-9A-BC-DE"

where x,y,z,w are my implementation-defined octets.

Note:
1. I am fine with a locally-unique Interface-ID
2. The solicited-node multicast address i'll generate for a given
unicast/anycast address based on this Interface-ID is the same as
that for RFC 2464 based Interface-ID.

Assuming I make this change in an IPv6 stack which conforms to RFCs

2464 - Transmission of IPv6 Packets over Ethernet Networks
3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture
4861 - Neighbor Discovery for IP version 6 (IPv6)
4862 - IPv6 Stateless Address Autoconfiguration
3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6

After this change, will I still conform to these RFCs??

Thanks & Regards
Vijay

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 24 Jun 2009 16:19:21 -0700

Technically you would comply with the RFCs, but the FFFE value was
negotiated with the IEEE to avoid colliding with their eventual conversion
to EUI-64. If you pick other values for the actual mac you need to talk to
the IEEE, but if it is only the IPv6 address the bits will work until an
implementation gets a full EUI-64 and doesn't want you claiming its
autoconfigured address. Other than that you will simply confuse people that
read documents that state the EUI-48 transform is supposed to be FFFE.

If you really want an implementation specific value, don't bother copying
the mac, hash it then put in your filler.

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vijayrajan ranganathan
> Sent: Tuesday, June 23, 2009 10:09 PM
> To: [email-masked]
> Subject: Implementation specific Interface-ID
> 
> Hi Everyone,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Duncan, Richard J. (Jeremy) CONTRACTOR" <[email-masked]>
Date: Wed, 24 Jun 2009 15:56:50 -0400

Vijay-

The only thing I could find is that it's just standard practice to use FF
FE.. For example, if you use privacy extensions then there is no FF FE
because its address is hashed right? I think it's just a 16 bit filler for a
MAC 48..  See below from the IEEE:

http://standards.ieee.org/regauth/oui/tutorials/EUI64.html

Even RFC 4291 didn't really go into much detail either..
http://www.ietf.org/rfc/rfc4291.txt

Anyone else have any thoughts?  I also included the NAv6TF in the
discussion..

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

DTRA (BE-BIC)
INFOSEC 3, IPv6 Architect
Command Information
Office: (703) 767-6167
Cell: (703) 598-1193

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijayrajan ranganathan
Sent: Wednesday, June 24, 2009 1:09 AM
To: [email-masked]
Subject: Implementation specific Interface-ID

Hi Everyone,

I have an ethernet interface for which I am defining the Interface-ID in a
different manner.

For an ethernet interface with MAC "34-56-78-9A-BC-DE", I am defining the
Interface-ID to be "34-56-78-xy-zw-9A-BC-DE" instead of
"36-56-78-FF-FE-9A-BC-DE"

Note:
1. I am fine with a locally-unique Interface-ID 2. The solicited-node
multicast address i'll generate for a given unicast/anycast address based on
this Interface-ID is the same as that for RFC 2464 based Interface-ID.

2464 - Transmission of IPv6 Packets over Ethernet Networks
3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture
4861 - Neighbor Discovery for IP version 6 (IPv6)
4862 - IPv6 Stateless Address Autoconfiguration 3810 - Multicast Listener
Discovery Version 2 (MLDv2) for IPv6

Thanks & Regards
Vijay

---

From: Bob Hinden <[email-masked]>
Date: Thu, 25 Jun 2009 14:51:24 +0300

Duncan,

> because its address is hashed right?

No, there is no FF FE because the IIDs created by RFC4941 have local  
significance.  From section 3.2.1:

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

IIDs with local significance only need to be unique on the link.   
Suggest reading the IID relateds sections and appendix in RFC4291.

> I think it's just a 16 bit filler for a

The FFEE is used to extend an EUI-48 to an EUI-64.  It is defined in  
the Section titled "Encapsulated EUI-48 values".  Namely, "A unique  
EUI-64 value is generated by concatenating the company_id, an FFFE  
valued label, and the extension identifier values".

> http://www.ietf.org/rfc/rfc4291.txt

RFC4291 references the above mentioned EUI64.html document.

Bob

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 25 Jun 2009 08:59:51 -0400

Vijay et al.,

RFC 4291 states in section 5.1:

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

Further, RFC 4291 is referenced in RFC 2464 (actually, it is the previous version) as providing further guidance on the formation of Interface ID's.

As a result, it appears to me that your methodology is not compliant with either RFC 2464 or 4291. That said, DAD should take care of any operational problems associated with not using the modified EUI-64. Further, since you appear to be using 64-bit Interface ID's , all the implementations I have come across should interoperate with your methodology.

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 Bob Hinden
Sent: Thursday, June 25, 2009 7:51 AM
To: Duncan, Richard J. (Jeremy) CONTRACTOR
Cc: [email-masked]; [email-masked]
Subject: Re: Implementation specific Interface-ID

Duncan,

Bob

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Fri, 26 Jun 2009 10:30:54 -0400

Jeremy,

I was not disagreeing (or agreeing) with your assertion. The original e-mail
had a question about RFC compliance. If an implementation does not use the
EUI-64 (regardless of how you choose to interpret the IEEE EUI-64
specification), it is not compliant with RFC 2464 or 4291; however,
operationally, I doubt it matters. Specifically, if DAD is in use (and it is
mandated by RFC 4862), then it really does not appear to matter how an
implementation forms the Interface ID. As a result, I am not sure that the
discussion of how to form an EUI-64 Interface ID is germane to Vijay's
original question, which appeared to relate to whether his proposed
mechanism for generating an Interface ID would break SLAAC, etc. My take is
No for the reasons stated.

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

-----Original Message-----
From: Duncan, Richard J. (Jeremy) CONTRACTOR
[mailto:[email-masked]] 
Sent: Friday, June 26, 2009 9:22 AM
To: Dunn, Jeffrey H.; Bob Hinden
Cc: [email-masked]
Subject: RE: Implementation specific Interface-ID

Jeff-

Yes, but nothing in the IEEE spec states anything that using the FF and FE
bits to supplant a MAC 48 is an absolute requirement for the Modified
EUI-64..  If so, please show me, I didn't find anything.

Jeremy Duncan

DTRA (BE-BIC)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dunn, Jeffrey H.
Sent: Thursday, June 25, 2009 9:00 AM
To: Bob Hinden; Duncan, Richard J. (Jeremy) CONTRACTOR
Cc: [email-masked]; [email-masked]
Subject: RE: Implementation specific Interface-ID

Vijay et al.,

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

Further, RFC 4291 is referenced in RFC 2464 (actually, it is the previous
version) as providing further guidance on the formation of Interface ID's.

As a result, it appears to me that your methodology is not compliant with
either RFC 2464 or 4291. That said, DAD should take care of any operational
problems associated with not using the modified EUI-64. Further, since you
appear to be using 64-bit Interface ID's , all the implementations I have
come across should interoperate with your methodology.

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 Bob
Hinden

Duncan,

> Vijay-
>
> The only thing I could find is that it's just standard practice to use 
> FF FE.. For example, if you use privacy extensions then there is no FF 
> FE because its address is hashed right?

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

> I think it's just a 16 bit filler for a MAC 48..  See below from the 
> IEEE:
>

The FFEE is used to extend an EUI-48 to an EUI-64.  It is defined in the
Section titled "Encapsulated EUI-48 values".  Namely, "A unique
EUI-64 value is generated by concatenating the company_id, an FFFE valued
label, and the extension identifier values".

Bob

---

From: "Duncan, Richard J. (Jeremy) CONTRACTOR" <[email-masked]>
Date: Fri, 26 Jun 2009 09:21:54 -0400

Jeff-

Jeremy Duncan

DTRA (BE-BIC)

-----Original Message-----

Vijay et al.,

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

-----Original Message-----

Duncan,

Bob

---

From: Vijayrajan ranganathan <[email-masked]>
Date: Sat, 27 Jun 2009 12:44:06 +0530

Hi Jeffrey,

Reply inline.

> "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."
=> I am not sure this is not the only way I can form a Modified EUI-64
Interface-ID. Agreed that "Links or Nodes with IEEE 802 48-bit MACs"
generally use this method. But I don't think its a MUST. RFC 4291
mentions 2 other types of Modified EUI-64 Interface Identifiers,
"Links with Other Kinds of Identifiers" and "Links without
Identifiers" under "Appendix A: Creating Modified EUI-64 Format
Interface Identifiers". As I am generating only a "Locally unique
Interface-ID", can't I claim to fall under "Links without
Identifiers"? I would think I'd be complaint to RFC 4291.

Further, since you appear to be using 64-bit Interface ID's , all the
implementations I have come across should interoperate with your
methodology.
=> I forgot to mention that I also ensure that the octets "x,y,z,w" I
use is NOT the bit-pattern "FFFE", thereby ensuring that it does not
clash with any autoconf addresses generated in the usual way.

RFC 2464 does'nt say its a "MUST" to generate Modified EUI-64
Interface-ID from IEEE 802 48-bit MAC in order to be complaint. So,
why do you think I would'nt conform to RFC 2464?

Thanks & Regards
Vijay

---

From: Vijayrajan ranganathan <[email-masked]>
Date: Sat, 27 Jun 2009 15:34:46 +0530

Hi Tony,
Reply inline.

> autoconfigured address.

=> I presume that the "u" bit i.e. universal/local bit that indicates the scope
will have its significance in any IEEE EUI-64 identifier. In that case all
IEEE EUI-64 identifiers assigned to IEEE 802.3 MAC interfaces will
have "0" in their
"u" bit and will result in "global" scoped interface-ids. Since my
implementation
generates only "local"scoped interface-ids, I don't think I'll be claiming
any other interface's autoconf address.

My implementation will anyway have to change if and when they move to
EUI-64. Probably I'll then have to hash it to 48-bits. But, for now, my hash
function is the NULL function.

> the mac, hash it then put in your filler.
=> I did consider hashing but due to the unique requirements of my environment,
I've decided to specifically have the MAC address in the Interface-ID.

Thanks & Regards
Vijay