IETF Logo Mail Archive

Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

Owen DeLong <owen@delong.com> Wed, 20 September 2017 19:38 UTC

Return-Path: <owen@delong.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 7BB9E134319 for <v6ops@ietfa.amsl.com>; Wed, 20 Sep 2017 12:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.101
X-Spam-Level:
X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 GNOycfqfZ6yA for <v6ops@ietfa.amsl.com>; Wed, 20 Sep 2017 12:38:34 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1769913430E for <v6ops@ietf.org>; Wed, 20 Sep 2017 12:38:33 -0700 (PDT)
Received: from [45.6.255.5] ([45.6.255.5]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8KJbO28007531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Sep 2017 12:37:29 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAAedzxo=ACB-3aJ0_9gwEPav_O3GSPM1j5txZ_aSTphcz=384Q@mail.gmail.com>
Date: Wed, 20 Sep 2017 16:37:27 -0300
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8AEA75E-2383-450C-AF9C-CB35A686326E@delong.com>
References: <C1017FAF-91C3-4CA3-89C2-B64FF5100E41@consulintel.es> <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <C33DB89E-C005-4A32-9066-C8EE710F3255@consulintel.es> <b16c4ca2-da97-9a5a-0f88-6388ebbda80e@gmail.com> <B9C2822F-56EE-47D8-AAB5-C041A3D22F41@gmail.com> <f23854dd-0952-eedb-802b-8506dc111da7@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <CAAedzxrMk10P8g0p5=1m8rANFy6+GvkA7+SrnWLKp3Do7sY5aw@mail.gmail.com> <d441f1cd-7b22-f94f-1fe2-4b12ab47ae21@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <CAAedzxo=ACB-3aJ0_9gwEPav_O3GSPM1j5txZ_aSTphcz=384Q@mail.gmail.com>
To: Erik Kline <ek@google.com>
X-Mailer: Apple Mail (2.3124)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 20 Sep 2017 12:37:30 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/54rqn9saJxCMYQeHJES4wFz9F00>
Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: 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 19:38:35 -0000

> On Sep 20, 2017, at 12:21 PM, Erik Kline <ek@google.com> wrote:
> 
>> Ctrl-F also, and that page does not seem to display any correction that says
>> "DHCP" in the last 3 and a half years.
>> 
>> But I think CLAT should run DHCP somehow, otherwise it's a non standard way
>> to get Prefix Delegation.  Does it?  (I may download it later and look at
>> it).
> 
> There is no PD wrt 464xlat.  The /64 is implicitly delegated to the
> mobile per the 3GPP architecture, as I'm sure you well know.

Isn’t that an artifact of 3GPP and not 464XLAT?

My understanding is that 464XLAT CLAT can work with any interface that has
a /64 on the interface, regardless of how it was assigned to the interface.

> If you want to know how the device learns the DNS64/NAT64 prefix then
> see https://tools.ietf.org/html/rfc7050 .

If 3GPP is baked into 464XLAT, then I agree we still have work to generalize it
before making it STD.

Owen

v2.23.0 | Report a Bug | By Email