Re: [dhcwg] MTU option for DHCPv6?

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
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
>
>     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 :
>
>         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
>
>         fred.l.templin@boeing.com <mailto:fred.l.templin@boeing.com>
>
>
>
>         *From:*Lorenzo Colitti [mailto:lorenzo@google.com
>         <mailto:lorenzo@google.com>]
>         *Sent:* Thursday, July 28, 2016 7:57 AM
>         *To:* Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>>
>         *Cc:* otroan@employees.org <mailto:otroan@employees.org>; Ian
>         Farrer <ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>>; Templin,
>         Fred L <Fred.L.Templin@boeing.com
>         <mailto:Fred.L.Templin@boeing.com>>; <dhcwg@ietf.org
>         <mailto:dhcwg@ietf.org>> <dhcwg@ietf.org <mailto:dhcwg@ietf.org>>
>         *Subject:* Re: [dhcwg] MTU option for DHCPv6?
>
>
>
>         On Thu, Jul 28, 2016 at 10:52 PM, Bernie Volz (volz)
>         <volz@cisco.com <mailto:volz@cisco.com>
>         <mailto:volz@cisco.com <mailto:volz@cisco.com>>> 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.
>
>
>
>         _______________________________________________
>         dhcwg mailing list
>         dhcwg@ietf.org <mailto:dhcwg@ietf.org>
>         https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>     _______________________________________________
>     dhcwg mailing list
>     dhcwg@ietf.org <mailto:dhcwg@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dhcwg
>
>