> Brian E Carpenter <mailto:brian.e.carpen...@gmail.com> > 3 May 2013 22:16 > > Exactly. I think that draft-ietf-6man-ug clarifies this to some extent, > as a side-effect of clarifying the U/G bits. Would it be useful to add > an extra sentence in that draft, simply stating that a number of > independent methods for forming an IID can exist? > > Brian Yes.
I think there's potentially a number of things to consider clarifying : 1) There may be multiple independent methods for forming an IID. 2) These methods SHOULD NOT assume any exclusivity, either on a per link, per interface, or per prefix basis. 3) DAD is the recognised mechanism for testing whether a unicast address is unique. 4) I have a question regarding existing RFC4862 implementations, and a very unlikely chain of events. Quote: draft-ietf-6man-ug states "Specifications of other forms of 64-bit IID MUST specify how all 64 bits are set, but need not treat the "u" and "g" bits in any special way." OK current text of draft-ietf-6man-stable-privacy-addresses is compliant with that. What happens in the unlikely event that these new mechanisms for creating an IID (such as draft-ietf-6man-stable-privacy-addresses) and which ignore setting u/g bits, cause a DAD clash with existing link-local addresses created compliant to RFC 4862 (IPv6 Stateless Address Autoconfiguration) especially regarding Section 5.4.5 (When Duplicate Address Detection Fails), which DOES rely on the u bit? 4862 states: "On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued." How would the node using 4862+4291 know the difference whether the duplicate was caused by another node running 4862+4291 with a duplicate MAC/EUI-64 hardware address, or because of draft-ietf-6man-stable-privacy-addresses or some other mechanism? Presumably by checking the incoming DAD probe NS packet to check if the transform of the EUI-64 / link-layer hardware source address matches the interface identifier stripped from the Target Address? Do all existing 4862 implementations perform this check before disabling IPv6 processing on the interface? I think that this additional check is a candidate for a SHOULD, rather than a MAY, and also needs highlighting in draft-ietf-6man-ug . regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
