At Thu, 18 Jul 2013 15:11:00 -0700, Bob Hinden <[email protected]> wrote:
> This message starts a two week 6MAN Working Group on advancing: > > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 > > http://tools.ietf.org/html/draft-ietf-6man-ug-01 > > as a Proposed Standard. I think this draft is generally well written and good to be advanced (although I personally don't have a strong opinion on what's proposed in the draft). I have one comment that may improve the clarity of the document: the latter half of Section 4 is not very understandable to me: There is one case in RFC 4862 that requires additional consideration: "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." However, as mentioned above, some methods of IID formation might produce IID values with "u" = "g" = 0 that are not based on a MAC (hardware) address. With very low probability, such a value might collide with an IID based on a MAC address. There is no algorithm for determining whether this case has arisen, rather than a genuine MAC address collision. Implementers should carefully consider the consequences of continuing IPv6 operation on the interface in this unlikely situation. First, as already noted in this thread, the notation of '"u" = "g" = 0' is confusing and should better be clarified. I guess the intent is "IID values whose position 6 is 1 and position 7 is 0". But then...I'm still not really sure what this paragraph tries to suggest. Is it talking about something like this? - A node N creates an IID not based on a MAC address but its position 6 is 1 and position 7 is 0. - Node N then creates a link-local address using the IID, and performs DAD, which detects a duplicate. - The other address that collides with N's address might be created from a MAC address (name it "MAC1") - And, it might also be possible that N's MAC address is actually MAC1. (So, even if N's IID was not created on that MAC address, the result would have been the same). - Since we cannot eliminate this possibility, we should be careful before continuing IP(v6) operation (as allowed with MAY by RFC 4862, since this link-local address was "not created based on the MAC address"). If so...I don't see much point in noting that explicitly. The main intent of this part of RFC 4862 was that if a link-local address created based on a MAC address is detected to be a duplicate, that very strongly suggests there's MAC address collision, and it's better to take some specific action (i.e, disabling the IP operation). In all other cases, the IP address duplicate may or may not be because of MAC address collision, and since there's no strong indication of MAC address collision, RFC 4862 leaves it to the implementor (hence the MAY). There's always a possibility that duplicated IP address identified via DAD is actually because of duplicate MAC address, even if the way of creating the IID does not directly suggest so. In that sense it wouldn't be bad to raise consideration on the consequence of continuing the IP operation after a duplicate address is detected. But, that doesn't seem to be very specific to the context of the ug bit discussion. And, recalling the original intent of RFC 4862, explicitly mentioning the obvious sounds a bit awkward to me and even tries to update the sense of the RFC. So, unless that (updating RFC 4862 in addition 4291) is the point of this paragraph(s), my first suggestion is simply remove it. If the intent is to update RFC 4862, I think the draft needs to explicitly say so. And, at least the description should be clearer (at least to me it was very difficult to understand what it tries to say). --- JINMEI, Tatuya On Thu, Jul 18, 2013 at 3:14 PM, Bob Hinden <[email protected]> wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ext-transmit-01.txt > Pages : 9 > Date : 2013-05-29 > > http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 > > as a Proposed Standard. Substantive comments and statements of support for > advancing this document should be directed to the mailing list. Editorial > suggestions can be sent to the author. This last call will end on 1 August > 2013. > > The chairs would also like to solicit a few people to do a detailed review of > this document. Please contact the chairs directly. > > Regards, > > Bob Hinden & Ole Trøan > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
