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

Tue May 4 15:15:40 UTC 2021

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 at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

________________________________
From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> on behalf of Saku Ytti <saku at ytti.fi>
Sent: May 4, 2021 01:44
To: Mark Tinka <mark at tinka.africa>
Cc: nanog list <nanog at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210504/e4a2bbc8/attachment.html>