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

Lorenzo Colitti <lorenzo@google.com> Thu, 02 March 2017 14:03 UTC

Return-Path: <lorenzo@google.com>
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 34A1F1295B4 for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 06:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wxo9Dvq5od2z for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 06:02:59 -0800 (PST)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1E512958D for <ipv6@ietf.org>; Thu, 2 Mar 2017 06:02:58 -0800 (PST)
Received: by mail-ua0-x235.google.com with SMTP id c11so27917438uaa.0 for <ipv6@ietf.org>; Thu, 02 Mar 2017 06:02:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UMS4YnQ+0uvs+gddXgFg9R4DkeGdcaOv5jpXm4Sp2f0=; b=ODWN6+Vk5Ktg0Sg+CCt/YBkRkV5nAiXv8V/htDH0+6aMH9dVqBJmNa2IPVPzkjxNLm tGG6DkSYJJqIgiRSwbyX7THZSmSYtHrF8xjBU3cePnQXeC1gbSIqKsWL/JgWBEVLf90t Zf43SrwDSCc6log8GKcEYXxqmJZ1dcFdjqZhsojet3upW/ixKmojp2mELaTsYF2MXNAS UKu+BpTXCQMXvkh5N3GGQyUu5yXPZtshrHrSOg33ejqacXdW7HtV3Tnezw1MRuCKcI51 leahQzZVj029U6SphiJ9aKl0uVg2ubN8QRwZTivtuPkolDoeHnHO6Y3+UaGQtlU/1uLW 0odA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UMS4YnQ+0uvs+gddXgFg9R4DkeGdcaOv5jpXm4Sp2f0=; b=PFciK9ofDMe9OrzBMcWIvKeCI8cEw+xtk37O47J80vEdgvtSb5ck0ldXsCYjSWhFiR tUkCJymDHYRrb1dYz4CPn1f4I58Q4UsirTOxjT7/X1vDqHEc8+A85fYeWDU31juSfVmE iqtrIRVzID3RM9L1AC5yEq7eiD+x8qC2lo1saWWKoszt8FiPuVv7Odn0tvWIDE8RACTH 3YfSJ6NtA6YFWL1bSoF5GFveHSEGvIDzrF6jvszj/cbWVIj/VBjcbVb3TKaKkVtLhF75 6VIJh4Rtg5+SEO8FQX8vZZFX9lmfi5JJwpIwCxtLesdK0XnI7TbWOtkpttYCCZJ4GFic oduA==
X-Gm-Message-State: AMke39mrcWbftq8ezFCNTVewJQ5SbOHDaovpoltYSESSgZTPPAEjuzuvaUdGYkY7ttMVBZtCjxpprIgjESs08Ysi
X-Received: by 10.176.1.5 with SMTP id 5mr5895332uak.30.1488463374858; Thu, 02 Mar 2017 06:02:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 06:02:34 -0800 (PST)
In-Reply-To: <20170302121104.36ddda4e@echo.ms.redpill-linpro.com>
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAKD1Yr0qk_njAGnex_FZsYisCVw=eM8hXTr1v+wqvcfX_09wiQ@mail.gmail.com> <CAN-Dau0ohz3Wp55bs+eoFvSyoUjuKfjzKGSAsJS3wUt3z7TGtA@mail.gmail.com> <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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 02 Mar 2017 23:02:34 +0900
Message-ID: <CAKD1Yr1cNihxMVHjY2j7mcCNU2TE0X6-0p2mDNCBVVUcUbU20Q@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Tore Anderson <tore@fud.no>
Content-Type: multipart/alternative; boundary="001a113d058cb88a680549bfe2da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2BEBgMIFJBQkhMihukrOjKLvoBY>
Cc: 6man WG <ipv6@ietf.org>, james woodyatt <jhw@google.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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 14:03:05 -0000

On Thu, Mar 2, 2017 at 8:11 PM, Tore Anderson <tore@fud.no> wrote:

> > So really, you can't express this type of configuration using only an
> > IPv6 address and a prefix length, because they don't provide enough
> > information to do that. "2001:db8:0:c0:2:100::/80" by itself is not
> > enough: you need one more piece of information, which is the length
> > of the NAT64 prefix.
>
> I'm not exactly sure what you're saying here? RFC7915 does currently
> work, and hosts participating in a network using RFC7915 do not need to
> know the length of the translation prefix.
>

Oh, I see. It works if you ensure that all the hosts and translators agree
on how to calculate the suffix, and no two hosts have IPv6 addresses that
differ only in the suffix. IPv6 addresses that don't have this property
experience unidirectional connectivity to IPv4, and can cause packets to be
sent by third parties to the host that has the correct suffix. Fair enough.


> > As I said before, I think we should have an exception for IPv6
> > addresses where the only non-zero bits in the IID are an IPv4
> > address. Those aren't really IPv6 addresses anyway, they're just
> > convenient representations for IPv4 addresses.
>
> Well, the point is that in order to ensure compatibility with SIIT such
> an «exception» would need to _always_ apply, and then it's not really
> much of an exception anymore.
>

How about an exception for IPv6-translatable addresses, then? I don't think
it's essential that the host know that the addresses are IPv6-translatable.