Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
5098
Views
5
Helpful
3
Replies

IPv6 Interface ID selection

Go to solution
jkirby
Level 1
Level 1

‎04-07-2011 12:15 PM - edited ‎03-01-2019 05:26 PM

Regarding the selection of interface IDs for IPv6 I came across these rules the other day while reading a forum (HE.net or ipv6.ops list):

1.  Do not use all 0s. (interferes with Router Anycast)

2.  Do not use all 0s with one character at the end (interferes with Embedded-RP RFC 3956)

3.  Do not use all Fs followed by 80 through FF  I.e. do not use FFFF:FFFF:FFFF:FF80 through

FFFF:FFFF:FFFF:FFFF (interferes with Anycast)

4.  Do not use something that begins with 0000:5EFE (interferes with ISATAP RFC5214)

5.  The second hexadecimal character of the 64 bit Interface ID must be 0, 4, 8 or C i.e. X8XX:XXXX:XXXX:XXXX

where the 8 can be replaced with 0, 4 or C (71st and 72nd bit set to 0)

I've gone through the manuals and my notes from the IPv6FD class but didnt' find anything like this.  I can understand rules 1,3 and 4.  But I have problems with rules 2 and 5.  Why not use all 0's with one character at the end, especially since these types of addresses are given in nearly every example on CCO.  Specifically, what's wrong with a unicast address like:  2001:db8::1/64 ?

Siilarly with rule 5, if setting this character is mandatory, why do no examples do it?

Thanks,

jk

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
Salman Asadullah
Cisco Employee
Cisco Employee

‎04-11-2011 10:51 AM

Hi JK,

Please see the response below:

Regarding the selection of interface IDs for IPv6 I came across these rules the other day while reading a forum (HE.net or ipv6.ops list):

1.  Do not use all 0s. (interferes with Router Anycast)

++ Correct, but there may be cases where you actually want to configure the subnet router Anycast address on a router. "ipv6 address 2001:db8::/64 anycast"

2.  Do not use all 0s with one character at the end (interferes with Embedded-RP RFC 3956)

++ Not correct. "2001:db8::1" is a perfectly fine IPv6 address to use, and 'conflict' with 3956 would only be an issue if they chose to configure an embedded RP address on that /64.That's completely under control of the operator. So just pick another /64 for embedded RPs.

3.  Do not use all Fs followed by 80 through FF  I.e. do not use FFFF:FFFF:FFFF:FF80 through FFFF:FFFF:FFFF:FFFF (interferes with Anycast)

++ Well, possibly. There is a reserved Anycast range in the interface-id space however again the /64 has to be setup to use that, so in a normal /64 link that's not an issue. Really nothing one has to worry about either.

4.  Do not use something that begins with 0000:5EFE (interferes with ISATAP RFC5214)

++ It doesn't interfere, however some implementations pretty prints 'ISATAP' addresses. Note that if they use EUI-64 identifiers, then ISATAP has a separate reservation in OUI space, so no implementation would generate this. No practical consequence if that bit string is used though, only for pretty printing.

5.  The second hexadecimal character of the 64 bit Interface ID must be 0, 4, 8 or C i.e. X8XX:XXXX:XXXX:XXXX where the 8 can be replaced with 0, 4 or C (71st and 72nd bit set to 0)

++ See text from RFC4291 below. The use of u/g bits came after discussions about the 8+8/GSE proposals. I don't know if the more modern versions (ILNP) depend on this property or not. In any case for _existing_ implementations the setting of those bits does not matter. There are no implementations that interpret the interface-ids.

I've gone through the manuals and my notes from the IPv6FD class but didnt' find anything like this.  I can understand rules 1,3 and 4.  But I have problems with rules 2 and 5.  Why not use all 0's with one character at the end, especially since these types of addresses are given in nearly every example on CCO.  Specifically, what's wrong with a unicast address like:  2001:db8::1/64 ?

Siilarly with rule 5, if setting this character is mandatory, why do no examples do it?

++ There is a combination of RFCs, see RFC429, that has the following excerpt:

   "IPv6 nodes are not required to validate that interface identifiers

   created with modified EUI-64 tokens with the "u" bit set to universal

   are unique.

   The use of the universal/local bit in the Modified EUI-64 format

   identifier is to allow development of future technology that can take

   advantage of interface identifiers with universal scope."

I wouldn't call these "rules" or take them too literary if I were you.

Enjoy the IPv6 rollout!

Regards,

Salman

View solution in original post

3 Replies 3

Go to solution
cadet alain
VIP Alumni
VIP Alumni

‎04-08-2011 12:42 PM

Hi,


point 3: I thought an anycast address is the same as unicast but configured on different devices and in fact on Cisco routers you must tell that this is an anycast address otherwise how would he know.

point5: then when the MAC address used to derive EUI-64 has a different value how does he do?

Regards.

Alain

Don't forget to rate helpful posts.
0 Helpful

Go to solution
Salman Asadullah
Cisco Employee
Cisco Employee

‎04-11-2011 10:51 AM

Hi JK,

Please see the response below:

Regarding the selection of interface IDs for IPv6 I came across these rules the other day while reading a forum (HE.net or ipv6.ops list):

1.  Do not use all 0s. (interferes with Router Anycast)

++ Correct, but there may be cases where you actually want to configure the subnet router Anycast address on a router. "ipv6 address 2001:db8::/64 anycast"

2.  Do not use all 0s with one character at the end (interferes with Embedded-RP RFC 3956)

++ Not correct. "2001:db8::1" is a perfectly fine IPv6 address to use, and 'conflict' with 3956 would only be an issue if they chose to configure an embedded RP address on that /64.That's completely under control of the operator. So just pick another /64 for embedded RPs.

3.  Do not use all Fs followed by 80 through FF  I.e. do not use FFFF:FFFF:FFFF:FF80 through FFFF:FFFF:FFFF:FFFF (interferes with Anycast)

++ Well, possibly. There is a reserved Anycast range in the interface-id space however again the /64 has to be setup to use that, so in a normal /64 link that's not an issue. Really nothing one has to worry about either.

4.  Do not use something that begins with 0000:5EFE (interferes with ISATAP RFC5214)

++ It doesn't interfere, however some implementations pretty prints 'ISATAP' addresses. Note that if they use EUI-64 identifiers, then ISATAP has a separate reservation in OUI space, so no implementation would generate this. No practical consequence if that bit string is used though, only for pretty printing.

5.  The second hexadecimal character of the 64 bit Interface ID must be 0, 4, 8 or C i.e. X8XX:XXXX:XXXX:XXXX where the 8 can be replaced with 0, 4 or C (71st and 72nd bit set to 0)

++ See text from RFC4291 below. The use of u/g bits came after discussions about the 8+8/GSE proposals. I don't know if the more modern versions (ILNP) depend on this property or not. In any case for _existing_ implementations the setting of those bits does not matter. There are no implementations that interpret the interface-ids.

I've gone through the manuals and my notes from the IPv6FD class but didnt' find anything like this.  I can understand rules 1,3 and 4.  But I have problems with rules 2 and 5.  Why not use all 0's with one character at the end, especially since these types of addresses are given in nearly every example on CCO.  Specifically, what's wrong with a unicast address like:  2001:db8::1/64 ?

Siilarly with rule 5, if setting this character is mandatory, why do no examples do it?

++ There is a combination of RFCs, see RFC429, that has the following excerpt:

   "IPv6 nodes are not required to validate that interface identifiers

   created with modified EUI-64 tokens with the "u" bit set to universal

   are unique.

   The use of the universal/local bit in the Modified EUI-64 format

   identifier is to allow development of future technology that can take

   advantage of interface identifiers with universal scope."

I wouldn't call these "rules" or take them too literary if I were you.

Enjoy the IPv6 rollout!

Regards,

Salman

Go to solution
jkirby
Level 1
Level 1
In response to Salman Asadullah

‎04-11-2011 11:19 AM

Wow, that's exactly the kind of answer I was hoping for.  As with many other IPv6 "rules" I've come across in this deployment, they are either depricated, unused, ignored or otherwise null.  Kind of like NAT-PT.  You still see questions, and answers *sigh*, but in reality it's depriocated and can be safely ignored.

Thanks for the very good information.

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents