Subject: draft-ietf-6man-default-iids and RFC4291

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 20:36:12 +1200

If we add a citation of 4291 to draft-ietf-6man-default-iids, please
note the difference that is coming soon in 4291bis:

RFC4291 says
   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

RFC4291bis says
   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long.  If derived
   from an IEEE MAC-layer address, they must be constructed in Modified
   EUI-64 format.

That's to say, 4291bis also leaves the question open to the implementor.

-- 
Regards
   Brian Carpenter
   (Don't blame me, I voted Remain.)

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Jul 2016 05:22:51 -0400

On Tue, Jul 19, 2016 at 4:36 AM, Brian E Carpenter <
[email-masked]> wrote:

> The interesting wrinkle here is how one interprets the phrase "IEEE MAC-
layer address".  I get the sense that many people interpret this as a 48-bit
hardware address with the U/L bit set to zero.

The point that Pascal made at the mic is that 6LoWPAN (and other 6lo
IPv6-over-foo specs) specify a method for generating an IID by first
creating a locally assigned 48-bit MAC-layer address by right justifying
a short locally assigned L2 address in a field of zeros, setting the U/L bit
to one, then using this as the basis for forming a Modified EUI-64
according to RFC4291 Appendix A.

I don't see the RFC4291bis language as affecting this approach.

Regards, Kerry

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Jul 2016 11:27:50 +0200

> That's to say, 4291bis also leaves the question open to the implementor.

FWIW, I think 4291bis should actualy reference default-iids here.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 21:34:04 +1200

> I don't see the RFC4291bis language as affecting this approach.

Agreed. My point was that 4291bis does *not* provide a normative fall
back; it just provides an "if" statement, which doesn't resolve Lorenzo's
issue about the choice left open by draft-ietf-6man-default-iids in its
current form.

   Brian

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Jul 2016 05:56:53 -0400

On Tue, Jul 19, 2016 at 5:27 AM, Fernando Gont <[email-masked]>
wrote:

> I think not, since that assumes the bis language only covers IIDs derived
from stable IEEE MAC-layer addresses.

Kerry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Jul 2016 12:01:06 +0200

> issue about the choice left open by draft-ietf-6man-default-iids in its

You mean for the case where a node employs non-stable only?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 22:14:25 +1200

> You mean for the case where a node employs non-stable only?

Well, yes, or any case in which the implementor decides to "escape" from
draft-ietf-6man-default-iids for any other reason.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 12:14:40 +0200

Hi,

I suspect HbH is used in Router Alert options and MLDv2, which is used 
at computer startup to signal presence and belonging to some multicast 
groups needed later by ND.

If so, then the RFC2460bis suggested modifications would imply that all 
computers would have to be specifically enabled to continue use this HbH?

Alex

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Jul 2016 12:31:21 +0200

On 07/19/2016 12:14 PM, Brian E Carpenter wrote:
[...]
> draft-ietf-6man-default-iids for any other reason.

My take is that if you decide not to follow the SHOULD in default-iids,
you need to specify whatever algorithm you want to use (i.e., the nus is
on the folk that decided not to follow default-iids).

Regarding non-stable IIDs, I guess that "hole" is filled by the
non-stable-iids I presented today?

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 23:08:44 +1200

> on the folk that decided not to follow default-iids).

Yes. And for this, 4291bis doesn't define a default.

> non-stable-iids I presented today?

Yes, I think so.

   Brian

---

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

> Yes. And for this, 4291bis doesn't define a default.

Right, and I don't think leaving that open is a problem.
In most of the implementations I work on the default is to require manual configuration.
Link-locals are created by modified EUI-64. I don't think we have any intention of changing that.

[...]

Cheers,
Ole

---

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

Alex,

> I suspect HbH is used in Router Alert options and MLDv2, which is used at computer startup to signal presence and belonging to some multicast groups needed later by ND.
> 
> If so, then the RFC2460bis suggested modifications would imply that all computers would have to be specifically enabled to continue use this HbH?

Wouldn't it only be multicast routers that would need to do that?

If I remember correctly non-multicast routers do not listen to MLD and multicast routers do ignore MLD reports for link-local multicast addresses. (As discussed on a different thread it is arguable how much value there is in sending MLD reports for link-local multicast in the first place).

Cheers,
Ole

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 19 Jul 2016 12:22:05 +0000

AFAIK No, because only MLD listeners will actually receive the packet
(i.e. They are member of the destination group) and not forward this
packet anyway as MLD packets are not forwarded.

So, the HbH is rather useless as a trigger in this case because MLD
routers will have to parse anyway the full chain as they receive it

-éric

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Jul 2016 05:33:31 -0700

Router Alert is required in MLD messages, but I don't see much point.
I wonder if it could be used as a way to prevent forwarding though.
That is, if someone tries to illegally send an MLD packet to a remote
unicast address or non-link-local group address, then this could make
it easier for the local router to discard it. Of course someone trying
to do something bad could send an MLD report without RA. I suspect
receivers may not check for presence of RA.

Stig

---

From: Enno Rey <[email-masked]>
Date: Tue, 19 Jul 2016 14:55:48 +0200

Hi,

> receivers may not check for presence of RA.

your assumption is correct. As of https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf there's a number of MLD implementations that do *not* care for the presence of RA. more precisely: at the time of lab testing there were some implementations. I doubt this has changed in the interim though.

best

Enno

> > -??ric

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

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

Le 19/07/2016 à 14:17, [email-masked] a écrit :
> Alex,
>
>> I suspect HbH is used in Router Alert options and MLDv2, which is
>> used at computer startup to signal presence and belonging to some
>> multicast groups needed later by ND.
>>
>> If so, then the RFC2460bis suggested modifications would imply
>> that all computers would have to be specifically enabled to
>> continue use this HbH?
>

I think any IPv6 machines (router and host) sends MLD messages when it
boots, but I am not sure whether each MLD message is mandated to contain
a Router Alert.

> If I remember correctly non-multicast routers do not listen to MLD
> and multicast routers do ignore MLD reports for link-local multicast
> addresses. (As discussed on a different thread it is arguable how
> much value there is in sending MLD reports for link-local multicast
> in the first place).

If there is an effort to develop IEEE MAC multicast then the MLD reports
for link-local multicast addressing make sense.  IF there is no such
effort in view, then it would make sense to rather make a linux bug report.

Alex

> Cheers, Ole

---

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

> routers will have to parse anyway the full chain as they receive it

Where is MLD being specified/maintained these days?

Alex

---

From: Ron Bonica <[email-masked]>
Date: Tue, 19 Jul 2016 16:47:06 +0000

Stig,

Likewise, RSVP relies on the Router Alert Option. And, likewise, I don't see much point.

Some vendors set the destination address in the RSVP message to the next hop and change the destination address at each hop. In this case, the Router Alert isn't needed. This works well today.

I wonder if 6man should send a request to the PIM and RSVP WGs asking them to avoid the Router Alert Option in the future? Since there are relatively few RSVP-over-IPv6 implementations, such a recommendation might have a significant impact.

                                                              Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Stig Venaas
> Sent: Tuesday, July 19, 2016 8:34 AM
> To: Eric Vyncke (evyncke) <[email-masked]>
> Cc: Alexandre Petrescu <[email-masked]>; [email-masked]
> Subject: Re: HbH used by Router Alert in MLDv2?
> 
> That is, if someone tries to illegally send an MLD packet to a remote unicast
> address or non-link-local group address, then this could make it easier for the
> local router to discard it. Of course someone trying to do something bad
> could send an MLD report without RA. I suspect receivers may not check for
> presence of RA.
> 
> Stig
> 
> 
> On Tue, Jul 19, 2016 at 5:22 AM, Eric Vyncke (evyncke) <[email-masked]>
> wrote:
> >>If so, then the RFC2460bis suggested modifications would imply that
> >>all computers would have to be specifically enabled to continue use this
> HbH?
> >>
> >>Alex
> >>