cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3602
Views
15
Helpful
2
Replies

IPv6 Link-Local Address Space

sakar
Level 1
Level 1

This question might be redundant of https://supportforums.cisco.com/t5/lan-switching-and-routing/ipv6-link-local-address-issue/td-p/2692397 But I have not got a definitive answer.

 

RFC4291 section 2.4 states FE80::/10 as Link-Local address space which would mean addresses from FE80:: through FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

But, section 2.5.6 restricts Link-Local address as FE80::/64 which would mean addresses from FE80:: through FE80::FFFF:FFFF:FFFF:FFFF

However, Cisco IOS allows manual Link-Local address configuration from the whole address space FE80::/10

Cisco Support Community: https://supportforums.cisco.com/…/ipv6-link-lo…/td-p/2692397

RFC Errata: http://www.rfc-editor.org/errata_search.php…

After reading above two threads seems like Cisco is getting Link-Local addressing wrong? How do other vendors handle Link-Local addressing? Or, is there an error in RFC?

 

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello Sakar,

I remember that thread :)

You may have noted that my erratum for RFC4291 was rejected. The explanation I got back was that while the entire fe80::/10 range was reserved for link-local unicast, currently, the link-local addresses have a fixed format of fe80::/64 prefix plus the 64-bit interface ID, with the inner 54 bits fixed at 0. It appears that the rest of the address space is set aside for future use, if there is ever going to be any.

Admittedly, Cisco IOS is much more permissive in what link-local IPv6 address it accepts - indeed, it accepts anything falling into the fe80::/10 range. This way, IOS is truly not 100% abiding by RFC4291. However, quickly checking on my Linux (kernel 4.17), the behavior is exactly the same; the OS is happy with accepting just about any fe80::/10 address as a link-local address.

I would personally say the current implementations seem to accept the entire fe80::/10 range as a link-local address range, even though if you want to be 100% compliant with RFC4291, you should assign your IPv6 link-local addresses from the fe80::/64 range.

I hope this helps at least a little.

Best regards,
Peter

View solution in original post

2 Replies 2

Peter Paluch
Cisco Employee
Cisco Employee

Hello Sakar,

I remember that thread :)

You may have noted that my erratum for RFC4291 was rejected. The explanation I got back was that while the entire fe80::/10 range was reserved for link-local unicast, currently, the link-local addresses have a fixed format of fe80::/64 prefix plus the 64-bit interface ID, with the inner 54 bits fixed at 0. It appears that the rest of the address space is set aside for future use, if there is ever going to be any.

Admittedly, Cisco IOS is much more permissive in what link-local IPv6 address it accepts - indeed, it accepts anything falling into the fe80::/10 range. This way, IOS is truly not 100% abiding by RFC4291. However, quickly checking on my Linux (kernel 4.17), the behavior is exactly the same; the OS is happy with accepting just about any fe80::/10 address as a link-local address.

I would personally say the current implementations seem to accept the entire fe80::/10 range as a link-local address range, even though if you want to be 100% compliant with RFC4291, you should assign your IPv6 link-local addresses from the fe80::/64 range.

I hope this helps at least a little.

Best regards,
Peter

Hello.

Please, be aware that BSDs will not work with fe80::/10. The problem occurs because BSDs assume fe80::/64 and the second word is used internally for state management. This is an implementation details, but it makes BSDs incompatible with Cisco if they are not following the RFC.

Source: https://github.com/kame/kame/blob/master/IMPLEMENTATION#L475

RFC4291 MUST be followed regarding this otherwise BSDs will silently drop packets not in the fe80::/64 range