Subject: RFC6085 update to rfc2464bis

From: Bob Hinden <[email-masked]>
Date: Mon, 9 Jan 2017 13:53:54 -0800

Hi,

Based on update from RFC6085 I added two paragraphs to Section 7 of <draft-hinden-6man-rfc2464bis-01>.  These are:

> 7.  Address Mapping -- Multicast
> 
>    An IPv6 packet with a multicast destination address DST, consisting
>    of the sixteen octets DST[1] through DST[16], is transmitted to the
>    Ethernet multicast address whose first two octets are the value 3333
>    hexadecimal and whose last four octets are the last four octets of
>    DST.
> 
>                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                   |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
>                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                   |   DST[13]     |   DST[14]     |
>                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                   |   DST[15]     |   DST[16]     |
>                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An IPv6 multicast packet may also be mapped to a unicast Ethernet
   Link layer address as defined in Section 6.

   An IPv6 node receiving an IPv6 packet with a multicast destination
   address and an Ethernet link-layer unicast address must not drop the
   packet as a result using of this form of address mapping.

While RFC6085 isn’t exactly clear about the change it wants in RFC2464, I think this is about right.

Comments?

Thanks,
Bob

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Jan 2017 11:59:50 +0100

Hi,

> While RFC6085 isn’t exactly clear about the change it wants in RFC2464, I think this is about right.

Looks good.
Sander

---

From: 神明達哉 <[email-masked]>
Date: Tue, 10 Jan 2017 09:26:22 -0800

At Mon, 9 Jan 2017 13:53:54 -0800,

>    Link layer address as defined in Section 6.

I think it's more helpful to refer to RFC6085 explicitly here.
Otherwise the proposed text looks good to me.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Jan 2017 10:12:01 -0800

Jinmei-san,

> On Jan 10, 2017, at 9:26 AM, 神明達哉 <[email-masked]> wrote:
> 

RFC6085 doesn’t actually say very much.  The only real content in Section 3:

   3.  Receiving IPv6 Multicast Packets

   An IPv6 node receiving an IPv6 packet with a multicast destination
   address and an Ethernet link-layer unicast address MUST NOT drop the
   packet as a result of the use of this form of address mapping.

There is some text in the Introduction that says more:

   This document
   extends this mapping to explicitly allow for a mapping of an IPv6
   packet with a multicast destination address into an Ethernet link-
   layer unicast address, when it is clear that only one address is
   relevant.

Unfortunately, there isn’t anything like that in the main part of the document.

I will add an informational reference to RFC6085, but I don’t think it helps very much.

Thanks,
Bob

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

---

From: 神明達哉 <[email-masked]>
Date: Tue, 10 Jan 2017 11:22:52 -0800

> Otherwise the proposed text looks good to me.

On re-reading it more closely, I wonder whether "as defined in Section
6" may not be very appropriate.  RFC6085 intentionally left the
mapping open:

   [...]  The determination of the unicast Ethernet link-layer
   address and the construction of the outgoing IPv6 packet are out of
   scope for this document.

but I suspect it doesn't really intend to perform link-layer address
resolution using ND (which is in my understanding what "Section 6"
talks about) to determine the unicast Ethernet address.  In fact, the
address resolution itself uses a multicast IPv6 address, which is
derived from the target unicast IPv6 address.  So it would be a kind
of circular definition.

So it's probably even better to just refer to the RFC instead of
Section 6:

    An IPv6 multicast packet may also be mapped to a unicast Ethernet
    Link layer address as noted in [RFC6085].

And, for that matter, this text of Section 6 of rfc2464bis-01 now
looks a bit awkward to me:

   The procedure for mapping IPv6 unicast addresses into Ethernet link-
   layer addresses is described in [DISC].

On reading both Sections 6 and 7, this "the procedure for mapping"
could read some static mapping whereas it should actually refer to
dynamic link-layer address resolution.

I suggest revising the first paragraph from:

   The procedure for mapping IPv6 unicast addresses into Ethernet link-
   layer addresses is described in [DISC].  The Source/Target Link-layer
   Address option has the following form when the link layer is
   Ethernet.

to:

   When the link layer is Ethernet, the Ethernet address for an IPv6
   unicast address is resolved using the address resolution protocol
   as defined in [DISC].  The Source/Target Link-layer Address option
   used in that protocol has the following form.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Jan 2017 16:05:39 -0800

Jinmei-san,

> On Jan 10, 2017, at 11:22 AM, 神明達哉 <[email-masked]> wrote:
> 

I think the problem remains that RFC6085 isn’t very clear how to do that.  Pointing to RFC6085 is that it doesn’t say what to do :-(

It would be good to hear from the authors of RFC6085.  Also, what is current practice.

>   layer addresses is described in [DISC].

That is original text from RFC2464.  I tried to avoid changing anything that wasn’t part of an update or errata.

>   used in that protocol has the following form.

I find that an improvement (maybe without the “When” text), but I am not sure a change is needed.

Thanks,
Bob

---

From: [email-masked]
Date: Wed, 11 Jan 2017 10:48:45 +0100

Bob, Jinmei,

As one of the authors of RFC6085 let me try to clarify how it would typically be used.
Scenario: Wireless AP that already knows the L2 unicast address of all stations on a link.
Some APs try to improve on IPv6 multicast on wireless by sending the RAs as L2 unicast to each individual station.
The AP then runs through it's list of L2 unicast addresses and sends the multicast RA with the given L2 unicast mapping.

2464bis says:

As Jinmei also says, referring to section 6 is then wrong. That implies that the 6085 address mapping uses address resolution. Which is not the case.

6085 is indeed very underspecified in stating how the mapping is done, from 6085:
   The determination of the unicast Ethernet link-layer
   address and the construction of the outgoing IPv6 packet are out of
   scope for this document.

Either do (Jinmei): 
   An IPv6 multicast packet may also be mapped to a unicast Ethernet
   Link layer address as described in RFC6085.

Or something like:
  An IPv6 packet with a multicast destination address may also be mapped to an 
  Ethernet link-layer unicast address [RFC6085].
  E.g. when it is clear that only one address is relevant on the link and that the
  mapping between an IPv6 multicast destination address and an Ethernet link-layer
  unicast address is already known.

Cheers,
Ole

> On 11 Jan 2017, at 01:05, Bob Hinden <[email-masked]> wrote:
> 
> Jinmei-san,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Jan 2017 19:57:55 +0100

Has one witnessed a packet dump of IPv6-over-wired-Ethernet (not WiFi) 
featuring a dst _IP multicast_ address with the dst _MAC unicast_ address?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Jan 2017 20:00:01 +0100

Le 11/01/2017 à 10:48, [email-masked] a écrit :
> Scenario: Wireless AP

This is WiFi, it is not Ethernet.  It is not the same.  An 
IPv6-over-WiFi document remains to be written.

This multicast aspect is the tip of the iceberg of differences between 
the two.

Alex

> that already knows the L2 unicast address of all stations on a link.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Jan 2017 20:07:39 +0100

On 11 Jan 2017, at 20:00, Alexandre Petrescu <[email-masked]> wrote:
> 
> This is WiFi, it is not Ethernet.  It is not the same.  An IPv6-over-WiFi document remains to be written.

That’s actually not true in real life.

“IPv6 over Ethernet” in reality is a shorthand for “IPv6 over 802.1 bridged links that collectively try to look like Ethernet but don’t always succeed very well”.  WiFi is part of that world.

Grüße, Carsten

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Jan 2017 06:11:13 +1100

Hi,

I also wrote up a draft a few years back as to how MLDv2 in combination
with Neighbor Discovery could use link layer unicast for multicast IPv6
traffic.

MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
https://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00

I also saw this Linux bridge patch a few days ago which sounds like it does
the same sort of thing and has apparently been enabled in OpenWRT on Wifi
AP interfaces.

https://patchwork.ozlabs.org/patch/710249/

Regards,
Mark.

On 11 January 2017 at 20:48, <[email-masked]> wrote:
> Some APs try to improve on IPv6 multicast on wireless by sending the RAs
as L2 unicast to each individual station.
> The AP then runs through it's list of L2 unicast addresses and sends the
multicast RA with the given L2 unicast mapping.
> As Jinmei also says, referring to section 6 is then wrong. That implies
that the 6085 address mapping uses address resolution. Which is not the
case.
>> I think the problem remains that RFC6085 isn’t very clear how to do
that. Pointing to RFC6085 is that it doesn’t say what to do :-(

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Jan 2017 12:09:55 -0800

> “IPv6 over Ethernet” in reality is a shorthand for “IPv6 over 802.1 bridged links that collectively try to look like Ethernet but don’t always succeed very well”.  WiFi is part of that world.

I would agree with that statement. "Ethernet", these days, includes the IEEE 802.3 series of specifications at various speeds and using various PHY interfaces, the IEEE 802.11 series, and lambdas and other "serial" media in the backbone. The point, as you you note, is the use of the Ethernet frame format (1518 bytes, including the 802.3 header and the CRC trailer, and the bit I care about in between). There is an obvious extension at 1 GBPS and faster, to a 9K byte message, but the exact value of "9K" varies, and there are funny issues like "is that a single frame, or a burst of 1500 byte frames?"

By way of example, in my house I have both wired (1 GBPS) Ethernet and 802.11 Wifi. The latter is attached to the former, and is in any useful sense indistinguishable from it including sharing the IP prefixes. A message might originate on WiFi using one access point, ride a wire to and from a switch, and come out to a printer on the other access point. It's one "Ethernet", and it is what it is.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2017 09:13:57 +1300

> “IPv6 over Ethernet” in reality is a shorthand for “IPv6 over 802.1 bridged links that collectively try to look like Ethernet but don’t always succeed very well”.  WiFi is part of that world.

Indeed. I don't care how it works under the covers: code that runs over Ethernet runs
identically over WiFi. OK, maybe some spectrum is wasted, but for most people most of the
time that simply doesn't matter.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 16:36:51 -0800

Ole,

> On Jan 11, 2017, at 1:48 AM, [email-masked] wrote:
> 
> Bob, Jinmei,
> 

I agree with Jinmei and your comments that referring to Section 6 is not correct.  Adding the reference to RFC6085 is good, but as you note above, it doesn’t describe how to do this mapping.  The text you suggest may be the best we can do.  It’s not exactly an algorithmic mapping, as the node doing it needs to know something about the environment it is running in.  I guess this is the down side of using “Ethernet” on a variety of media that isn’t a real multicast domain.  

Any other suggestions?

Bob