Re: [v6ops] I-D Action: draft-link-v6ops-gulla-00.txt

[Vasilenko Eduard <[e-mail]>]

Hi Mark, Thanks. Good text to have it in this draft.
Actually, EUI-64 for routers is so good surface for attack that pushing vendors out of it – is a value by itself.
Eduard
From: Mark Smith [mailto:[e-mail]]
Sent: Thursday, November 9, 2023 11:41 AM
To: Vasilenko Eduard <[e-mail]>
Cc: IPv6 Operations <[e-mail]>
Subject: Re: [v6ops] I-D Action: draft-link-v6ops-gulla-00.txt


On Thu, 9 Nov 2023, 17:54 Vasilenko Eduard, <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
Hi all,
The idea has a few drawbacks that should be better documented:
1. Changing router LLA would effectively clear the ND cache on all hosts. It Is not a big problem because PIO->LLA should not change very often.
2. Should the router listen and respond to the old LLA? How long?
3. Vendors still using EUI-64 for LLA. They could not attach so many MAC addresses for EUI-64. It should be stated clearly that they SHOULD move out of EUI-64 for this feature to work.

EUI-64s for IPv6 addresses, including for LLAs, have been obsolete since RFC 8064, which is updating specifications to use RFC 7217.

RFC 7217 is intended to be used for LLAs generally, however specifically they're in RFC 7217 to decouple router LLAs from an interface MAC address, so that e.g. a router interface module could be replaced, with the new one having a different MAC address, and the router's LLA wouldn't change.

Previous to RFC 7217, people were manually setting static router interface LLAs to achieve this MAC address independence.



4. I am not happy that "some hash function or whatever" could be used for LLA generation. Why not RECOMMEND algorithm from RFC 8981 - it uses many more parameters for the hash function (they are needed).

I have a question about this optimistic statement:
>Link-local address LLA_A is not reachable anymore, as the host changes the network attachement point. Neighbor Unreachability Detection ([RFC4861]) detects it and removes LLA_A from the list of default routers.

As I understand, in the case of a router, hosts would not send traffic directly to the host.
Hence, blackholing would continue up to 900s till the respective number of RAs would be not received.
If this is the case, then a 450s average outage is not a good mechanism.
Eduard
>
> On 07-Nov-23 14:34, [e-mail]<mailto:[e-mail]> wrote:
> > Internet-Draft draft-link-v6ops-gulla-00.txt is now available.
> >
> >     Title:   Using Subnet-Specific Link-Local Addresses to Improve SLAAC
> Robustness
> >     Author:  Jen Linkova
> >     Name:    draft-link-v6ops-gulla-00.txt
> >     Pages:   7
> >     Dates:   2023-11-06
> >
> > Abstract:
> >
> >     This document suggests that a link-local address used by a router as
> >     a source address for Router Advertisement packets is calculated as a
> >     function of prefixes listed in the Prefix Information Option of the
> >     Router Advertisement.  The proposed approach, combined with the Rule
> >     5.5 of the Default Source Address Selection algorithm (RFC6724)
> >     improves the robustness of the SLAAC by allowing the hosts to detect
> >     the IPv6 subnet changes much faster and select the correct source
> >     address.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-link-v6ops-gulla/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-link-v6ops-gulla-00.html
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops