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

Tore Anderson <tore@fud.no> Thu, 02 March 2017 09:52 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 DA7DF1296A2 for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 01:52:13 -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 M6HLklOovmcP for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 01:52:12 -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 8CFB71296B1 for <ipv6@ietf.org>; Thu, 2 Mar 2017 01:52:12 -0800 (PST)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=49604 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 1cjNP4-0005lW-Op; Thu, 02 Mar 2017 10:52:06 +0100
Date: Thu, 02 Mar 2017 10:52:06 +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: <20170302105206.15fc3886@echo.ms.redpill-linpro.com>
In-Reply-To: <CAKD1Yr3tHm5x29w4L5KtKi7PqDHRxkPr6i9mJMtHLaPc2eM2GQ@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>
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="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/v0XvA5IYPLXuV8zlfwRhHLe_97s>
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 09:52:14 -0000

* Lorenzo Colitti <lorenzo@google.com>

> Let's see if there is common ground here. I agree that routers should
> forward on arbitrary prefix lengths. It's probably reasonable that
> hosts should not make assumptions about other host's IP addresses
> (except if they are on the same subnet). But I think a host should be
> allowed to assume that its own subnet and its own IID are 64 bits
> long.

Such an assumption would fundamentally break SIIT [RFC7915]. Consider
the following examples of IPv4-translatable IPv6 addresses [RFC6052]
that might be assigned to hosts on different links in a vanilla SIIT
(a.k.a. IVI) deployment:

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.

Thus, if you want to give the host permission to make such an assumption
of /64, you'd need to make exceptions for IPv4-translatable IPv6
addresses (or deprecate RFC7915 and possibly RFC6052).

However, creating such an exception probably means in practise that
implementations much apply it to the entire IPv6 address space, because
there is no way for a host to determine whether or not, e.g.,
2001:db8::c000:201 (host #1 above) is an IPv4-translatable IPv6 address
or not (that I'm aware of, anyway).

Tore