On 23/07/2013 12:28, JINMEI Tatuya wrote: > At Thu, 18 Jul 2013 15:11:00 -0700,
... > 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." To be honest, I have great difficulty understanding this sentence, because I can't imagine any case in which continuing operation would be OK. It seems to me that disaster is guaranteed. However, somebody in the WG asked us to discuss this case. > 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. That's the intended meaning. As I said, somebody asked us to discuss it. If the WG agrees with you, we can remove it. > > 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). But it doesn't matter. If you have duplicate IIDs, you have unintentionally created a link-local anycast address, whether it's MAC collision or otherwise. Surely there is no way forward? > 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. Well yes, I would actually be happier if 4862 said SHOULD NOT instead of MAY, because that requires a good reason to ignore it. But we didn't want to open up 4862. > 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). Sure, if the WG wants to keep this, we will improve the text. Thanks Brian > > --- > JINMEI, Tatuya > > On Thu, Jul 18, 2013 at 3:14 PM, Bob Hinden <bob.hin...@gmail.com> 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 >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------