Re: 6MAN WG Last Call: <draft-ietf-6man-ug-01.txt>

[Brian E Carpenter <[e-mail]>]

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