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

Tore Anderson <tore@fud.no> Thu, 02 March 2017 11:11 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 3872A1297BE for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 03:11:12 -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 Ss1yOTfeq6fG for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 03:11:10 -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 0DDBF128824 for <ipv6@ietf.org>; Thu, 2 Mar 2017 03:11:10 -0800 (PST)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=51172 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <tore@fud.no>) id 1cjOdV-0000f2-Bk; Thu, 02 Mar 2017 12:11:05 +0100
Date: Thu, 2 Mar 2017 12:11:04 +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: <20170302121104.36ddda4e@echo.ms.redpill-linpro.com>
In-Reply-To: <CAKD1Yr2AYaAQMuGZiKXYwKdgz1dzKs5fc5bm7hQjpuq3O_V8gQ@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>
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/3TkcC6dwlc6eCt5YG7L7ebhZIpI>
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 11:11:12 -0000

* Lorenzo Colitti <lorenzo@google.com>;

> On Thu, Mar 2, 2017 at 6:52 PM, Tore Anderson <tore@fud.no>; wrote:
> 
> > 1) 2001:db8::192.0.2.1/120
> > 2) 2001:db8::198.51.100.1/120
> > 3) 2001:db8::203.0.113.0/120
> >
> > These are all in the same /64 but if these tree hosts assume the /120
> > prefix length is incorrect and "helpfully correct" it to /64, then they
> > can no longer communicate with each other.
> >  
> 
> I think you and I have already covered this case. I don't see how we can
> define the IID in any meaningful way for RFC 6052 addresses.

Precisely. So if you build an host implementation that, quote,
«assume[s] that its own subnet and its own IID are 64 bits long», as
you suggested in your previous message, that would as I understand it
break RFC7915/RFC6052 (the «vanilla SIIT» use case).

> In the limited case of /96 it might work, but in the general case it
> won't.
> 
> Consider a translation prefix of 2001:db8::/56. In this case
> 192.0.2.1/24 becomes (I think) 2001:db8:0:c0:2:100::/80. But if you
> configure 2001:db8:0:c0:2:100::/80 on an interface, that really won't
> work the way you'd like it to. For example, suppose the node gets a
> packet whose destination address is 2001:db8:0:c0:2:100::1. It won't
> match any of the IP addresses configured it on the system. So it will
> either drop it, forward it on-link (if L=1) or forward it back to the
> router it came from, potentially causing a routing loop.

This is somewhat besides my original point. However, it is no
different from a non-SIIT situation you'd get with a subnet prefix of
2001:db8::/64, a host configured with 2001:db8::1, and a packet
destined for 2001:db8::2.

I'd imagine that in most deployments the packet destined for
2001:db8::2 / 2001:db8:0:c0:2:100::1 will never reach the node at
2001:db8::1 / 2001:db8:0:c0:2:100:: becuase the router or node
attempting to deliver a packet to the latter address will first need to
resolve it, but there's nobody on the link to answer the transmitting
router/node's neighbour solicitations for those addresses and thus it
will just be dropped (and possibly cause some ICMPv6 unreachables to be
generated).

Or if it is a ND-less PtP interface and the host is also behaving as a
router you'd indeed get a loop. But again, that's no different than
what would happen with any regular non-RFC6052 /64, as documented in
RFC6164 section 5.1.

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

Side note: NAT64 [RFC6146] does not have this issue because it does not
use IPv4-translatable IPv6 addresses (the same goes for SIIT-DC). That
is, saying that all IPv6 prefixes must be /64 and enforcing that in the
host stacks would not prevent use of NAT64 (or SIIT-DC). The issue only
arises for networks/technologies that are using IPv4-translatable IPv6
addresses such as (traditional) SIIT.

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

At least I don't see how an IPv6 implementation could possibly
distinguish between any arbitrary (non-IPv4-translatable) IPv6 address
and IPv4-translatable IPv6 address?

As an example, take "2001:db8:1:2:3:4:c000:201".

This could be an IPv4-embedded IPv6 address where "c000:201" represents
the IPv4 address 192.0.2.1, but it could also just be an arbitrary
regular IPv6 address that someone configured. You can't know which it
is just by looking at the address, right?

And even if you did know, it wouldn't really match the «only non-zero
bits in the IID are an IPv4 address», because if you either:

1) consider the IID to always be 64 bits, then there's some nonzero
bits in there ("3:4") that are not part of the embedded IPv4 address, or

2) if you consider the IID to be the bits remaining after the subnet
prefix has been stripped off, e.g., 2001:db8:1:2:3:4:c000:200/120
(representing 192.0.2.0/24), then the IID simply does not contain a
complete IPv4 address as it's just 8 bits long.

Tore