After reading the email thread on <draft-carpenter-6man-ug-00.txt>, the 6man chairs think the sense of the work group is:
1) The "u and g" bits did not end up being as useful as was thought when RFC4291 was standardized. Consequently, we don't think there is any need to continue the notion that an IID with "u" set to 1 means the IID contains a globally unique token. 2) Under the current scheme defined in RFC4291, the "u" bit only means that the node creating the IID asserts that it is globally unique. It is incorrect to make any other assumptions about what is in the IID. The IID should be viewed as opaque by third parties. 3) There isn't any need to change any running code. There isn't any operational problem with the current definition of the "u" and "g" bits. Removing the properties for these bits should only apply to new standards that define new methods to create IIDs. 4) DAD should, of course, continue to be used as is specified. 5) Having <draft-carpenter-6man-ug-00.txt> become a w.g. document to clarify these issues would be useful and we think there is support in the w.g. for this. Bob & Ole 6man chairs p.s. We are reviewing the discussion on <draft-ietf-softwire-4rd> and will send another email on that topic later. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------