Subject: [dhcwg] MTU option for DHCPv6?

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Jul 2016 20:09:44 +0000

Just curious - is there now (or has there ever been proposed) an MTU option
for DHCPv6 in the same way that DHCPv4 has an MTU option?

Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Jul 2016 21:01:57 +0000

Hi Fred:

Nothing has been proposed that I can recall. The issue really hasn't come up (to date).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Wednesday, July 27, 2016 4:10 PM
To: <[email-masked]> <[email-masked]>
Subject: [dhcwg] MTU option for DHCPv6?

Just curious - is there now (or has there ever been proposed) an MTU option for DHCPv6 in the same way that DHCPv4 has an MTU option?

Thanks - Fred

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Jul 2016 21:24:19 +0000

Hi Bernie,

I'm operating on a link where I don't need to get any configuration information from
RS/RA - everything comes from DHCPv6. So, ideally, I would like to see DHCPv6 provide
an MTU option and a Prefix Information Option - then I would have everything I need
so that I don't have to use a vendor-specific option. Would that be possible?

Thanks - Fred

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2016 2:02 PM
> To: Templin, Fred L <[email-masked]>; <[email-masked]> <[email-masked]>
> Subject: RE: MTU option for DHCPv6?
> 
> Hi Fred:
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Jul 2016 22:14:11 +0000

I'm not sure I fully follow.

The v4 MTU option is the client telling the server how much it can receive.

I'm not sure why the client wouldn't just use a large buffer (64K) as it isn't likely to need many of these buffers? The server is often more restrictive since it might be processing many requests at once.

And, why would you need to have the server send so much data that the client might not be able to receive it all?

BTW: I think when this came up during the writing of 3315, it was thought that having the client use a 64K buffer wasn't really an issue.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2016 5:24 PM
To: Bernie Volz (volz) <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: RE: MTU option for DHCPv6?

Hi Bernie,

I'm operating on a link where I don't need to get any configuration information from RS/RA - everything comes from DHCPv6. So, ideally, I would like to see DHCPv6 provide an MTU option and a Prefix Information Option - then I would have everything I need so that I don't have to use a vendor-specific option. Would that be possible?

Thanks - Fred

> Just curious - is there now (or has there ever been proposed) an MTU 
> option for DHCPv6 in the same way that DHCPv4 has an MTU option?
> 
> Thanks - Fred
>

---

From: Ian Farrer <[email-masked]>
Date: Thu, 28 Jul 2016 10:49:15 +0200

Hi Bernie,

It sounds like Fred is looking for a DHCPv6 equivalent of DHCPv4 option 26 which (as I understand it) allows the DHCP server to tell the client the interface MTU to use on the link. Is this the same option as the one that you’re referring to?

I can also see a use for having this information being sent to the client as we plan to use large MTUs to clients. From my perspective, having this information inside the PIO would be most useful.

@Fred, if the MTU was carried as an option inside the PIO, and there was a way of putting the PIO into DHCP, would this work for you?

Ian

> On 28 Jul 2016, at 00:14, Bernie Volz (volz) <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Thu, 28 Jul 2016 11:06:00 +0200

> @Fred, if the MTU was carried as an option inside the PIO, and there was a way of putting the PIO into DHCP, would this work for you?

If you want to solve the set of problems that Mikael outlined here:
https://www.ietf.org/proceedings/95/slides/slides-95-6man-4.pdf

Then the notion of an interface MTU might not be so helpful. MTU is really a path property between two end hosts.

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Jul 2016 18:13:44 +0900

Ian,

please let's not rehash the arguments about putting routing into DHCPv6.
Last time that happened the resulting controversy was substantial.

Why doesn't the link use RAs? It seems to me that MTU is just one of the
parameters that are needed for link configuration. Other examples are be
router lifetimes, or default router addresses for things like liveness
detection using NUD or failover between multiple routers.

Cheers,
Lorenzo

On Thu, Jul 28, 2016 at 5:49 PM, Ian Farrer <[email-masked]> wrote:

> Hi Bernie,
>
> It sounds like Fred is looking for a DHCPv6 equivalent of DHCPv4 option 26
> which (as I understand it) allows the DHCP server to tell the client the
> interface MTU to use on the link. Is this the same option as the one that
> you’re referring to?
>
> I can also see a use for having this information being sent to the client
> as we plan to use large MTUs to clients. From my perspective, having this
> information inside the PIO would be most useful.
>
> @Fred, if the MTU was carried as an option inside the PIO, and there was a
> way of putting the PIO into DHCP, would this work for you?
>
>
> Ian
>
>
> > I'm not sure why the client wouldn't just use a large buffer (64K) as it
> isn't likely to need many of these buffers? The server is often more
> restrictive since it might be processing many requests at once.
> >
> > And, why would you need to have the server send so much data that the
> client might not be able to receive it all?
> >
> > BTW: I think when this came up during the writing of 3315, it was
> thought that having the client use a 64K buffer wasn't really an issue.
> >
> > - Bernie
> >
> > I'm operating on a link where I don't need to get any configuration
> information from RS/RA - everything comes from DHCPv6. So, ideally, I would
> like to see DHCPv6 provide an MTU option and a Prefix Information Option -
> then I would have everything I need so that I don't have to use a
> vendor-specific option. Would that be possible?
> >
> > Thanks - Fred
> >

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Jul 2016 13:52:20 +0000

OK. For some reason I was thinking of option 22 (max db assembly).

Thanks for providing that link Ole for presentation & draft-van-beijnum-multi-mtu. 

The minutes from 6man @ IETF-95 don't say much about this work:

***BEGIN COPY/PASTE
Extensions for Multi-MTU Subnets, draft-van-beijnum-multi-mtu , Mikael
Abrahamsson, 10 min
-----------------------------------------------------------------

Discussed at IETF 69, 71, and 78.

David Lamparter: suggest doing this for link-local addresses on the basis
of per-link-local-per-interface.

Mark Townsley: really need PMTUD, still have issues about header insertion.
***END COPY/PASTE

So what is the status of this work?

And, note that Fred had indicated "I'm operating on a link where I don't need to get any configuration information from RS/RA - everything comes from DHCPv6." So, looks like at least he wants DHCPv6 option(s). I guess he can always propose this by writing a DHCPv6 draft to provide one or more of the various DHCPv4 MTU options (27, MTU Subnet, is not really applicable for IPv6):

24	MTU Timeout	4	Path MTU Aging Timeout	[RFC2132]
25	MTU Plateau	N	Path MTU Plateau Table	[RFC2132]
26	MTU Interface	2	Interface MTU Size	[RFC2132]
27	MTU Subnet	1	All Subnets are Local	[RFC2132]

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 28, 2016 5:06 AM
To: Ian Farrer <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [dhcwg] MTU option for DHCPv6?

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Jul 2016 23:57:07 +0900

On Thu, Jul 28, 2016 at 10:52 PM, Bernie Volz (volz) <[email-masked]> wrote:

> And, note that Fred had indicated "I'm operating on a link where I don't
> need to get any configuration information from RS/RA - everything comes
> from DHCPv6." So, looks like at least he wants DHCPv6 option(s).

Yes, but it doesn't have to be that way. Sending an RA would work just as
well. Like all RA parameters, it also has the advantage that it is easier
to update dynamically if needed. Doing that in DHCPv6 is more difficult,
because at least as of RFC3315bis, it looks like reconfigure messages MUST
be discarded if they do not include authentication.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:03:10 +0000

Hi Ian,

> From: Ian Farrer [mailto:[email-masked]]
> Sent: Thursday, July 28, 2016 1:49 AM
> To: Bernie Volz (volz) <[email-masked]>
> Cc: <[email-masked]> <[email-masked]>; Templin, Fred L <[email-masked]>
> It sounds like Fred is looking for a DHCPv6 equivalent of DHCPv4 option 26 which (as I understand it) allows the DHCP server to tell the
> client the interface MTU to use on the link. Is this the same option as the one that you’re referring to?

Yes; that is what I was thinking.

> I can also see a use for having this information being sent to the client as we plan to use large MTUs to clients. From my perspective,
> having this information inside the PIO would be most useful.
> 

I'm not sure I see putti ng the MTU option inside the PIO, because there may be many
PIOs but only one MTU value. Can we have both?

Thanks - Fred
[email-masked]

> > I'm not sure why the client wouldn't just use a large buffer (64K) as it isn't likely to need many of these buffers? The server is often
> more restrictive since it might be processing many requests at once.
> >
> > I'm operating on a link where I don't need to get any configuration information from RS/RA - everything comes from DHCPv6. So,
> ideally, I would like to see DHCPv6 provide an MTU option and a Prefix Information Option - then I would have everything I need so
> that I don't have to use a vendor-specific option. Would that be possible?
> >
> > Thanks - Fred
> >

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Jul 2016 15:05:05 +0000

> it looks like reconfigure messages MUST be discarded if they do not include authentication.

It has always been that way (see https://tools.ietf.org/html/rfc3315#section-15.11). Reconfigure uses the Reconfigure Key Authentication Protocol (the server provided the client the key at some point earlier in the client/server interaction). Of course, this does require the client to indicate it is willing to do Reconfigure.

BTW: If I understood draft-van-beijnum-multi-mtu, it is about using ND, not RAs. And this allows [link local] destination specific MTUs to be used.

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, July 28, 2016 10:57 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; Ian Farrer <[email-masked]>; Templin, Fred L <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [dhcwg] MTU option for DHCPv6?

On Thu, Jul 28, 2016 at 10:52 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
And, note that Fred had indicated "I'm operating on a link where I don't need to get any configuration information from RS/RA - everything comes from DHCPv6." So, looks like at least he wants DHCPv6 option(s).

Yes, but it doesn't have to be that way. Sending an RA would work just as well. Like all RA parameters, it also has the advantage that it is easier to update dynamically if needed. Doing that in DHCPv6 is more difficult, because at least as of RFC3315bis, it looks like reconfigure messages MUST be discarded if they do not include authentication.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:05:52 +0000

Hi Lorenzeo,

Ø  Why doesn't the link use RAs?

It does use RAs, only not for configuration information; it uses DHCPv6 for all
configuration information. If the Client sends an RS to the router, it will get back
an RA the same as for any link. It’s just that the RA won’t be providing any
configuration information.

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, July 28, 2016 2:14 AM
To: Ian Farrer <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] MTU option for DHCPv6?

Ian,

please let's not rehash the arguments about putting routing into DHCPv6. Last time that happened the resulting controversy was substantial.

Why doesn't the link use RAs? It seems to me that MTU is just one of the parameters that are needed for link configuration. Other examples are be router lifetimes, or default router addresses for things like liveness detection using NUD or failover between multiple routers.

Cheers,
Lorenzo

On Thu, Jul 28, 2016 at 5:49 PM, Ian Farrer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernie,

Ian

> On 28 Jul 2016, at 00:14, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
>
> From: Templin, Fred L [mailto:[email-masked]<mailto:[email-masked]>]
> To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
>> From: Bernie Volz (volz) [mailto:[email-masked]<mailto:[email-masked]>]
>> To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
>> <[email-masked]<mailto:[email-masked]>>
>> From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Templin, Fred
>> L
>> To: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:10:08 +0000

RA doesn’t provide nearly the same configuration flexibility as DHCPv6. RA also
doesn’t have Rebind/Renew/Release messags that can be used to manage
mobiole devices. And, RA also does not have DHCPv6 Security. (RA does have
SEND, but I have not heard of that as being widely deployed). Finally, RA does
not have the back-end database management capabilities that are built into
common public domain DHCPv6 implementations.

Thanks – Fred

Sent: Thursday, July 28, 2016 7:57 AM

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:18:16 +0000

Hi Bernie,

The MTU option I am talking about allows link administrators to set the MTU value that
all nodes on the link must use. draft-van-beijunm-multi-mtu proposed having different
MTU values among the nodes no the link, but there is at least one problem with that.
In particular, IP multicast expects that all nodes on the link will be able to receive multicast
packets as large as the link MTU. So, for example, if node A on the link configured an MTU
of 8KB and node B configured an MTU of 4KB, the 8KB multicasts sent by node A would
not reach node B – and this violates the reasonable expectation of nodes attached to
the same link. Therefore, the DHCPv6 MTU option should encode the minimum MTU
among the (potential) MTUs of all nodes on the link, which in this case would be 4KB.

Interestingly, draft-van-beijnum-multi-mtu does not have a section on multicast.

Thanks – Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Thursday, July 28, 2016 8:05 AM
To: Lorenzo Colitti <[email-masked]>
Cc: [email-masked]; Ian Farrer <[email-masked]>; Templin, Fred L <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: RE: [dhcwg] MTU option for DHCPv6?

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, July 28, 2016 10:57 AM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ian Farrer <[email-masked]<mailto:[email-masked]>>; Templin, Fred L <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] MTU option for DHCPv6?

---

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

On point to point links like cellular, RA makes little sense, is not 
specified formally (IPv6-over-Ethernet-over-cellular) and is cause of 
incompatibility issues; when used as part of SLAAC with privacy address 
concepts the RA was witnessed to result in huge number of addresses 
self-configured.

The INFORMATIONAL 64share is another result of using wrongly RAs on ptp 
links.

These things dont happen with ppp or DHCP which are more adapted to ptp 
links like cellular.

Alex

Le 28/07/2016 à 17:10, Templin, Fred L a écrit :
> *From:*Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Thursday, July 28, 2016 7:57 AM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* [email-masked]; Ian Farrer <[email-masked]>; Templin,
> Fred L <[email-masked]>; <[email-masked]> <[email-masked]>
> *Subject:* Re: [dhcwg] MTU option for DHCPv6?
>
>
>
>     And, note that Fred had indicated "I'm operating on a link where I
>     don't need to get any configuration information from RS/RA -
>     everything comes from DHCPv6." So, looks like at least he wants
>     DHCPv6 option(s).
>
>
>
> Yes, but it doesn't have to be that way. Sending an RA would work just
> as well. Like all RA parameters, it also has the advantage that it is
> easier to update dynamically if needed. Doing that in DHCPv6 is more
> difficult, because at least as of RFC3315bis, it looks like reconfigure
> messages MUST be discarded if they do not include authentication.
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Jul 2016 00:23:53 +0900

Alexandre, that doesn't make sense. The only specified mechanism for IPv6
on 3GPP links is RAs.

There is no Ethernet on cellular links, where did you get that from?

The fact that the host can configure lots of addresses is a feature, not a
bug. It makes useful features like /64 sharing possible.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Jul 2016 00:30:22 +0900

On Fri, Jul 29, 2016 at 12:10 AM, Templin, Fred L <[email-masked]
> wrote:

> mobiole devices. And, RA also does not have DHCPv6 Security.
>

What does this link look like? Is it a point-to-point link? If so, then RAs
are equivalent to DHCPv6 because they are effectively unicasted to a single
client. As for security, basic DHCPv6 doesn't usually provide security
either. And if the link is wireless, I would hope it does encryption
already?

> Finally, RA does not have the back-end database management capabilities
> that are built into common public domain DHCPv6 implementations.
>
It's perfectly possible to do this with RAs. The Framed-IPv6-prefix option
was defined in 2001. When I looked at it as far back as 2010, common
implementations (e.g., Juniper) were perfectly capable of create dynamic
VLANs and configure RA parameters based on radius attributes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Jul 2016 00:31:26 +0900

On Fri, Jul 29, 2016 at 12:05 AM, Templin, Fred L <[email-masked]

>
> If the Client sends an RS to the router, it will get back an RA the same
> as for any link. It’s just that the RA won’t be providing any configuration
> information.
>

What's wrong with adding the MTU option to that RA? That is supported by
pretty much all routers and clients today.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:35:29 +0000

Hi Lorenzo,

The link is NBMA – and there could be a quite large number of nodes on the link.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, July 28, 2016 8:30 AM
To: Templin, Fred L <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; [email-masked]; Ian Farrer <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [dhcwg] MTU option for DHCPv6?

On Fri, Jul 29, 2016 at 12:10 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

What does this link look like? Is it a point-to-point link? If so, then RAs are equivalent to DHCPv6 because they are effectively unicasted to a single client. As for security, basic DHCPv6 doesn't usually provide security either. And if the link is wireless, I would hope it does encryption already?

Finally, RA does not have the back-end database management capabilities that are built into common public domain DHCPv6 implementations.
It's perfectly possible to do this with RAs. The Framed-IPv6-prefix option was defined in 2001. When I looked at it as far back as 2010, common implementations (e.g., Juniper) were perfectly capable of create dynamic VLANs and configure RA parameters based on radius attributes.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:39:16 +0000

Hi Lorenzo,

Ø  What's wrong with adding the MTU option to that RA? That is supported by pretty much all routers and clients today.

Being lazy as I am, I just don’t want to have to send multiple messages to get
all of the configuration information the client needs. If the DHCPv6 Reply
contains all configuration information, then there is no need to also perform
an RS/RA just to get the MTU value.

Granted, RS/RA could be used later the same as for any link, but it would be
more for keepalive-type purposes and not for configuration information.

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, July 28, 2016 8:31 AM
To: Templin, Fred L <[email-masked]>
Cc: Ian Farrer <[email-masked]>; <[email-masked]> <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] MTU option for DHCPv6?

On Fri, Jul 29, 2016 at 12:05 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

If the Client sends an RS to the router, it will get back an RA the same as for any link. It’s just that the RA won’t be providing any configuration information.

What's wrong with adding the MTU option to that RA? That is supported by pretty much all routers and clients today.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 28 Jul 2016 16:45:25 +0100

> an RS/RA just to get the MTU value.

I'm curious. OK I've probably missed a few things, but I was under the impression that clients won't (can't ?) do DHCPv6 unless the RA tells them it's a managed network. Also, if clients are self-configuring multiple addresses, doesn't that imply the RAs they are acting on have the wrong options set ?

And given that (AIUI) DHCPv6 doesn't include any routing information (as that's supposed to come from the RAs), how are the clients getting that information ?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jul 2016 15:51:40 +0000

Hi Simon,

> From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
> Sent: Thursday, July 28, 2016 8:45 AM
> To: [email-masked]
> > Being lazy as I am, I just don't want to have to send multiple messages to get
> I'm curious. OK I've probably missed a few things, but I was under the impression that clients won't (can't ?) do DHCPv6 unless the RA
> tells them it's a managed network. Also, if clients are self-configuring multiple addresses, doesn't that imply the RAs they are acting on
> have the wrong options set ?

The IPv6-over-(foo) document gets to tell how IPv6 ND and DHCPv6 operate over the
link. At least for the link type I am considering, nodes on the link use DHCPv6 without
waiting to first get an RA with M/O bits.

> getting that information ?

Do you mean default router lifetime? For the link type I am considering, the
default router lifetime is derived from the IA_NA/IA_PD lease lifetime.

Thanks - Fred

______________________________________________

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Jul 2016 19:27:37 +0200

Le 28/07/2016 à 17:23, Lorenzo Colitti a écrit :
> Alexandre, that doesn't make sense. The only specified mechanism for
> IPv6 on 3GPP links is RAs.

I would doubt so.  I think DHCPv6 is there in the 3GPP specs too.

> There is no Ethernet on cellular links, where did you get that from?

 From packet dumps, looking at the headers.

> The fact that the host can configure lots of addresses is a feature, not
> a bug. It makes useful features like /64 sharing possible.

It were a feature _if_ forwarding were associated with it upon allocation.

But that /64 is advertised as on-link (no routing associated with it), 
as if there were 2^64 neighbors on that link; there are only two.  As 
such it is over-provisioining, not a feature.

It is a feature in which it invites for 64share, which when looked at 
closely is a hack.

It is a bug when the Host configures so many IPv6 addresses on its 
interface.  It's looking like getting out of hand.

Alex

>
> On Fri, Jul 29, 2016 at 12:19 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     specified formally (IPv6-over-Ethernet-over-cellular) and is cause
>     of incompatibility issues; when used as part of SLAAC with privacy
>     address concepts the RA was witnessed to result in huge number of
>     addresses self-configured.
>
>     The INFORMATIONAL 64share is another result of using wrongly RAs on
>     ptp links.
>
>     These things dont happen with ppp or DHCP which are more adapted to
>     ptp links like cellular.
>
>     Alex
>
>         RA doesn’t provide nearly the same configuration flexibility as
>         DHCPv6.
>         RA also
>
>         SEND, but I have not heard of that as being widely deployed).
>         Finally,
>         RA does
>
>         [email-masked] <mailto:[email-masked]>
>
>
>
>         *From:*Lorenzo Colitti [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *To:* Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>
>         *Cc:* [email-masked] <mailto:[email-masked]>; Ian
>         Farrer <[email-masked] <mailto:[email-masked]>>; Templin,
>         Fred L <[email-masked]
>         <mailto:[email-masked]>>; <[email-masked]
>         <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>         On Thu, Jul 28, 2016 at 10:52 PM, Bernie Volz (volz)
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Jul 2016 23:20:40 +0900

> I would doubt so.  I think DHCPv6 is there in the 3GPP specs too.

DHCPv6 PD (only) was added in release 10. SLAAC has been there for at least
a decade, I think.

> From packet dumps, looking at the headers.

Just because the driver of a device you own pretends that the 3GPP link is
an Ethernet link doesn't mean that there's Ethernet on the air. Look at an
Android phone and you'll see something completely different - no Ethernet
address and a different ARPHRD_xxx value.

> interface.  It's looking like getting out of hand.

RFC 7934 claims the opposite.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 29 Jul 2016 17:14:16 +0200

Le 29/07/2016 à 16:20, Lorenzo Colitti a écrit :
> On Fri, Jul 29, 2016 at 2:27 AM, Alexandre Petrescu
> DHCPv6 PD (only) was added in release 10. SLAAC has been there for at
> least a decade, I think.
>
>
> Just because the driver of a device you own pretends that the 3GPP
> link is an Ethernet link doesn't mean that there's Ethernet on the
> air.

I agree, there may be no Ethernet headers in the air of cellular links.

But there is an additional indicator.  Companies like Huawei and Sierra
have requested and paid for IEEE OUI numbers that they use to form MAC
addresses on cellular links (Huawei E392 4G LTE dongle, Sierra Wireless
Airprime module).  These IEEE OUI numbers and MAC addresses are
obviously not part of 3GPP specs either, yet they are there printed
on the boards, in the driver, etc.  I suspect these MAC addresses do get
sent over the air on cellular links.

Add to this that in some cases this is on USB too.

This is completely unspecified behaviour (no IPv6-over-USB, no 3GPP
specs mention IEEE addressing, etc).

> Look at an Android phone and you'll see something completely
> different - no Ethernet address and a different ARPHRD_xxx value.

Somehow I dont understand ARPHRD_xxx value.

I wonder what chipset the Android phone in question uses to communicate
on cellular?

I am asking because I just got hold of a brand new Huwaei Mate 8 phone
running Androing, and I still have to figure whether this uses these
Huawei IEEE OUI MAC addresses on cellular links (like the Huawei dongle
does).

> RFC 7934 claims the opposite.

This is an excellent RFC that makes it an excellent case to deliver many
addresses to Host, instead of just one.

But there are a couple of ways to satisfy that requirement (give more
addresses to a Host) and one of the ways is pretty bad.  RA a /64 to a
Host is not the right way to deliver many addresses to a Host.

Unless you agree that a Prefix Delegation during RA operation may be a
good idea?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 29 Jul 2016 17:16:43 +0200

Le 29/07/2016 à 17:14, Alexandre Petrescu a écrit :
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Alexandre, that doesn't make sense. The only specified mechanism
>> for IPv6 on 3GPP links is RAs.
>>
>>
>> DHCPv6 PD (only) was added in release 10. SLAAC has been there for
>> at least a decade, I think.
>>
>>
> But there is an additional indicator.  Companies like Huawei and
> Sierra have requested and paid for IEEE OUI numbers that they use to
> form MAC addresses on cellular links (Huawei E392 4G LTE dongle,
> Sierra Wireless Airprime module).  These IEEE OUI numbers and MAC
> addresses are obviously not part of 3GPP specs either, yet they are
> there printed on the boards, in the driver, etc.  I suspect these
> MAC addresses do get sent over the air on cellular links.
>
> I wonder what chipset the Android phone in question uses to
> communicate on cellular?
>
> I am asking because I just got hold of a brand new Huwaei Mate 8
> phone running Androing,
                         ^^H^Hd (Android)

> and I still have to figure whether this uses these Huawei IEEE OUI
> MAC addresses on cellular links (like the Huawei dongle does).
>
> This is an excellent RFC that makes it an excellent case to deliver
> many addresses to Host, instead of just one.
>
> addresses to a Host) and one of the ways is pretty bad.  RA a /64 to
> a Host is not the right way to deliver many addresses to a Host.
>
> Unless you agree that a Prefix Delegation during RA operation may be
> a good idea?
>
> Alex
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg