Re: [v6ops] reclassify 464XLAT as standard instead of info

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 21 September 2017 14:04 UTC

Return-Path: <prvs=14370a98a6=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72913235C for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 07:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 06sFFnVcKHN5 for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 07:04:18 -0700 (PDT)
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 8EDEE1321C7 for <v6ops@ietf.org>; Thu, 21 Sep 2017 07:04:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506002655; x=1506607455; 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=GwNQP3Khs3+xtyRceaAnNzIrw oz1vMIeNP5zC8OSjaU=; b=YcaosnYonFayD3rnVAxSGz3Cow7lKuOL1QDuBiZAH DQIWaYsz0g+YYRF3oOmXa0NArNF9/R8Zw0yWTIlEjjxj4Ms69nH4a9RlBSnmGRcD QzixTg/UZfzguwMsyVQH9J3cpJtdKCtBkybQZhFRvGYvkPpwMtsQfUy1QLEYcDJz tg=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=A8l2SgE7vWTcP/VKE5w0hRxBVTBtziDQ2IfIQP7K0UnXY+0a7PoPxgq2VtVe zUskYkDPCMZUVDPRImjsNp8DD6gIr6MCgasSLBT6xS5geR1XAhQPCVYhc eWxnOGhBu9ef5xbOHmrEci2UPbexfmcccXxgNsf1jwPijgskSF8MNE=;
X-MDAV-Processed: mail.consulintel.es, Thu, 21 Sep 2017 16:04:15 +0200
X-Spam-Processed: mail.consulintel.es, Thu, 21 Sep 2017 16:04:15 +0200
Received: from [45.6.251.164] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005562228.msg for <v6ops@ietf.org>; Thu, 21 Sep 2017 16:04:15 +0200
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:170921:md50005562228::I87ya5a/1HZk7Inx:00001HMG
X-MDRemoteIP: 45.6.251.164
X-Return-Path: prvs=14370a98a6=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.26.0.170902
Date: Thu, 21 Sep 2017 11:04:10 -0300
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <AFA0A44E-E631-43CD-800B-8F1ACA5EB421@consulintel.es>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
References: <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <CAKD1Yr1V5BsrrEO68ASS1hF-Qj3Q_SsyquXeRx0gNRdNURcKsw@mail.gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <alpine.DEB.2.20.1709211030060.29378@uplift.swm.pp.se> <bd4c7462-2483-b617-e64c-b5dcfc768e17@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> <dbac4f8a-55e0-345b-667c-937b75869890@gmail.com> <F8A62D88-6FAE-48A1-A28F-F84451F781BA@consulintel.es> <f26447b3-8d9b-2216-495e-59413e3a8913@gmail.com> <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> <20170921135235.GF45648@Space.Net>
In-Reply-To: <20170921135235.GF45648@Space.Net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3e7IKrdGihXls3bhf-tfDo6dtdk>
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 14:04:20 -0000

You’re right, that’s why I said quick thought because I’ve seen operators doing that actually (two APNs one for broadband LTE, one for smartphones) ;-)

So, a single APN, provides by default a /64. Then if it is a broadband router starts DHCPv6-PD (not sure then if NO need to use RFC6603 for excluding the WAN link if the initial “default” /64 was already used as well for the WAN link).

Regards,
Jordi
 

-----Mensaje original-----
De: Gert Doering <gert@space.net>
Responder a: <gert@space.net>
Fecha: jueves, 21 de septiembre de 2017, 10:52
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: <v6ops@ietf.org>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    Hi,
    
    On Thu, Sep 21, 2017 at 10:40:17AM -0300, JORDI PALET MARTINEZ wrote:
    > I also see a valid case for having 2 APNs. 1) for LTE broadband routers that require more than a /64 (and thus DHCPv6-PD), and 2) for the rest that are regular UEs and only require a /64 (64share for the tethering)
    
    The claim that you need multiple APNs for that is not logical.
    
    The basic function "assign a /64 for each PDP" is 3GPP standard, any APN
    needs to do that (and that's the /64 you use for 64share).
    
    The extra function "DHCPv6-PD" is conceptually totally independent - you
    need an IPv6 capable link, nothing else, and whether or not a /64 has been
    assigned is not relevant for PD.  
    
    Now, if a given *vendor* can only turn on one or the other on their gear 
    is an implementation choice, and that REALLY doesn't belong here - if at
    all, it's a 3GPP standardization topic ("if you add DHCPv6PD, you MUST
    continue to provide a /64 for each subscriber").
    
    Gert Doering
            -- NetMaster
    -- 
    have you enabled IPv6 on something today...?
    
    SpaceNet AG                        Vorstand: Sebastian v. Bomhard
    Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
    



**********************************************
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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.