Subject: 2460bis - section 4.2 -- hop-by-hop option writeup.

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 03:46:25 -0400

While I recognize that section 4 has text:

   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the Hop-by-
   Hop Options header if explicitly configured to do so.

which means that most nodes will never look at the Hop-by-Hop header, I
thought that section 4.2 was going to going to obsolete the discard
actions-when-not-understood.  Aside from making it clearer that the packets
will almost never be dropped, doing so eventually 4x the number of hop-by-hop
option numbes available.

I think that we agreed to change this, then I guess the decision was that the
NOTE: above solved it all, and we decided not to change this part?
I'd prefer to change this text.

I'd write:

--- /tmp/k6	2016-07-19 03:43:57.287438396 -0400
+++ /tmp/k7	2016-07-19 03:45:15.751903442 -0400
@@ -1,19 +1,7 @@
-   The Option Type identifiers are internally encoded such that their
-   highest-order two bits specify the action that must be taken if the
-   processing IPv6 node does not recognize the Option Type:
+   The Option Type identifiers were previously internally encoded such that
+   the highest-order two bits specified an action that must be taken if the
+   processing IPv6 node did not recognize the option type.
+   The recommended action (in the absense of an explicitely configured ACL),
+   is that unknown hop-by-hop options are simply skipped, and the next header
+   is examined.

-
-
-      00 - skip over this option and continue processing the header.
-
-      01 - discard the packet.
-
-      10 - discard the packet and, regardless of whether or not the
-           packet's Destination Address was a multicast address, send an
-           ICMP Parameter Problem, Code 2, message to the packet's
-           Source Address, pointing to the unrecognized Option Type.
-
-      11 - discard the packet and, only if the packet's Destination
-           Address was not a multicast address, send an ICMP Parameter
-           Problem, Code 2, message to the packet's Source Address,
-           pointing to the unrecognized Option Type.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tim Chown <[email-masked]>
Date: Tue, 19 Jul 2016 08:51:13 +0000

Hi,

> On 19 Jul 2016, at 08:46, Michael Richardson <[email-masked]> wrote:
> 
> 

I commented on this in my review also.  One option is to refer to RFC7045, since the text in 2460bis is at odds with what is said there.

So perhaps what you say below, also citing RFC7045, is appropriate.

Tim

> --------------------------------------------------------------------
> 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, 19 Jul 2016 21:08:39 +1200

> So perhaps what you say below, also citing RFC7045, is appropriate.

People objected to the text in 7045 because it was basically (and intentionally)
pragmatic. So the formulation in 2460bis was intentionally different than
7045.

     Brian

---

From: [email-masked]
Date: Tue, 19 Jul 2016 14:32:33 +0200

Michael,

> +++ /tmp/k7	2016-07-19 03:45:15.751903442 -0400

I don't think we can do this in 2460bis. The option flags are also used for the Destination options header.
There is anyway legacy implementations, meaning that new options cannot reuse the space.

For your particular problem, it sounds like you don't really want a mandatory option, why not reclassify the RPL option instead of trying to make 2460 fit the corner you've been painted into :-)).

While other options e.g. the jumbo option really does require mandatory behaviour...
Of course making processing the whole header optional, makes failing to enable it in the jumbo case a configuration error.

The compromise here, apart from trying to shoehorn the changes within the limitations of 6410, is to allow limited domains to use HBH as defined in 2460, while at the same time let the open Internet ignore and forward.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 18:06:36 +0200

Hi,

Currently the RFC2464 multicast address mapping says:

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

I think this mapping should happen only for link-scoped IPv6 destination 
addresses, not other scopes.

I.e. the last four octets of a _link-local_ IPv6 address should get 
mapped into that MAC address (ff02::XXXX:XXXX -> 33-33-XX-XX-XX-XX); 
multicast addresses of other scopes than ff02 should not get mapped.

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Jul 2016 08:01:29 +1000

I think you're assuming that there are no other nodes on the link are
members of the > link-local scope group, or that there is no more than one
multicast router on the link.

Multicast address scopes are only indicating boundary of the multicast
forwarding domain, not where multicast group members are or are not.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jul 2016 11:40:47 +0200

Le 20/07/2016 à 00:01, Mark Smith a écrit :
> On 20 Jul 2016 2:12 AM, "Alexandre Petrescu"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>>
>> Hi,
>>
>>> 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.
>>
>>
>> I think this mapping should happen only for link-scoped IPv6
> destination addresses, not other scopes.
>>
> I think you're assuming that there are no other nodes on the link
> are members of the > link-local scope group, or that there is no more
> than one multicast router on the link.

Yes, I do assume so.

> Multicast address scopes are only indicating boundary of the
> multicast forwarding domain, not where multicast group members are or
> are not.

But an Ethernet 33-33- scope can only be a link scope.  A reverse
mapping from an Ethernet scope back to a > link-local scope would make
no sense.

(I also assume mapping to be bidirectional).

Alex

> Regards, Mark.
>> [email-masked] <mailto:[email-masked]> Administrative
>> Requests:https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 20 Jul 2016 05:24:31 -0700

Hi

>>> I think this mapping should happen only for link-scoped IPv6

Why? Both for IPv4 and IPv6 you need to have some destination
multicast MAC address for any IP/IPv6 multicast packet, regardless of
scope.

>> than one multicast router on the link.

It's fairly common to have multiple multicast routers on the link, and
there can definitely be multiple members of a link-local group (or any
group) on the link.

> But an Ethernet 33-33- scope can only be a link scope.  A reverse

Why?

> (I also assume mapping to be bidirectional).

What do you mean by bidirectional? As you wrote, you cannot do a
reverse mapping.

Stig

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jul 2016 19:22:49 +0200

Le 20/07/2016 à 14:24, Stig Venaas a écrit :
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>>> 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.
>>>>
>>>>
>>>>
> multicast MAC address for any IP/IPv6 multicast packet, regardless
> of scope.

It woudlnt make sense to map a global-scope IPv6 multicast address into
a - by definition local - Ethernet multicast address.

There is not enough place in there.  As such reverse mapping would be
impossible.

>>> mapped into that MAC address (ff02::XXXX:XXXX ->
>>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02
>>> should not get mapped.
>>>>
>>>>
>>>
>>> I think you're assuming that there are no other nodes on the
>>> link are members of the > link-local scope group, or that there
>>> is no more than one multicast router on the link.
>>
>>
>> Yes, I do assume so.
>
> It's fairly common to have multiple multicast routers on the link,
> and there can definitely be multiple members of a link-local group
> (or any group) on the link.

Yes certainly there can be multiple IP multicast routers on a link.  But
I dont see how that supports mapping a global multicast address into an
Ethernet address.

>>> multicast forwarding domain, not where multicast group members
>>> are or are not.
>>
>>

Because the whole world is not (and can not) be Ethernet - there are
other link types as well.  As such its scope can only be local.

>
>> mapping from an Ethernet scope back to a > link-local scope would
>> make no sense.
>>

Bidirectional - map from IP address to MAC address, and vice-versa.
'Mapping' suggests me ability to translate and reversely too.

Or maybe this RFC2464 'mapping' means to translate into only one
direction?  (translate an IP to MAC but not vice-versa)

Alex

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jul 2016 13:24:55 -0400

> There is anyway legacy implementations, meaning that new options cannot

Ah, I hadn't realized this.

    > For your particular problem, it sounds like you don't really want a
    > mandatory option, why not reclassify the RPL option instead of trying
    > to make 2460 fit the corner you've been painted into :-)).

Okay, so I want to re-open this possibility as part of the flag day caused by
deploying of 6LoRH.

Specifically, about updating RFC6553 such that the Option code changes from
0x63 to 0x23.  I think that this should be tied to deployment of 6LoRH.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 21 Jul 2016 06:46:35 -0700

Hi

> a - by definition local - Ethernet multicast address.

I know the local means locally assigned, but it is the same mapping
regardless of scope. Even a global scope multicast packet need to
have a defined MAC mapping so that a NIC can be programmed to
receive the appropriate packets.

Since only the last 4 octets from the IP address is in the MAC address,
there can be many IP multicast addresses using the same MAC address.
Hence in some cases a NIC could receive a packet it isn't interested in.
But this cannot really be avoided when you map an IPv6 address into 48 bits
or less.

> I dont see how that supports mapping a global multicast address into an

I don't know why it matters how many routers there are.

> other link types as well.  As such its scope can only be local.

A global scope multicast packet might be forwarded across multiple
links. On each link it traverses it will have some local link address. So
you can say the L3 address is global, while the L2 address is just for
the link.

> direction?  (translate an IP to MAC but not vice-versa)

Yes, it's only in one direction.

Stig

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Jul 2016 17:02:14 +0200

Hi,

Le 21/07/2016 à 15:46, Stig Venaas a écrit :
[...]
>>> multicast MAC address for any IP/IPv6 multicast packet,
>>> regardless of scope.
>>
>>
>> It woudlnt make sense to map a global-scope IPv6 multicast address
>> into a - by definition local - Ethernet multicast address.
>
> have a defined MAC mapping so that a NIC can be programmed to receive
> the appropriate packets.

Hmm, I would agree, but I also think that the NIC of the default router
should not be programmed in some special way to receive appropriate
packets multicast packets.  I think it's sufficient for it to have a
normal unicast IP and MAC address, and be present in the default router
list of the sender.

> Since only the last 4 octets from the IP address is in the MAC
> address, there can be many IP multicast addresses using the same MAC
> address.

That's not good, right?  These groups are different groups.

> Hence in some cases a NIC could receive a packet it isn't interested
> in. But this cannot really be avoided when you map an IPv6 address
> into 48 bits or less.

No.  It could be avoided if (1) only the link-local ff02 addresses would
be mapped (and not all scopes), (2) Group IDs in IPv6 for link-local
scope would be of max length 3 bytes.

But yes, this is in a fictitious IPv6 world.

Alex

>
>> There is not enough place in there.  As such reverse mapping would
>> be impossible.
>>
>>>>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than
>>>>> ff02 should not get mapped.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> link are members of the > link-local scope group, or that
>>>>> there is no more than one multicast router on the link.
>>>>
>>>>
>>>>
>>>> Yes, I do assume so.
>>>
>>>
>>> It's fairly common to have multiple multicast routers on the
>>> link, and there can definitely be multiple members of a
>>> link-local group (or any group) on the link.
>>
>>
>> Yes certainly there can be multiple IP multicast routers on a link.
>> But I dont see how that supports mapping a global multicast address
>> into an Ethernet address.
>
>>>>> multicast forwarding domain, not where multicast group
>>>>> members are or are not.
>>>>
>>>>
>>>>
>> Because the whole world is not (and can not) be Ethernet - there
>> are other link types as well.  As such its scope can only be
>> local.
>
> links. On each link it traverses it will have some local link
> address. So you can say the L3 address is global, while the L2
> address is just for the link.
>
>>>
>>>> mapping from an Ethernet scope back to a > link-local scope
>>>> would make no sense.
>>>>
>> Bidirectional - map from IP address to MAC address, and
>> vice-versa. 'Mapping' suggests me ability to translate and
>> reversely too.
>>
>>>>
>>>> IETF IPv6 working group mailing list [email-masked]
>>>> Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Stig Venaas <[email-masked]>
Date: Fri, 22 Jul 2016 01:21:40 -0700

Hi

> normal unicast IP and MAC address, and be present in the default router

The NIC of the receiver is programmed so that it can filter and receive
only packets that are likely to be for the host, including multicast packets.
Note that there may be hashing used so it can pick up some MACs that
are not for the host.

> That's not good, right?  These groups are different groups.

The host stack will still do verification and discard packets it doesn't want.
The main issue is that the NIC may pick up packets that the host
doesn't care about.

> But yes, this is in a fictitious IPv6 world.

Right. So in particular, it is a bad idea if someone uses a multicast
address where the last 4 bytes are just ::1 as it looks just like ff02::1 at
L2, so all host NICs would pick up the packets.

Note that for SSM we will always have such problems as the NIC has
no idea about the multicast source. Some IGMP snoopers/proxies do
though, so that can help.

Stig