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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 03 March 2017 09:29 UTC

Return-Path: <alexandre.petrescu@gmail.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 EED931297CA for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 01:29:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level:
X-Spam-Status: No, score=-5.352 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, 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 9OLYpbA8qLgS for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 01:29:11 -0800 (PST)
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 70EAE1297AA for <ipv6@ietf.org>; Fri, 3 Mar 2017 01:29:10 -0800 (PST)
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 v239T8M0000845; Fri, 3 Mar 2017 10:29:08 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 742F5203BEF; Fri, 3 Mar 2017 10:29:08 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 65D7F200CE6; Fri, 3 Mar 2017 10:29:08 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239T8rP025210; Fri, 3 Mar 2017 10:29:08 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Mark Andrews <marka@isc.org>
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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com>
Date: Fri, 3 Mar 2017 10:29:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170302224856.E63AB65D34EC@rock.dv.isc.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xf6OjZGdelYBAv60RtyX0RlVJEw>
Cc: 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 09:29:14 -0000


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