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

From: Bob Hinden <[email-masked]>
Date: Thu, 18 Jul 2013 15:14:21 -0700

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

---

From: JINMEI Tatuya <[email-masked]>
Date: Mon, 22 Jul 2013 17:28:38 -0700

At Thu, 18 Jul 2013 15:11:00 -0700,
Bob Hinden <[email-masked]> wrote:

>     Title           : Significance of IPv6 Interface Identifiers
>     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-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jul 2013 13:09:50 +1200

> At Thu, 18 Jul 2013 15:11:00 -0700,

...
>     supposed to be uniquely assigned, IP operation on the interface MAY

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.

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

> MAC address collision, RFC 4862 leaves it to the implementor (hence

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?

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

> (at least to me it was very difficult to understand what it tries to

Sure, if the WG wants to keep this, we will improve the text.

Thanks
    Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 22 Jul 2013 23:32:29 -0700

At Tue, 23 Jul 2013 13:09:50 +1200,

> in the WG asked us to discuss this case.

For example, there may be other, manually assigned address that is
unique in the subnet.  Or you might assign some once you notice the
duplicate.  If it's less likely due to MAC address collision, I see it
makes some sense (but RFC 4862 does not necessarily recommend it; it
just does not prohibit it by saying MAY).

(BTW, I noticed the phrase of ", which is supposed to be uniquely
assigned," in the above snippet from RFC 4862 may be confusing.  I'm
not sure how it was inserted, but it's probably a copy-paste error).

> MAC collision or otherwise. Surely there is no way forward?

See above.  Surely there's no way of using that link-local address any
more (I believe RFC 4862 is very clear about that).  But there can be
other reasonable way of recovery from that situation at layer 3 if
it's not MAC collision.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jul 2013 08:14:26 +1200

On 23/07/2013 18:32, JINMEI Tatuya / 神明達哉 wrote:
> unique in the subnet.  

Ah. Now I understand what is intended, but the text needs to say:

...IP operation on the interface MAY be continued _using another
address that is not a duplicate_.

OK, we can clean up the text in the next version.

     Brian

Or you might assign some once you notice the
> .