IPv6 Interface ID selection

Answered Question
Apr 7th, 2011

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

I have this problem too.
0 votes
Correct Answer by Salman Asadullah about 3 years 1 week ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Cadet Alain Fri, 04/08/2011 - 12:42

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

Correct Answer
Salman Asadullah Mon, 04/11/2011 - 10:51

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

jkirby Mon, 04/11/2011 - 11:19

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.

Actions

Login or Register to take actions

This Discussion

Posted April 7, 2011 at 12:15 PM
Stats:
Replies:3 Avg. Rating:5
Views:904 Votes:0
Shares:0

Related Content

Discussions Leaderboard