IS-IS and IPv6 LLA next-hop - just Arista, or everyone?
Hey, just checking as I don’t have any Cisco or Extreme or Juniper gear running IS-IS to verify myself… On current Arista (7280SR2K) and older Brocade (MLXe) routers, the IPv6 next-hop address in IS-IS seems to always be the link-local address of the neighbour, instead of any manually-assigned address on the interface. I believe this is *not* the case with Cisco, in particular. Not sure about other vendors, I don’t have any handy that can run IS-IS. I don’t appear to have any knobs to control this behaviour, and haven’t found anything related in the docs. Can anyone confirm that Cisco or other vendors does/do not do this (prefer LLA over GUA)? Thanks, -Adam Adam Thompson Consultant, Infrastructure Services [[MERLIN LOGO]]<https://www.merlin.mb.ca/> 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/>
On 5/4/21 03:28, Adam Thompson wrote:
Hey, just checking as I don’t have any Cisco or Extreme or Juniper gear running IS-IS to verify myself…
On current Arista (7280SR2K) and older Brocade (MLXe) routers, the IPv6 next-hop address in IS-IS seems to always be the link-local address of the neighbour, instead of any manually-assigned address on the interface. I believe this is **not** the case with Cisco, in particular. Not sure about other vendors, I don’t have any handy that can run IS-IS. I don’t appear to have any knobs to control this behaviour, and haven’t found anything related in the docs.
Can anyone confirm that Cisco or other vendors does/do not do this (prefer LLA over GUA)?
Junos: 2c0f:feb0::1/128 *[IS-IS/18] 02:43:49, metric 5870 to fe80::1205:caff:fe86:4ac3 via et-4/0/2.0 to fe80::5287:89ff:fef3:25c3 via et-4/0/2.0 to fe80::1205:caff:fe86:4b10 via et-5/0/2.0 > to fe80::5287:89ff:fef3:2610 via et-5/0/2.0 IOS XE: I2 2C0F:FEB0::1/128 [115/6410] via FE80::1205:CAFF:FE86:4AC3, TenGigabitEthernet1/0/0 via FE80::1205:CAFF:FE86:4B10, TenGigabitEthernet0/0/0 via FE80::5287:89FF:FEF3:25C3, TenGigabitEthernet1/0/0 via FE80::5287:89FF:FEF3:2610, TenGigabitEthernet0/0/0 IOS XR: i L2 2c0f:feb0::1/128 [115/5870] via fe80::1205:caff:fe86:4b10, 02:45:22, HundredGigE0/3/0/0 (!) [115/5810] via fe80::f60f:1bff:feb0:75c4, 02:45:22, HundredGigE0/2/0/1 Mark.
On Tue, 4 May 2021 at 07:24, Mark Tinka <mark@tinka.africa> wrote:
Junos:
2c0f:feb0::1/128 *[IS-IS/18] 02:43:49, metric 5870 to fe80::1205:caff:fe86:4ac3 via et-4/0/2.0 to fe80::5287:89ff:fef3:25c3 via et-4/0/2.0 to fe80::1205:caff:fe86:4b10 via et-5/0/2.0 > to fe80::5287:89ff:fef3:2610 via et-5/0/2.0
IOS XE: I2 2C0F:FEB0::1/128 [115/6410] via FE80::1205:CAFF:FE86:4AC3, TenGigabitEthernet1/0/0 via FE80::1205:CAFF:FE86:4B10, TenGigabitEthernet0/0/0 via FE80::5287:89FF:FEF3:25C3, TenGigabitEthernet1/0/0 via FE80::5287:89FF:FEF3:2610, TenGigabitEthernet0/0/0
IOS XR: i L2 2c0f:feb0::1/128 [115/5870] via fe80::1205:caff:fe86:4b10, 02:45:22, HundredGigE0/3/0/0 (!) [115/5810] via fe80::f60f:1bff:feb0:75c4, 02:45:22, HundredGigE0/2/0/1
SROS: 2001:218:0:1000::1/128 Remote ISIS 48d22h13m 18 fe80::42de:adff:fe98:87e4-"lag1" 25301 ---- https://tools.ietf.org/html/rfc5308 For Hello PDUs, the "Interface Address" TLV MUST contain only the link-local IPv6 addresses assigned to the interface that is sending the Hello. For LSPs, the "Interface Address" TLVs MUST contain only the non-link-local IPv6 addresses assigned to the IS. ---- These are hello derived: A:ytti@a04.chcgil09.us.bb# show router isis adjacency r22.chcgil09.us.bb-re0 detail |match Neigh IPv6 Neighbor : fe80::42de:adff:fe98:87e4 IPv4 Neighbor : 129.250.3.205 Vendors do not have the option to use GUA while being RFC5308 compliant. -- ++ytti
Thank you, both! ...that kinda sucks, though. I don't see any rationale in RFC 5308 for why the HELLO packet may only contain the LLA - does anyone know/remember why? (I'm hoping that understanding the rationale will make this an easier pill to swallow.) Obviously this behaviour/requirement is net-new to the IPv6 TLVs, as there's no LLA-cognate in IPv4 (APIPA doesn't count). There is in OSI, I think, but I'm still too sane to read those docs. It makes sense that you would not want LLAs in LSPs, only GUAs, but does that imply that you must use either ULAs or GUAs in order to establish IPv6 routes in IS-IS, in an IPv6 environment? That makes about as much sense to me as forcing LLAs for next-hops. -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Saku Ytti <saku@ytti.fi> Sent: May 4, 2021 01:44 To: Mark Tinka <mark@tinka.africa> Cc: nanog list <nanog@nanog.org> Subject: Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone? On Tue, 4 May 2021 at 07:24, Mark Tinka <mark@tinka.africa> wrote:
Junos:
2c0f:feb0::1/128 *[IS-IS/18] 02:43:49, metric 5870 to fe80::1205:caff:fe86:4ac3 via et-4/0/2.0 to fe80::5287:89ff:fef3:25c3 via et-4/0/2.0 to fe80::1205:caff:fe86:4b10 via et-5/0/2.0 > to fe80::5287:89ff:fef3:2610 via et-5/0/2.0
IOS XE: I2 2C0F:FEB0::1/128 [115/6410] via FE80::1205:CAFF:FE86:4AC3, TenGigabitEthernet1/0/0 via FE80::1205:CAFF:FE86:4B10, TenGigabitEthernet0/0/0 via FE80::5287:89FF:FEF3:25C3, TenGigabitEthernet1/0/0 via FE80::5287:89FF:FEF3:2610, TenGigabitEthernet0/0/0
IOS XR: i L2 2c0f:feb0::1/128 [115/5870] via fe80::1205:caff:fe86:4b10, 02:45:22, HundredGigE0/3/0/0 (!) [115/5810] via fe80::f60f:1bff:feb0:75c4, 02:45:22, HundredGigE0/2/0/1
SROS: 2001:218:0:1000::1/128 Remote ISIS 48d22h13m 18 fe80::42de:adff:fe98:87e4-"lag1" 25301 ---- https://tools.ietf.org/html/rfc5308 For Hello PDUs, the "Interface Address" TLV MUST contain only the link-local IPv6 addresses assigned to the interface that is sending the Hello. For LSPs, the "Interface Address" TLVs MUST contain only the non-link-local IPv6 addresses assigned to the IS. ---- These are hello derived: A:ytti@a04.chcgil09.us.bb# show router isis adjacency r22.chcgil09.us.bb-re0 detail |match Neigh IPv6 Neighbor : fe80::42de:adff:fe98:87e4 IPv4 Neighbor : 129.250.3.205 Vendors do not have the option to use GUA while being RFC5308 compliant. -- ++ytti
On Tue, 4 May 2021 at 18:15, Adam Thompson <athompson@merlin.mb.ca> wrote: Hey Adam,
I don't see any rationale in RFC 5308 for why the HELLO packet may only contain the LLA - does anyone know/remember why? (I'm hoping that understanding the rationale will make this an easier pill to swallow.) Obviously this behaviour/requirement is net-new to the IPv6 TLVs, as there's no LLA-cognate in IPv4 (APIPA doesn't count). There is in OSI, I think, but I'm still too sane to read those docs.
IPv4 link local is 169.254/16, you may have seen them in Windows.
It makes sense that you would not want LLAs in LSPs, only GUAs, but does that imply that you must use either ULAs or GUAs in order to establish IPv6 routes in IS-IS, in an IPv6 environment? That makes about as much sense to me as forcing LLAs for next-hops.
The list may benefit from the context you have, it is not obvious to me why you'd want anything but LLA. -- ++ytti
I don't believe APIPA and Link-Local are precisely equivalent, but I agree it's the closest thing IPv4 has. IS-IS/IPv4 would presumably use APIPA addresses if nothing else were assigned to the interface, based on my reading of the RFC. I'm unsure what the RFC authors think should happen in a HELLO packet when the interface has multiple IPv4 addresses, but none of that is my problem here. I don't like LLAs because they are - intrinsically - meaningless. In the context of my L3 core, I know that for any subnet, .1/::1 is such-and-such a router, .2/::2 is that one, .3/::3, is the other one, etc., etc. (Yes, I have a very small & topologically simple L3 core. Let's not talk about L2!) When I look at my IPv4 routing table, I know which next-hop is which just by looking at it, and I can spot anomalies very easily. When I look at my IPv6 routing table, the next-hops are all... well... gibberish, at least to me. My experience is that LLAs are not durable, so memorizing them is not IMHO a useful task. Figuring out an (IS-IS) IPv6 route currently involves a couple of extra steps to locate the LLA's interface route, find the MAC address of that LLA on that link, and then identify the router from its MAC address. Am I missing something obvious? Thanks! -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: Saku Ytti <saku@ytti.fi> Sent: May 4, 2021 10:20 To: Adam Thompson <athompson@merlin.mb.ca> Cc: Mark Tinka <mark@tinka.africa>; nanog <nanog@nanog.org> Subject: Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone? On Tue, 4 May 2021 at 18:15, Adam Thompson <athompson@merlin.mb.ca> wrote: Hey Adam,
I don't see any rationale in RFC 5308 for why the HELLO packet may only contain the LLA - does anyone know/remember why? (I'm hoping that understanding the rationale will make this an easier pill to swallow.) Obviously this behaviour/requirement is net-new to the IPv6 TLVs, as there's no LLA-cognate in IPv4 (APIPA doesn't count). There is in OSI, I think, but I'm still too sane to read those docs.
IPv4 link local is 169.254/16, you may have seen them in Windows.
It makes sense that you would not want LLAs in LSPs, only GUAs, but does that imply that you must use either ULAs or GUAs in order to establish IPv6 routes in IS-IS, in an IPv6 environment? That makes about as much sense to me as forcing LLAs for next-hops.
The list may benefit from the context you have, it is not obvious to me why you'd want anything but LLA. -- ++ytti
On Tue, 4 May 2021 at 18:28, Adam Thompson <athompson@merlin.mb.ca> wrote:
I don't believe APIPA and Link-Local are precisely equivalent, but I agree it's the closest thing IPv4 has. IS-IS/IPv4 would
Agreed, APIPA is using link-local, but they're not the same. APIPA is an application or process which needs the use of link-local addresses.
presumably use APIPA addresses if nothing else were assigned to the interface, based on my reading of the RFC. I'm unsure what the RFC authors think should happen in a HELLO packet when the interface has multiple IPv4 addresses, but none of that is my problem here.
I doubt that it is implemented in such a way, but would be cute.
I don't like LLAs because they are - intrinsically - meaningless. In the context of my L3 core, I know that for any subnet, .1/::1 is such-and-such a router, .2/::2 is that one, .3/::3, is the other one, etc., etc. (Yes, I have a very small & topologically simple L3 core. Let's not talk about L2!) When I look at my IPv4 routing table, I know which next-hop is which just by looking at it, and I can spot anomalies very easily.
When I look at my IPv6 routing table, the next-hops are all... well... gibberish, at least to me. My experience is that LLAs are not durable, so memorizing them is not IMHO a useful task. Figuring out an (IS-IS) IPv6 route currently involves a couple of extra steps to locate the LLA's interface route, find the MAC address of that LLA on that link, and then identify the router from its MAC address.
Am I missing something obvious?
I don't think you are, I read like an opinion piece so it's inherently not right or wrong. I don't have the same experience and I consider forcing LLA a blessing in limiting attack vectors and I personally don't see downsides as all addresses are gibbering to me, as my working memory contains very few digits. I wish ND had mandated LLA too, so many customer tickets due to poorly configured filters due to misunderstanding how ND works. -- ++ytti
On 5/4/21 17:34, Saku Ytti wrote:
I don't think you are, I read like an opinion piece so it's inherently not right or wrong. I don't have the same experience and I consider forcing LLA a blessing in limiting attack vectors and I personally don't see downsides as all addresses are gibbering to me, as my working memory contains very few digits. I wish ND had mandated LLA too, so many customer tickets due to poorly configured filters due to misunderstanding how ND works.
I agree - this may be one of those "six-and-half-a-dozen" scenarios. When I had a smaller network there was meaning in what IPv4 addresses I assigned, i.e., I could look at them and figure out which port on which router. As I built larger networks, I suppose I had bigger problems than that, and relied on other tools to help me with reverse look-up (DNS, IPAM, an NMS, old notes that were probably half eaten by rats, e.t.c.). I really haven't bothered to look into the history that brought us here, but to me, LLA for an IGP makes sense. Would I have minded if it was GUA... probably not. But I'm pretty okay with where we are at as a community, in this respect. Mark.
I did an L3VPN over SRv6 test recently using IS-IS as the IGP. I thought it was quite cool that I didn't configure any IPv6 addressing at all in the core... simply enabled v6 on interfaces and allowed FE80 LL's to run... IS-IS neighbored up... then added a mp-ibgp v6 loopback (rfc 4193) to the PE's and let BGP neighbor up... L3VPN worked over SRv6 (of course with all that weird (new) locator magic). But, point is, LL FE80's worked nice. Yeah, less attack surface... I always say, you can't attack what you can't reach -Aaron
hey,
I did an L3VPN over SRv6 test recently using IS-IS as the IGP. I thought it was quite cool that I didn't configure any IPv6 addressing at all in the core... simply enabled v6 on interfaces and allowed FE80 LL's to run... IS-IS neighbored up... then added a mp-ibgp v6 loopback (rfc 4193) to the PE's and let BGP neighbor up... L3VPN worked over SRv6 (of course with all that weird (new) locator magic).
For less adventurous - you can also do unnumbered ISIS or OSPF. It works equally as good and enables one to do plug-and-play SR-MPLS like you would do layer-2 network. -- tarko
On 5/4/21 11:34 AM, Saku Ytti wrote:
On Tue, 4 May 2021 at 18:28, Adam Thompson <athompson@merlin.mb.ca> wrote:
When I look at my IPv6 routing table, the next-hops are all... well... gibberish, at least to me. My experience is that LLAs are not durable, so memorizing them is not IMHO a useful task. Figuring out an (IS-IS) IPv6 route currently involves a couple of extra steps to locate the LLA's interface route, find the MAC address of that LLA on that link, and then identify the router from its MAC address.
Am I missing something obvious?
I don't think you are, I read like an opinion piece so it's inherently not right or wrong. I don't have the same experience and I consider forcing LLA a blessing in limiting attack vectors and I personally don't see downsides as all addresses are gibbering to me, as my working memory contains very few digits. I wish ND had mandated LLA too, so many customer tickets due to poorly configured filters due to misunderstanding how ND works.
Sadly, all 128-bit IPv6 addresses are gibberish. The original IPv6 design specified the upper 32 bits as the ASN, the lower 32 to match the subnetting of IPv4. I'd even specified an alternative representation to Karn's notation (called Simpson's notation), so that the IPv4 and IPv6 matched! Karn's notation: x.x.x.x/24 compared to ::xxxx:xxxx/56 Simpson's notation: x.x.x.x//8 matching ::xxxx:xxxx//8 All that went out the window with the IESG decision to override our 64-bit design and specify 128-bit addresses with no topological prefix. The IESG didn't have any operators on it. OTOH, I was the pioneer of the RFC *Operational* Considerations section (and an early operator). Link Local Addresses are/were intended to be durable. They are/were statically based upon a physical constant, such as the interface MAC. IPv6 globally routed addresses are/were intended to change every day. One of my drafts indicated that IANA would test changing a leading ASN at least once per month, ensuring that software properly handled it. Neighbor Discovery was intended to use the stable Link Local Address. Neighbor and Router Discovery were intended to be authenticated. You shouldn't allow some random device to be attached to your network. You shouldn't authenticate some unknown interface address. And you shouldn't communicate via some router that cannot demonstrate verification of your per interface secret. Also you shouldn't assign a globally routable address to any unauthenticated device. All that went out the window with the IESG decision.... Remember the vocal resistance (screaming) in the DHCP WG meeting? Configuring a secret key for each interface is just too hard. (Eventually, various countries required every device to have a secret, printed on the label along with the model and serial number.) Configuring a public key for every ASN is just too hard. Configuring a public key for every Domain Name is just too hard.
LOLOLOL. “%VXLAN-4-IPV6_UNDERLAY_UNSUPPORTED: VXLAN encapsulation using IPv6 VTEP addresses is not supported on this platform” Guess it’s going to be a non-issue for me, at this time, since VxLAN was the main reason for this entire setup… Thanks for all the responses! -Adam Adam Thompson Consultant, Infrastructure Services [[MERLIN LOGO]]<https://www.merlin.mb.ca/> 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Adam Thompson Sent: Tuesday, May 4, 2021 10:29 AM To: Saku Ytti <saku@ytti.fi> Cc: nanog <nanog@nanog.org> Subject: Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone? I don't believe APIPA and Link-Local are precisely equivalent, but I agree it's the closest thing IPv4 has. IS-IS/IPv4 would presumably use APIPA addresses if nothing else were assigned to the interface, based on my reading of the RFC. I'm unsure what the RFC authors think should happen in a HELLO packet when the interface has multiple IPv4 addresses, but none of that is my problem here. I don't like LLAs because they are - intrinsically - meaningless. In the context of my L3 core, I know that for any subnet, .1/::1 is such-and-such a router, .2/::2 is that one, .3/::3, is the other one, etc., etc. (Yes, I have a very small & topologically simple L3 core. Let's not talk about L2!) When I look at my IPv4 routing table, I know which next-hop is which just by looking at it, and I can spot anomalies very easily. When I look at my IPv6 routing table, the next-hops are all... well... gibberish, at least to me. My experience is that LLAs are not durable, so memorizing them is not IMHO a useful task. Figuring out an (IS-IS) IPv6 route currently involves a couple of extra steps to locate the LLA's interface route, find the MAC address of that LLA on that link, and then identify the router from its MAC address. Am I missing something obvious? Thanks! -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: Saku Ytti <saku@ytti.fi<mailto:saku@ytti.fi>> Sent: May 4, 2021 10:20 To: Adam Thompson <athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca>> Cc: Mark Tinka <mark@tinka.africa<mailto:mark@tinka.africa>>; nanog <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone? On Tue, 4 May 2021 at 18:15, Adam Thompson <athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca>> wrote: Hey Adam,
I don't see any rationale in RFC 5308 for why the HELLO packet may only contain the LLA - does anyone know/remember why? (I'm hoping that understanding the rationale will make this an easier pill to swallow.) Obviously this behaviour/requirement is net-new to the IPv6 TLVs, as there's no LLA-cognate in IPv4 (APIPA doesn't count). There is in OSI, I think, but I'm still too sane to read those docs.
IPv4 link local is 169.254/16, you may have seen them in Windows.
It makes sense that you would not want LLAs in LSPs, only GUAs, but does that imply that you must use either ULAs or GUAs in order to establish IPv6 routes in IS-IS, in an IPv6 environment? That makes about as much sense to me as forcing LLAs for next-hops.
The list may benefit from the context you have, it is not obvious to me why you'd want anything but LLA. -- ++ytti
On 5/4/21 21:07, Adam Thompson wrote:
LOLOLOL.
“%VXLAN-4-IPV6_UNDERLAY_UNSUPPORTED: VXLAN encapsulation using IPv6 VTEP addresses is not supported on this platform”
Guess it’s going to be a non-issue for me, at this time, since VxLAN was the main reason for this entire setup…
Thanks for all the responses!
https://tools.ietf.org/html/rfc7439 Doesn't speak to VXLAN (and is MPLS), but the problem is the same. IPv6-only networks that want to tunnel services will continue to struggle, as parity from a vendor standpoint is sorely lacking. Mark.
participants (6)
-
aaron1＠gvtc.com -
Adam Thompson -
Mark Tinka -
Saku Ytti -
Tarko Tikan -
William Allen Simpson