RE: Objection to draft-ietf-6man-rfc4291bis-07.txt

<mohamed.boucadair@orange.com> Fri, 03 March 2017 10:30 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8309712947A for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 02:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 QZg3ww_30qG4 for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 02:30:39 -0800 (PST)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DFD12943E for <ipv6@ietf.org>; Fri, 3 Mar 2017 02:30:39 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 94085C0263; Fri, 3 Mar 2017 11:30:37 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 5C7FD1A0063; Fri, 3 Mar 2017 11:30:37 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Fri, 3 Mar 2017 11:30:37 +0100
From: <mohamed.boucadair@orange.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Mark Andrews <marka@isc.org>
Subject: RE: Objection to draft-ietf-6man-rfc4291bis-07.txt
Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt
Thread-Index: AQHSlACeVr+y/Sr+qUWS2y7pqG6meKGC6Lrw
Date: Fri, 3 Mar 2017 10:30:36 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <CAKD1Yr2AYaAQMuGZiKXYwKdgz1dzKs5fc5bm7hQjpuq3O_V8gQ@mail.gmail.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <CAKD1Yr1cNihxMVHjY2j7mcCNU2TE0X6-0p2mDNCBVVUcUbU20Q@mail.gmail.com> <20170302153611.36506f85@envy> <CAKD1Yr1SbdE-i-oGhi2kEFBWTOi_-FzgVdMYkMWjCEtw0MRRMg@mail.gmail.com> <ee3b73b1-64fd-6fef-bc0a-53b325f0bcfd@gmail.com> <alpine.DEB.2.02.1703021902010.30226@uplift.swm.pp.se> <efe2504e-198c-36ce-c79f-be1886e5d031@gmail.com> <alpine.DEB.2.02.1703021929170.30226@uplift.swm.pp.se> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <b6ff1b86-698c-0b8f-6a08-7d6bf8a33c8f@gmail.com> <E2709C92-4C32-4E1C-A8A1-B6B98F0BF336@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com>
In-Reply-To: <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Yu9GlZwwF1DsYBtlRYLG8hy7qjg>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 10:30:41 -0000

Hi Alex,


> This is why I dont understand the cellular operators dont do DHCPv6-PD.
>   And I guess it is so because they are told it's sufficient to run the
> 64share INFORMATIONAL RFC.

This is a chicken-and-egg problem: you need both the cellular device and the network side to support prefix delegation + prefix exclude option, but while waiting for that to happen /64 share is your solution. Below what you can read in RFC7849:

=====
   L_REC#1:  For deployments that require that the same /64 prefix be
             shared, the cellular device should support [RFC7278] to
             enable sharing a /64 prefix between the LAN and the WAN
             interfaces.  The WAN interface is the one towards the
             Gateway GPRS Support Node (GGSN) / Packet Data Network
             Gateway (PGW).

                Prefix Delegation (refer to L_REC#2) is the target
                solution for distributing prefixes in the LAN side but,
                because the device may attach to earlier 3GPP release
                networks, a means to share a /64 prefix is also
                recommended [RFC7278].

                [RFC7278] must be invoked only if Prefix Delegation is
                not in use.

   L_REC#2:  The cellular device must support Prefix Delegation
             capabilities [RFC3633] and must support the Prefix Exclude
             Option for DHCPv6-based Prefix Delegation as defined in
             [RFC6603].  Particularly, it must behave as a Requesting
             Router.

                Cellular networks are more and more perceived as an
                alternative to fixed broadband networks for home IP-
                based services delivery; especially with the advent of
                smartphones and 3GPP data dongles.  There is a need for
                an efficient mechanism to assign larger prefixes (other
                than /64s) to cellular hosts so that each LAN segment
                can get its own /64 prefix and multi-link subnet issues
                to be avoided.

                In case a prefix is delegated to a cellular host using
                DHCPv6, the cellular device will be configured with two
                prefixes:

                (1)  one for the 3GPP link allocated using the Stateless
                     Address Autoconfiguration (SLAAC) mechanism and

                (2)  another one delegated for LANs acquired during the
                     Prefix Delegation operation.

                Note that the 3GPP network architecture requires both
                the WAN and the delegated prefix to be aggregatable so
                the subscriber can be identified using a single prefix.

                Without the Prefix Exclude Option, the delegating router
                (GGSN/PGW) will have to ensure compliance with [RFC3633]
                (e.g., halving the delegated prefix and assigning the
                WAN prefix out of the first half and the prefix to be
                delegated to the terminal from the second half).

                Because Prefix Delegation capabilities may not be
                available in some attached networks, L_REC#1 is strongly
                recommended to accommodate early deployments.
=====

Cheers,
Med


> -----Message d'origine-----
> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Alexandre Petrescu
> Envoyé : vendredi 3 mars 2017 10:29
> À : Mark Andrews
> Cc : ipv6@ietf.org
> Objet : Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
> 
> 
> 
> Le 02/03/2017 à 23:48, Mark Andrews a écrit :
> >
> > In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>;,
> > Alexandre Petrescu writes:
> >> Le 02/03/2017  20:25, JORDI PALET MARTINEZ a crit :
> >>> I understood from one of your previous emails that 3GPP doesnt
> >>> require DHCPv6-PD.
> >>
> >> Right - if I understand correctly, it does not require DHCPv6-PD on
> >> the UE.  Maybe in the core, but not in the UE.
> >>
> >>> RFC6653, suggest its use, so probably we got confused ourselves
> >>> and 3GPP is actually using it.
> >>>
> >>> 6rd is a different thing, because is actually IPv4 link and IPv6
> >>>  is a tunnel, so you typically use DHCP (v4).
> >>
> >> I agree.
> >>
> >>> In IPv6-only world (including cellular), the WAN link will be
> >>> IPv6-only instead of dual-stack. This is already happening.
> >>>
> >>> If they dont use it, I guess is the same reason why big vendors
> >>> didnt implemented yet RDDNS
> >>
> >> I wonder if Windows refusing RDNSS doesn't have somehting to do
> >> with its Teredo; and extending this logic to smartphones: the lack
> >>  of answers to DHCPv6-PD issued from the UE may have something to
> >> do with 464xlat presence.
> >>
> >> Could it be that 464xlat presence on UE makes it that DHCPv6-PD is
> >> impossible on same UE?
> >
> > No.  They are or should be orthogonal.  One is about providing IPv4
> > as as service.  The other is about providing IPv6 address space.
> 
> I can agree.
> 
> With my operator I asked her once 'why not giving DHCPc6-PD to
> smartphone' and she replied 'because now we do 464xlat on the
> smartphone, and that is sufficient'.  As such it sounds illogical
> statement, although I guess s/he has some reasons to say so.
> 
> But let me ask differently: maybe it's because 464xlat requires some
> kernel version that DHCPv6-PD doestn support, or vice-versa?  Maybe it's
> because once you run 464xlat on smartphone it takes control of the
> unique default route and DHCPv6-PD couldnt?  Some reason like that?
> 
> Has one tried DHCPv6-PD software simultaneosuly with 464xlat? (even
> knowing the cellular operator would not reply to DHCPv6 Slicitations).
> 
> >>> Cellular world is using 464XLAT, and they use DHCPv6-PD. Check
> >>> RFC6877.
> >>
> >> I guess you mean cellular stations (like BS, not the User
> >> Equipment) uses DHCPv6-PD within the fixed network.
> >
> > No, the UE should be using DHCPv6-PD.  This is how tethered
> > equipement should be getting IPv6 address space.
> 
> I agree with yuo.
> 
> This is why I dont understand the cellular operators dont do DHCPv6-PD.
>   And I guess it is so because they are told it's sufficient to run the
> 64share INFORMATIONAL RFC.
> 
> Are the people advising 64share to tethering-willing telecom operators
> conscious it's non-interoperable?
> 
> Is the 64share advice coming together with the claim there are enough
> /64s out there?
> 
> Alex
> 
> >> Because cellular operator I am aware of replies to DHCPv6-PD
> >> requests issued from an User Equipment.
> >>
> >> Alex
> >>
> >>>
> >>> Saludos, Jordi
> >>>
> >>>
> >>> -----Mensaje original----- De: ipv6 <ipv6-bounces@ietf.org>; en
> >>> nombre de Alexandre Petrescu <alexandre.petrescu@gmail.com>;
> >>> Responder a: <alexandre.petrescu@gmail.com>; Fecha: jueves, 2 de
> >>> marzo de 2017, 20:15 Para: <ipv6@ietf.org>; Asunto: Re: Objection
> >>>  to draft-ietf-6man-rfc4291bis-07.txt
> >>>
> >>>
> >>>
> >>> Le 02/03/2017  20:06, JORDI PALET MARTINEZ a crit :
> >>>> I guess because the lack of DHCPv6-PD support, as you already
> >>>> indicated?
> >>>
> >>> But for deity's sake - DHCPv6-PD is available as open source...
> >>> it's common software.  Just download and install.  The IETF Specs
> >>> suggest it, and the 3GPP specs require it too.
> >>>
> >>> There must be something else making these router equipment
> >>> manufacturers refraining from downloading and installing
> >>> DHCPv6-PD.
> >>>
> >>>> I think majority of the households and business customers get
> >>>> configured the CPE by means for DHCPv6-PD
> >>>
> >>> AFAIK my CPE at home does not use DHCPv6-PD, but something based
> >>>  on IPv4, like 6rd.  I think it's something developped in-house
> >>> at that particular operator.
> >>>
> >>> Alex
> >>>
> >>>>
> >>>> Saludos, Jordi
> >>>>
> >>>>
> >>>> -----Mensaje original----- De: ipv6 <ipv6-bounces@ietf.org>; en
> >>>> nombre de Alexandre Petrescu <alexandre.petrescu@gmail.com>;
> >>>> Responder a: <alexandre.petrescu@gmail.com>; Fecha: jueves, 2
> >>>> de marzo de 2017, 20:02 Para: <ipv6@ietf.org>; Asunto: Re:
> >>>> Objection to draft-ietf-6man-rfc4291bis-07.txt
> >>>>
> >>>>
> >>>>
> >>>> Le 02/03/2017  19:54, JORDI PALET MARTINEZ a crit :
> >>>>> Actually, is not correct that most use /56 for residential.
> >>>>>
> >>>>>> From my last review of the survey, worldwide, 22% use /48,
> >>>>>>  35% use /56, but there is a lot of ISPs (33%) doing it
> >>>>>> wrong and using /64, which of course, we are explaining
> >>>>>> them that is wrong. 10% use other sizes.
> >>>>
> >>>> So how comes that households can get /56s but smartphones no?
> >>>>
> >>>> Really there must be something there hidden.
> >>>>
> >>>> Alex
> >>>>
> >>>>>
> >>>>> Full details at:
> >>>>>
> >>>>>
> >> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-
> deployment-s
> >>
> >>
> >>
> >>
> urvey
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>>>
> >>>>>
> >>>>
> >>>>> Saludos, Jordi
> >>>>>
> >>>>>
> >>>>> -----Mensaje original----- De: ipv6 <ipv6-bounces@ietf.org>;
> >>>>> en nombre de Mikael Abrahamsson <swmike@swm.pp.se>;
> >>>>> Organizacin: People's Front Against WWW Responder a:
> >>>>> <swmike@swm.pp.se>; Fecha: jueves, 2 de marzo de 2017, 19:33
> >>>>> Para: Alexandre Petrescu <alexandre.petrescu@gmail.com>; CC:
> >>>>> <ipv6@ietf.org>; Asunto: Re: Objection to
> >>>>> draft-ietf-6man-rfc4291bis-07.txt
> >>>>>
> >>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote:
> >>>>>
> >>>>>> YEs yes, but how much of that /44 is covering the
> >>>>>> end-users and how much is reserved for interconnnections?
> >>>>>
> >>>>> Nothing. It's /44 to the GGSN/SPGW.
> >>>>>
> >>>>>> Ah great, but I guess few cellular operators (if any?) are
> >>>>>> LIRs. Or maybe that's true and I didnt know.
> >>>>>
> >>>>> You don't know.
> >>>>>
> >>>>>> If all this were that simple and clearcut - there are
> >>>>>> enough /64s out there - then why operators only assign one
> >>>>>>  per one end user?
> >>>>>
> >>>>> Because DHCPv6-PD hasn't been implemented in mobile networks
> >>>>>  yet (that I know of). So that's all they can do per 3GPP
> >>>>> standards.
> >>>>>
> >>>>> Residential rollouts, most use /56 per customer.
> >>>>>
> >>>>>> From the RIRs, you can without further justification get
> >>>>>> /48 per "site",
> >>>>> so if you show up to RIR and you're LIR and you say "hello,
> >>>>> I have 40 million customers and I want to give each customer
> >>>>> a /48" then they'll give you a /22 most likely. You're
> >>>>> perfectly within your right as an operator to deploy /48 per
> >>>>>  customer per current RIR rules that I am aware of.
> >>>>>
> >>>>> -- Mikael Abrahamsson    email: swmike@swm.pp.se
> >>>>>
> >>>>> --------------------------------------------------------------------
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>>>
> >>>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>>>
> >>>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> ********************************************** IPv4 is over Are
> >>>>> you ready for the new Internet ? http://www.consulintel.es
> >>>>> The IPv6 Company
> >>>>>
> >>>>> This electronic message contains information which may be
> >>>>> privileged or confidential. The information is intended to
> >>>>> be for the use of the individual(s) named above. If you are
> >>>>> not the intended recipient be aware that any disclosure,
> >>>>> copying, distribution or use of the contents of this
> >>>>> information, including attached files, is prohibited.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --------------------------------------------------------------------
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>>>
> >>>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> --------------------------------------------------------------------
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> IETF IPv6 working group mailing list ipv6@ietf.org
> >>> Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> ********************************************** IPv4 is over Are
> >>>> you ready for the new Internet ? http://www.consulintel.es The
> >>>> IPv6 Company
> >>>>
> >>>> This electronic message contains information which may be
> >>>> privileged or confidential. The information is intended to be
> >>>> for the use of the individual(s) named above. If you are not
> >>>> the intended recipient be aware that any disclosure, copying,
> >>>> distribution or use of the contents of this information,
> >>>> including attached files, is prohibited.
> >>>>
> >>>>
> >>>>
> >>>> --------------------------------------------------------------------
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>>
> >>>>
> >>>>
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list ipv6@ietf.org
> >>> Administrative Requests:
> >>> https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> ********************************************** IPv4 is over Are you
> >>> ready for the new Internet ? http://www.consulintel.es The IPv6
> >>> Company
> >>>
> >>> This electronic message contains information which may be
> >>> privileged or confidential. The information is intended to be for
> >>> the use of the individual(s) named above. If you are not the
> >>> intended recipient be aware that any disclosure, copying,
> >>> distribution or use of the contents of this information,
> >>> including attached files, is prohibited.
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> >>
> >>>
> >>>
> >>>
> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------