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

William Allen Simpson william.allen.simpson at
Thu May 6 00:39:54 UTC 2021

On 5/4/21 11:34 AM, Saku Ytti wrote:
> On Tue, 4 May 2021 at 18:28, Adam Thompson <athompson at> 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.

More information about the NANOG mailing list