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
--------------------------------------------------------------------

Reply via email to