Re: [dhcwg] MTU option for DHCPv6?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 28 July 2016 17:27 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115912DABC for <dhcwg@ietfa.amsl.com>; Thu, 28 Jul 2016 10:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN1s5EtdGXKr for <dhcwg@ietfa.amsl.com>; Thu, 28 Jul 2016 10:27:41 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B5912DAB5 for <dhcwg@ietf.org>; Thu, 28 Jul 2016 10:27:40 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6SHRbTa027934; Thu, 28 Jul 2016 19:27:38 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E11C7208449; Thu, 28 Jul 2016 19:27:37 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D281A2082F7; Thu, 28 Jul 2016 19:27:37 +0200 (CEST)
Received: from [132.166.84.73] ([132.166.84.73]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6SHRbXj018152; Thu, 28 Jul 2016 19:27:37 +0200
To: Lorenzo Colitti <lorenzo@google.com>
References: <8c706ad593cc403d9e738c7aafec8360@XCH15-05-05.nw.nos.boeing.com> <5671d2f3bf364bec9b70ab8cbb9cd2a9@XCH-ALN-003.cisco.com> <9db5a86d50314519b4fcc4589717f802@XCH15-05-05.nw.nos.boeing.com> <f98d75f73d224798a406084fdb4cdedc@XCH-ALN-003.cisco.com> <F22A046E-27FA-4EED-9699-70A6B3D49A66@gmx.com> <20AC7B4D-430C-4D56-8D5C-1E134AEEDA76@employees.org> <516a0ed770414d0095ca69905c3a83a3@XCH-ALN-003.cisco.com> <CAKD1Yr2nx_GeyZJ7YA3b1zktRUG-yvkRQKOVywzg0i7s=WTyaw@mail.gmail.com> <4725f6ba7bbf4b9ab5c4c23a04f41518@XCH15-05-05.nw.nos.boeing.com> <f72eede6-83b8-80bb-573c-17580d0e02a5@gmail.com> <CAKD1Yr23QkpXpoZa1pxzZz-HTqQQDBS0k=jyvvssivjQqmraZw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <7d3a9eb3-cee3-d855-0bc6-0c397b29a963@gmail.com>
Date: Thu, 28 Jul 2016 19:27:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr23QkpXpoZa1pxzZz-HTqQQDBS0k=jyvvssivjQqmraZw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Ej0ntasdHfQrPVebNMRhBz3s4Po>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] MTU option for DHCPv6?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2016 17:27:43 -0000


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