IS-IS and IPv6 LLA next-hop - just Arista, or everyone?

Mailman List Mirror (Read Only)
1

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]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson@merlin.mb.ca
www.merlin.mb.ca

2

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.

3

SROS:
2001:218:0:1000::1/128 Remote ISIS 48d22h13m 18
       fe80::42de:adff:fe98:87e4-"lag1" 25301

4

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

5

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.

6

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

7

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.

8

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.

9

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

10

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.

11

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

12

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.

13

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.