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

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

All,

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.  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: "Liubing (Leo)" <[email-masked]>
Date: Mon, 22 Jul 2013 09:57:53 +0000

Hi, WG

Support for advancing.

Best regards,
Bing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bob Hinden
> Sent: Friday, July 19, 2013 6:11 AM
> To: IPv6 IPv6 List
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call: <draft-ietf-6man-ug-01.txt>
> 
> All,
> 
> 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-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 22 Jul 2013 11:41:14 +0000

Perhaps you've argued this before, but per rfc 4291, u=1, g=0 is what an IID that was formed from a MAC address uses, not u=0. The IEEE mac bits are u=0, g=0. In the context below, perhaps best to be clear ... Use IEEE  "u" = "g" = 0? Or IID  "u" = 1 and "g" = 0. (It is also a bit odd that 2nd sentence talks about IID into MAC and 4th sentence switches this to MAC into IID, especially given last sentence.)

3<http://tools.ietf.org/html/draft-ietf-6man-ug-01#section-3>.  Usefulness of the U and G Bits

   Given that the "u" and "g" bits do not have a reliable meaning in an
   IID, it is relevant to consider what usefulness they do have.

   If an IID is known or guessed to have been created according to RFC<http://tools.ietf.org/html/rfc4291>
   4291<http://tools.ietf.org/html/rfc4291>, it could be transformed back into a MAC address.  This can be
   very helpful during operational fault diagnosis.  For that reason,
   mapping the IEEE "u" and "g" bits into the IID has operational
   usefulness.  However, it should be stressed that "u" = "g" = 0 does
   not prove that an IID was formed from a MAC address; on the contrary,
   it might equally result from another method.  With other methods,
   there is no reverse transformation available.

- Bernie (from iPad)

On Jul 22, 2013, at 6:01 AM, "Liubing (Leo)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi, WG

Support for advancing.

Best regards,
Bing

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Bob Hinden
Sent: Friday, July 19, 2013 6:11 AM
To: IPv6 IPv6 List
Cc: Bob Hinden
Subject: 6MAN WG Last Call: <draft-ietf-6man-ug-01.txt>

All,

Regards,

Bob Hinden & Ole Trøan

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jul 2013 16:31:36 +0000

Hi,

This looks good, but may want to include 1-2 sentences on ISATAP
[RFC5214] which is another variant on modified EUI-64.

Thanks - Fred
[email-masked]

> Sent: Thursday, July 18, 2013 3:11 PM
> To: IPv6 IPv6 List
> Cc: Bob Hinden
> 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: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jul 2013 08:04:30 +1200

> Perhaps you've argued this before, but per rfc 4291, u=1, g=0 is what an IID that was formed from a MAC address uses, not u=0. The IEEE mac bits are u=0, g=0. In the context below, perhaps best to…

Bernie, you are correct, the phrasing is slightly confused there.
We can correct it.

    Brian

> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jul 2013 08:10:41 +1200

> [RFC5214] which is another variant on modified EUI-64.

Yes, we can add that for completeness.

(In 6over4, RFC2529, we forced u=g=0, but that is operationally
irrelevant.)

Thanks
    Brian

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Jul 2013 16:21:45 -0400

> as a Proposed Standard.

i have read it and i think this is about as good as we're gonna get in
this cycle

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jul 2013 08:41:47 +1200

The draft contains one open issue, in section 7:

>    OPEN ISSUE: Alternatively, we could decide to close the reserved IID
>    registry completely ...

Absent other opinions, my proposal is that we do not close the registry.
The rest of the section sets a high bar for new entries, which is
probably sufficient.

Regards
   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 22 Jul 2013 14:12:14 -0700 (PDT)

Hi,

Firstly, I support advancing this draft.

Some suggested changes:

"  This has no known harmful effect as long as the
   replicated MAC addresses and IIDs are used on different layer 2
   links.  If they are used on the same link, of course there will be a
   problem, to be detected by duplicate address detection [RFC4862], but
   such a problem can usually only be resolved by human intervention."

I think it would be worth pointing out that the link layer is most likely to fail to operate with duplicate link layer addresses, before DAD has a chance to detect duplicate IPv6 addresses.

"  Also, there is
   evidence from the field that IEEE MAC addresses with "u" = 0 are
   sometime incorrectly assigned to multiple MAC interfaces.  Firstly,
   there are recurrent reports of manufacturers assigning the same MAC
   address to multiple devices. Secondly, significant re-use of the
   same virtual MAC address is reported in virtual machine environments. "

I found this text a bit confusing. The '"u" = 0' term read like it was referring to locally unique IEEE MAC addresses ("unique equals no"), and then the 2nd sentence is referring to globally unique (but duplicated and therefore not actually globally unique) MAC addresses, u = 1 in an IPv6 IID, the opposite of what the previous sentence was referring to. Then the third sentence seems to be describing to what the first sentence was referring to. I think the cause of the confusion might be that IEEE use the "locally assigned" bit to distinguish locally generated or not (i.e., "l" = 0 for globally unique), where as IPv6 IIDs have renamed it to "u" bit when the value is inverted. I'd suggest trying to ensure the IEEE terminology is used when IEEE addresses are discussed to make it clearer what the properties of the IEEE address are.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 22 Jul 2013 14:14:57 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: 6man <[email-masked]>
> Cc: 
> Sent: Tuesday, 23 July 2013 6:41 AM
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-ug-01.txt>
> 
>T he draft contains one open issue, in section 7:
> 

I also agree with not closing the registry.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jul 2013 10:00:59 +1200

> I think it would be worth pointing out that the link layer is most likely to fail to operate with duplicate link layer addresses, before DAD has a chance to detect duplicate IPv6 addresses.

OK.

> I found this text a bit confusing. The '"u" = 0' term read like it was referring to locally unique IEEE MAC addresses ("unique equals no"), and then the 2nd sentence is referring to globally unique…

Yep. I remember complaining when the bit inversion was first proposed
that it would lead to years of confusion. Which IEEE standard is the
basic reference for their terminology?

    Brian

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Tue, 23 Jul 2013 02:17:46 +0000

Hi All,

    I support to move forward this draft.

Cheers
Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Friday, July 19, 2013 6:11 AM
To: IPv6 IPv6 List
Cc: Bob Hinden
Subject: 6MAN WG Last Call: <draft-ietf-6man-ug-01.txt>

All,

Regards,

Bob Hinden & Ole Trøan

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 22 Jul 2013 21:11:20 -0700 (PDT)

Hi Brian,

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>
> Cc: IPv6 IPv6 List <[email-masked]>
> Sent: Tuesday, 23 July 2013 8:00 AM
  
<snip> 

>>  I found this text a bit confusing. The '"u" = 0' term 
> read like it was referring to locally unique IEEE MAC addresses ("unique 
> equals no"), and then the 2nd sentence is referring to globally unique (but 
> duplicated and therefore not actually globally unique) MAC addresses, u = 1 in 
> an IPv6 IID, the opposite of what the previous sentence was referring to. Then 
> the third sentence seems to be describing to what the first sentence was 
> referring to. I think the cause of the confusion might be that IEEE use the 
> "locally assigned" bit to distinguish locally generated or not (i.e., 
> "l" = 0 for globally unique), where as IPv6 IIDs have renamed it to 
> "u" bit when the value is inverted. I'd suggest trying to ensure 
> the IEEE terminology is used when IEEE addresses are discussed to make it 
> clearer what the properties of the IEEE address are.
> 

I understand the canonical definition of 48-bit universal LAN MAC addresses is in:

IEEE Std 802®-2001 - 802® IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture

(http://standards.ieee.org/getieee802/download/802-2001.pdf)

From page 21, it seems what I knew as the "locally assigned" bit is actually the "Universally or Locally administered (U/L) address bit".

Regards,
Mark.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Jul 2013 04:14:57 -0400

I have reviewed the document; in my opinion it is ready to be sent to the IESG.

I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along with draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be extended to a set of links."  For completeness, RFC 6775 could be cited along with RFC 4862 in section 1.2.

- Ralph

---

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

> I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along with draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be extended to a set of links."  For completeness, RFC 67…

Makes sense to me.

   Brian

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Jul 2013 19:31:52 +0300

I think the document is ready to go. Good that we finally can
close the eternal u & g bit mess.

For the open issue in Section 7. I am also in favour
of retaining the reserved IID registry.

Then one or two nits. In Section 5. where changes to RFC4291 are
listed I wonder why those new pieces of text do not use RFC2119
language. I recon RFC4291 does not use RFC2119 language but still
this is going to be a new RFC that itself refers and uses RFC2119
language.

- Jouni

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jul 2013 08:07:15 +1200

> this is going to be a new RFC that itself refers and uses RFC2119

That was intentional so that if you read a "virtual" 4291bis including
these wording changes you do not find upper-case keywords but no
citation of 2119. I think it's more logical this way.

Thanks
    Brian

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 25 Jul 2013 10:43:31 +0300

> citation of 2119. I think it's more logical this way.

Sounds plausible to me.

- Jouni

---

From: Roland Bless <[email-masked]>
Date: Mon, 29 Jul 2013 15:41:03 +0200

Hi,
> 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 l…

Support to advance.

Minor comment:
I found the last statements in section 4 slightly confusing:
   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.

1.) DAD should actually detect that collision
2.) Continuing IPv6 operation with different addresses may be fine, but
    I don't see any reason to continue operation with the colliding
    address (or wasn't that what you meant?).

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2013 08:50:57 +1200

Roland,

> 1.) DAD should actually detect that collision

Yes, but it cannot detect the cause.

>     address (or wasn't that what you meant?).

You are correct and the text is confusing - see the earlier comments from
Tatuya explaining the intention of RFC 4862.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jul 2013 10:22:22 +0200

Brian,

(participant hat)

> Yes, but it cannot detect the cause.

why not?
can't the node just check the L2 source address against it's own?

I suggest removing the sentence:
"There is no algorithm for determining whether this case has arisen, rather than a genuine
MAC address collision. "

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Aug 2013 09:03:22 +1200

Ole,

> can't the node just check the L2 source address against it's own?

I suppose, if the MAC layer actually delivers the clashing
packet to the ND layer.
> "There is no algorithm for determining whether this case has arisen, rather than a genuine

We'll be rewriting the text, for sure.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 31 Jul 2013 14:26:26 -0700

On Jul 31, 2013, at 14:03 , Brian E Carpenter <[email-masked]> wrote:
> 
> I suppose, if the MAC layer actually delivers the clashing packet to the ND layer.

Alas, the presence of Neighbor Discovery proxy can disrupt that mechanism.

--
james woodyatt <[email-masked]>
core os networking