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 <[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
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
