Re: Review of draft-ietf-6man-rfc4291bis-06

Lorenzo Colitti <lorenzo@google.com> Fri, 13 January 2017 02:31 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 C4C3A12986E for <ipv6@ietfa.amsl.com>; Thu, 12 Jan 2017 18:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level:
X-Spam-Status: No, score=-5.199 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=-3.199, SPF_PASS=-0.001] autolearn=unavailable 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 7PoBz2mTawpT for <ipv6@ietfa.amsl.com>; Thu, 12 Jan 2017 18:31:32 -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 41CA012986B for <ipv6@ietf.org>; Thu, 12 Jan 2017 18:31:32 -0800 (PST)
Received: by mail-ua0-x235.google.com with SMTP id y9so28167562uae.2 for <ipv6@ietf.org>; Thu, 12 Jan 2017 18:31:32 -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=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=klU95R2LEDpWw/f3XnlXtr5gYmdS53CS8bzm2NjXi36qU+1yAr7oIusV5MqCu3knV2 QNNxQNeU/1mQO4zt/pOfJx1hj3WJrNs6cAkv/f4IT4iQhG9utDR6VpcN2xpo5jgKNV+f LNTfvRr9bFoSehBgCqzHPqydVpPAzb6AUFvReZVkzRd4rKo15y6xwlDPNzpKR7vt4tiC 5Ux4mm+lNn/QrK0+19qHoIAMPYWdLmVBpCTelnsUnT5+/HrtLPVbxKSOxI4BjRkO/ER7 nbb/Nty1OMUqICmP4EZQaE04/UmdvhSAyyDKu3NnPfRdcz9r1iPciVH+KJ5Zf4uGSmgq ID2A==
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=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=GTaS4xD9+Dvei98E3gByXa2I1quQ05OuUkVx5aFQIcy3NDaa5udevox+J0DW1nN8rj Muqzu6Y65DOLGQ+1cYDCj84MW5XCJXWk19cMkemTOMASaYJ6jBGnUWzUfxQ8qwkhEOZy niQfMSBdZRrBOXeli7MxiKPogrWL2s6uFf5DrOHskfg3L1gjaGLOTxT6Fg+6mJxMDVQa R3X6e+g+pg+CBa9GLLKD4KzGex4YolWQdtmDzq9QDrPLknTRnaPUwrqNSAseetJ8WKzw IlQ7eDlgGsraY2AiNkeSHRsF9R4r4y9s+h77JXzHF3XcmRyiFzfbX9DAE8/xMkIoS4fn pdOw==
X-Gm-Message-State: AIkVDXJINWAzHFlZTmXbgtttuVGMC4Vi9zO5NtNL/DLBMoJUclHBIvUCzgnP+qfwE+l5llwd31DoAO7ioJv5xWGB
X-Received: by 10.159.48.203 with SMTP id k11mr9273853uab.42.1484274691203; Thu, 12 Jan 2017 18:31:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 18:31:10 -0800 (PST)
In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <m2fukqbbwv.wl-randy@psg.com> <F6953234-3F85-4E28-9861-433ADD01A490@gmail.com> <m2wpdzhncn.wl-randy@psg.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <m2d1frhjfn.wl-randy@psg.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 13 Jan 2017 11:31:10 +0900
Message-ID: <CAKD1Yr1cvZ8Y3+bHeML=Xwqr+YgDspZGnZi=jqQj4qe2kMc4zw@mail.gmail.com>
Subject: Re: Review of draft-ietf-6man-rfc4291bis-06
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="f403045e34f4b8273e0545f0a1f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Yw6Zb-UPo_F4Ee4LSNaUJoqOAF0>
Cc: IPv6 List <ipv6@ietf.org>, IETF <ietf@ietf.org>, int-dir@ietf.org, Bob Hinden <bob.hinden@gmail.com>, Randy Bush <randy@psg.com>, draft-ietf-6man-rfc4291bis.all@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: Fri, 13 Jan 2017 02:31:35 -0000

On Fri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> The problem is (and why we wrote 7421) is that stuff breaks with subnet
> prefixes longer than 64, *except* for the point-to-point case covered
> by 6164. Yes, I see the problem in enshrining this but I think we face
> signifcant issues if we do otherwise.
>

Also, RFC7934 says that networks that provide service to general-purpose
hosts should be assigned /64 prefixes to avoid address scarcity. Networks
that provide service to general purpose hosts make up a lot of the Internet.

What we could conceivably say is that /64 is mandatory except for
> links where SLAAC will never be used. (SLAAC itself is designed
> to work with any reasonable length of IID, but again in practice it
> only works with /64, because we need mix-and-match capability. So
> although IID length is a parameter in the SLAAC design, it's a
> parameter whose value needs to be fixed globally.)
>

I don't think that's a good idea.

I strongly believe that unlike most areas of the IPv6 protocol where it is
a good idea to automatically apply the lessons we learned in IPv4, in the
specific field of IP subnet sizing, we should *not* automatically translate
IPv4 practices to IPv6. This is because the difference between 32 bits and
128 bits is large enough that the semantics are fundamentally different. We
may be lured by the fact that 128 is just 4 times larger than 32, but the
difference is huge - remember that even just the first 64 bits are 4
billion times larger than the whole of the current Internet.

So while Randy may well be right that we will move away from classful
eventually (we certainly never had it in the top 64 bite of the address), I
don't think it's necessarily a good idea to do that now. Let's have that
conversation when IPv6 deployment has reached 90% and we have experience
running the whole Internet with IPv6.

For now, I'd much prefer to just add a similar exception to the one we have
in 7421.