Thanks Tim, Fernando, We’ll move forward with this text.
Thanks, Acee > On Mar 5, 2023, at 5:08 AM, Tim Chown <tim.ch...@jisc.ac.uk> wrote: > > 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 <acee.i...@gmail.com> 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 <fg...@si6networks.com> 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: fg...@si6networks.com >>> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
