IETF Logo Mail Archive

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

David Schinazi <dschinazi@apple.com> Wed, 20 September 2017 01:10 UTC

Return-Path: <dschinazi@apple.com>
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 E4D0D1326ED for <v6ops@ietfa.amsl.com>; Tue, 19 Sep 2017 18:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 36XlD6VvGzxh for <v6ops@ietfa.amsl.com>; Tue, 19 Sep 2017 18:10:32 -0700 (PDT)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8F5124B18 for <v6ops@ietf.org>; Tue, 19 Sep 2017 18:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505869832; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ScGrXKUEYV0lt9NNC0kSHnFCRsfyMZGBxHTWS4pwkeE=; b=ZKdTht2gBBN62BUCyBNn8NHy5Cj0a4whDIUDm0bnq+SV873ojajB9kLpe0HTmSpM DOPfIT3hkU7jehg3Pn+nwvObrdCEDxdAJqHesG3Ua2ChOdRCjlT4USKs2IGwN+ZP 4H8qF4wNqkl8CwghpqxLwsW3SrdZXiLGmx5EtoVBmGfsh4doBuJJBfzYhTSyY6om InVNPz0vnpLoQJB4BDA0/blnzwel1hYx6Wz8t9jV2kvYmsOw5ouYhurCUkUXzSph W57Xs+EVu5/ZPFYe8MhhsgP4IVMPXgqDXkW/1NbHJQ9E2glaUM/tqwfiEaYc+AP+ WWpQVaIfRP3T0A736G0dvg==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 42.44.11091.800C1C95; Tue, 19 Sep 2017 18:10:32 -0700 (PDT)
X-AuditID: 11973e15-061ff70000002b53-3f-59c1c0082cec
Received: from koseret.apple.com (koseret.apple.com [17.151.62.39]) by relay6.apple.com (Apple SCV relay) with SMTP id F9.CE.03275.800C1C95; Tue, 19 Sep 2017 18:10:32 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from da0602a-dhcp112.apple.com (da0602a-dhcp112.apple.com [17.226.23.112]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OWK00L3F0LKK510@koseret.apple.com>; Tue, 19 Sep 2017 18:10:32 -0700 (PDT)
Sender: dschinazi@apple.com
From: David Schinazi <dschinazi@apple.com>
In-reply-to: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es>
Date: Tue, 19 Sep 2017 18:10:31 -0700
Cc: v6ops@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com>
References: <C1017FAF-91C3-4CA3-89C2-B64FF5100E41@consulintel.es> <a4385de4-ba3e-0b36-1bfd-ef3210fba08c@gmail.com> <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es>
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FAYpctx4GCkwYYVGhZ/j39mtjh9bC+z A5PHuv0BHkuW/GQKYIrisklJzcksSy3St0vgyvix7Th7wQzWivtth9gbGCewdDFycEgImEic 3h/fxcjFISSwmkni3oJmti5GTrD4/AXNzCC2kMAWRomXa3RAbF4BQYkfk++B9TILqEtMmZIL 0buYSeLy77ksIDXCAtISXRfuskLYzhKrH7xkB6lnE9CSOLDGCCTMKeAkcfjYYbDxLAKqEq// LAGzmQWEJBZf+84IYWtLPHl3gRVirY3E5H+9LBC71jBKLOxoYwdJiAjISdxd0coIcbOsxK3Z l5hBiiQEfrJKnJ11hnUCo/AsJHfPQrh7FpIdCxiZVzEK5SZm5uhm5pnpJRYU5KTqJefnbmIE BfV0O9EdjGdWWR1iFOBgVOLhDbA6GCnEmlhWXJl7iFGag0VJnFd+OlBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QD49QOHuvvTb2lCUUCGk3BCSdm7ODWfrkkOvQNy7Ev7JlnX6xa/CfB9MHB lQzfz6vNWbG5b9p8rlNGzZO6fIMXn/I23//jyV0VBZ/nga8jZjNx3ftjf5Ot3eNkqWrRhEue ui9vRZpGlG4/fefhFf3Jpw8vfHa9+Y7scksNB4Pgc3LT64+q9ue8T1diKc5INNRiLipOBAB+ TWlpSwIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiON1OXZfjwMFIg9WHVC3+Hv/MbHH62F5m ByaPdfsDPJYs+ckUwBTFZZOSmpNZllqkb5fAlfFj23H2ghmsFffbDrE3ME5g6WLk5JAQMJGY v6CZGcQWEtjCKPFyjQ6IzSsgKPFj8j2gGg4OZgF1iSlTcrsYuYBKFjNJXP49F6xXWEBaouvC XVYI21li9YOX7CD1bAJaEgfWGIGEOQWcJA4fOww2nkVAVeL1nyVgNrOAkMTia98ZIWxtiSfv LrBCrLWRmPyvlwVi1xpGiYUdbewgCREBOYm7K1oZIW6Wlbg1+xLzBEaBWUhOnYVw6iwkYxcw Mq9iFChKzUmsNNNLLCjISdVLzs/dxAgKw4bCqB2MDcutDjEKcDAq8fD+MD8YKcSaWFZcmXuI UYKDWUmEt3QvUIg3JbGyKrUoP76oNCe1+BCjNAeLkjhv7gyglEB6YklqdmpqQWoRTJaJg1Oq gdHbp7At79Gm84kTVj+XebrqwLMWlzp2I3u+fRpSK9WcrbfskJz2f7bHg8e/zl504r1axJTt sNRfKtCWbemiCsdD20VFlnOE8TvpfXKYWcm98ZLDkoMzLaZaRNnNU7hnMpdHz3cx2zLnOJnP RT+u11Q7H5uqxFHtpZRVs8pvqd9xVjPnOCshMSWW4oxEQy3mouJEAH8FSD4/AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KbfMs8MxNJkyTor0LG2l2bHXFVA>
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:10:34 -0000

> 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

v2.23.0 | Report a Bug | By Email