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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 02 March 2017 19:25 UTC

Return-Path: <prvs=1234a5327c=jordi.palet@consulintel.es>
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 1A66D129543 for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 11:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 mWGNWmnd8P0R for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 11:25:40 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0022129488 for <ipv6@ietf.org>; Thu, 2 Mar 2017 11:25:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488482735; x=1489087535; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=NjIqf+ljYkKBqrXNP5gqIH6xH sFKmtsgAowtKH7rVd4=; b=WGUX10HECcqOC0pGISsa5etd8YA7zCFqjWtv6hDGB xjEkskWS8QzQER78YDVgo8lE3yov0PKs6j1kCYgWwx0mLjDLUpKNurvov+n/LYOi eZlupQ+TYYw1fEnf7LHCVi2Y88t6owwaeaqg9yicrr2kb5h+FeEvhZPrljin/EOm fw=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Thvd27UcYOgg+TkozK0IwGKVVhnS9okmd7z7OuiJheEMCBMFjptqV0BSXySp LoN/RTzHUdKSzAQi6ZY3GjQq61RMNNrJpE3pEt58ouuLKlZFcxVydtOum cPcCTUxDIrWUTe7Cu14bLBFBSiuPqbwJyiKq6FjeFvTwGr4tHZ6HMc=;
X-MDAV-Processed: mail.consulintel.es, Thu, 02 Mar 2017 20:25:35 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 02 Mar 2017 20:25:32 +0100
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005377531.msg for <ipv6@ietf.org>; Thu, 02 Mar 2017 20:25:32 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170302:md50005377531::cX3IzEkRGvgbxpz8:00004WZj
X-Return-Path: prvs=1234a5327c=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.1f.0.170216
Date: Thu, 02 Mar 2017 20:25:29 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <ipv6@ietf.org>
Message-ID: <E2709C92-4C32-4E1C-A8A1-B6B98F0BF336@consulintel.es>
Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt
References: <20170223134026.GI5069@gir.theapt.org> <CAKD1Yr0wK8EiAbz39EZz-xZLtsSV2JROSzNECKtGo36Zc=RZ0Q@mail.gmail.com> <CAN-Dau2N-fv3o9o4807m_fbMktjC6hq28sMZhfECKg5cbb4g6Q@mail.gmail.com> <CAKD1Yr3tHm5x29w4L5KtKi7PqDHRxkPr6i9mJMtHLaPc2eM2GQ@mail.gmail.com> <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>
In-Reply-To: <b6ff1b86-698c-0b8f-6a08-7d6bf8a33c8f@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/T5SchKhbsfDoJ7CAEGzWLTZ7yFk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
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: Thu, 02 Mar 2017 19:25:42 -0000

I understood from one of your previous emails that 3GPP doesn’t require DHCPv6-PD. 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).

In IPv6-only world (including cellular), the WAN link will be IPv6-only instead of dual-stack. This is already happening.

If they don’t use it, I guess is the same reason why big vendors didn’t implemented yet RDDNS …

Cellular world is using 464XLAT, and they use DHCPv6-PD. Check RFC6877.

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-survey
    >
    >>
    >>
    >
    >> Saludos, Jordi
    >>
    >>
    >> -----Mensaje original----- De: ipv6 <ipv6-bounces@ietf.org>; en
    >> nombre de Mikael Abrahamsson <swmike@swm.pp.se>; Organización:
    >> 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.