Hi, Thanks for this proposal Acee.
I would support [2] below. While most OS vendors/implementors have caught up with 8064/7217, router vendors maybe haven’t so much, so I’d argue it’s worth being explicit to inform them when implementing. Tim > On 4 Mar 2023, at 11:21, Acee Lindem <[email protected]> wrote: > > Hi Fernando, Tim, > > Tim Chown had a similar comment so I’m adding him. > > I see that we have two alternatives to correct this: > > 1. Remove section 7.4 altogether. > 2. Replace the first paragraph with: > > [RFC8064] specifies that [RFC7217] be used as the default > scheme for generating stable address in IPv6 Stateless Address > Autoconfiguration (SLAAC) [RFC4862]. The virtual router MAC > MUST not be used for the Net_Iface parameter used for the > Interface Identifier (IID) derivation algorithms in [RFC7217] and > [RFC8981]. > > Thanks, > Acee > > > >> On Mar 4, 2023, at 5:04 AM, Fernando Gont <[email protected]> wrote: >> >> Folks, >> >> Some comments on draft-ietf-rtgwg-vrrp-rfc5798bis. >> >> Section 7.4 says: >> ---- cut here ---- >> 7.4. IPv6 Interface Identifiers >> >> IPv6 routers running VRRP MUST create their Interface Identifiers in >> the normal manner, i.e., "Transmission of IPv6 Packets over Ethernet >> Networks" [RFC2464]. They MUST NOT use the virtual router MAC >> address to create the Modified Extended Unique Identifier (EUI)-64 >> identifiers. >> >> This VRRP specification describes how to advertise and resolve the >> VRRP router's IPv6 link-local address and other associated IPv6 >> addresses into the virtual router MAC address. >> ---- cut here ---- >> >> >> This text is non-compliant with RFC8064, which very explicitly says: >> >> ---- cut here ---- >> 3. Generation of IPv6 Interface Identifiers with SLAAC >> >> Nodes SHOULD implement and employ [RFC7217] as the default scheme for >> generating stable IPv6 addresses with SLAAC. A link layer MAY also >> define a mechanism for stable IPv6 address generation that is more >> efficient and does not address the security and privacy >> considerations discussed in Section 1. The choice of whether or not >> to enable the security- and privacy-preserving mechanism SHOULD be >> configurable in such a case. >> >> By default, nodes SHOULD NOT employ IPv6 address generation schemes >> that embed a stable link-layer address in the IID. In particular, >> this document RECOMMENDS that nodes do not generate stable IIDs with >> the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], >> [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], >> [RFC4391], [RFC5072], and [RFC5121]. >> ---- cut here ---- >> >> >> Thanks! >> >> Regards, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: [email protected] >> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
