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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 20 September 2017 01:34 UTC

Return-Path: <prvs=143688d48d=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 ABF6C133070 for <v6ops@ietfa.amsl.com>; Tue, 19 Sep 2017 18:34:32 -0700 (PDT)
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 wy315XobfJnm for <v6ops@ietfa.amsl.com>; Tue, 19 Sep 2017 18:34:29 -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 72A641320DC for <v6ops@ietf.org>; Tue, 19 Sep 2017 18:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505871266; x=1506476066; 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=CLYEj8nlAevaESzYcACeakx9B ipDJJXt14kvrrctTpk=; b=lGZQx9uqkqwwwptVtFGbB071efZjDQ5yIg2xRWuhB Ujgj53WvGgbBpR3oDlXkQTGDZcK1e1IAd7aIl2ULgasMDLXRxYGSI+xbMTs7zzrN J3ReygXhzbfUt/Zwi4Si4I/QQI0N3J27aGhwDlJuJI9WT0gf9HqYQ8UmOJMpqfnQ /s=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=j5BedfTbahu38cB9/xyBCrhTnvxC8BY0aeezcz5p/DtSWEODribu3SgQJucY A4bakvv9x7rDRz6PL3hJ2RRJIAZpldlp7OrUksBdmTmMSFvw4HtYVXKIC UGaGSU1a5R6glNc40/CxFuJeMmW/x+1YaqnCmnd3XDXcFmxGMB+XzE=;
X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 03:34:24 +0200
X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 03:34:23 +0200
Received: from [10.0.5.203] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005560702.msg for <v6ops@ietf.org>; Wed, 20 Sep 2017 03:34:22 +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:170920:md50005560702::pK/+287FMMPUo115:00004x+O
X-Return-Path: prvs=143688d48d=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: Tue, 19 Sep 2017 22:34:11 -0300
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <1B4AAE0F-0F5E-49F5-A35B-57F3372A11EB@consulintel.es>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
References: <C1017FAF-91C3-4CA3-89C2-B64FF5100E41@consulintel.es> <a4385de4-ba3e-0b36-1bfd-ef3210fba08c@gmail.com> <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com>
In-Reply-To: <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com>
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/3JDrQmAmR_PUg2bFY5Y2rc8ZtBY>
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: Wed, 20 Sep 2017 01:34:33 -0000

I think you may be right, it makes sense that a single /128 will be able to allow that, but I think it is clear that needs to be a different one that the CLAT WAN interface. I guess the authors indicated a separated /64 as it seems easier to allocate it than a single address if you’re using DHCPv6-PD. I was just recalling what is in the actual RFC:

6.3.  IPv6 Prefix Handling

   There are two relevant IPv6 prefixes that the CLAT must be aware of.

   First, CLAT must know its own IPv6 prefixes.  The CLAT should acquire
   a /64 for the uplink interface, a /64 for all downlink interfaces,
   and a dedicated /64 prefix for the purpose of sending and receiving
   statelessly translated packets.  When a dedicated /64 prefix is not
   available for translation from DHCPv6-PD [RFC3633], the CLAT may
   perform NAT44 for all IPv4 LAN packets so that all the LAN-originated
   IPv4 packets appear from a single IPv4 address and are then
   statelessly translated to one interface IPv6 address that is claimed
   by the CLAT via the Neighbor Discovery Protocol (NDP) and defended
   with Duplicate Address Detection (DAD).

Regards,
Jordi
 

-----Mensaje original-----
De: <dschinazi@apple.com> en nombre de David Schinazi <dschinazi@apple.com>
Responder a: <dschinazi@apple.com>
Fecha: martes, 19 de septiembre de 2017, 22:21
Para: <jordi.palet@consulintel.es>
CC: <v6ops@ietf.org>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    > On Sep 19, 2017, at 17:51, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
    > 
    > If you do it with SLAAC, as described in the RFC, the NAT46 will be stateful (by means of a previous NAT44) because you don’t have a specific /64 for the translation. Otherwise will be stateless.
    
    I don't think that's correct. In order to make 464XLAT stateless you need a separate /128, not /64. And SLAAC allows you to generate that extra /128. As far as I know, this is how Android works.
    
    As far the discussion of changing the Category of the RFC, I'm not sure what it accomplishes, and whether it's worth spending time on.
    
    David
    



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