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

Tore Anderson <tore@fud.no> Thu, 02 March 2017 14:36 UTC

Return-Path: <tore@fud.no>
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 2F38C129493 for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 06:36:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 kUkAZytwSOPX for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 06:36:15 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5901294E8 for <ipv6@ietf.org>; Thu, 2 Mar 2017 06:36:14 -0800 (PST)
Received: from [2a02:fe0:c420:6ae::c68] (port=42034 helo=envy) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <tore@fud.no>) id 1cjRpz-00015s-QR; Thu, 02 Mar 2017 15:36:11 +0100
Date: Thu, 02 Mar 2017 15:36:11 +0100
From: Tore Anderson <tore@fud.no>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Message-ID: <20170302153611.36506f85@envy>
In-Reply-To: <CAKD1Yr1cNihxMVHjY2j7mcCNU2TE0X6-0p2mDNCBVVUcUbU20Q@mail.gmail.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> <CAKD1Yr1cNihxMVHjY2j7mcCNU2TE0X6-0p2mDNCBVVUcUbU20Q@mail.gmail.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SwwTTEspogyTjRilzkEoZ1zBZz0>
Cc: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>
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:36:17 -0000

* Lorenzo Colitti

> 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,

Yes, apart from the fact that the hosts usually don't need to
«calculate» anything or even have any awareness of the translation
taking place:

For outbound flows from a host with an IPv4-translatable IPv6 address
to the IPv4 internet, a DNS64 recursor would typically take care of
that calcuation. This works exactly the same as if you're using
Stateful NAT64 instead.

For inbound flows to such a host it only has to respond normally to the
source address in the incoming IPv6 request packet - which may or may
not be an IPv4-embedded IPv6 address. Again, this works same as with
Stateful NAT64 (assuming the NAT64 device allows inbound flows from the
IPv4 network in the first place, e.g., using static BIB entries).

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

Indeed, if you arbitrarily start setting the bits RFC6052 says should be
all 0 you will have successfully shot yourself in the foot. (Not that I
believe this is relevant to the discussion at hand.)

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

Exactly, you'd need an exception for IPv4-translatable IPv6 addresses.

But if you're coding up an host OS IPv6 stack you can't differentiate
between IPv4-translatable IPv6 addresses and «normal» IPv6 addresses.
After all there's no flag or property that tells the host stack that a
given IPv6 address is IPv4-translatable or not.

An OS/IPv6 stack implementer therefore has no choice but to make this
«exception» apply to *all* IPv6 addresses, allowing addresses to be
configured with arbitrary-length IIDs, thus making the exception the
rule.

Tore