jkirby at datawareservices
Apr 11, 2011, 11:41 AM
Post #8 of 8
(863 views)
Permalink
|
Sorry for such a late response to this thread but the posts have been puzzling me for some time. After much unfruitful research I posted the 5 rules to Cisco's support community for input. The response was that in practice these rules (except the first one) can be ignored in nearly all situations. In the few situations where one of these rules may apply the designer/engineer should also have access to all IDs on the network and would need to knowingly create a conflict. The thread can be found at:
https://supportforums.cisco.com/message/3334900
The entire response below. Answers from Cisco's Salman Asadullah are prefaced with "++". I'd appreciate any comments on his response.
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.
++ 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.
--
Jim Kirby
Director of Engineering
Dataware Services
main: 605.336.0820 x368
fax: 605.336.0228
On Dec 20, 2010, at 1:50 AM, Chad Kissinger wrote:
> Well, no other input yet, but through RFC 5375, I have compiled the following:
>
> In manually choosing a 64 bit IPV6 Interface ID, you should follow the following rules (stated in terms of hexadecimal choices):
>
> 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)
>
>
> Any other input? Corrections?
>
>
>
> chad kissinger | founder-vp | onramp access, llc
> p: 512.322.9200 | f: 512.476.2878 | www.onr.com
> your internet operations | built | deployed | managed
|
