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