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

Lorenzo Colitti <> Fri, 13 January 2017 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42AB312986E for <>; Thu, 12 Jan 2017 18:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.199
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JnWyY4f9qo_s for <>; Thu, 12 Jan 2017 18:38:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45A5F12986F for <>; Thu, 12 Jan 2017 18:31:32 -0800 (PST)
Received: by with SMTP id 35so28081444uak.1 for <>; Thu, 12 Jan 2017 18:31:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=owc5EPumvsxWVzZqLZxnduMSLF2it5tkp7GnWNQme4kuRBfpwndvOzFP08oCqGZQSf t+1y/UvviOX3W2VpnpyebFzS0egaYTTWsbnZnOIVB29F7xxjWzKu37BgUSPrTTdlrVFI rswBPHxs14Rr8jEtCKswZk/0gYQL2IjU87seuc/hzj5y+3XjhWEdLH8i66FH++rMXA1K 0gYheXrvnB3V22boEi5gvkTmWpk+dbwZfgkjBgx2fysyZM5l1ZBWhAbxDNIJvtyMukEf WXScWAIfwcdTPefBHOluCCtiAr9bDedji7A1kV1M9I0zeRyoRz/ZQAFL6qSv/T7JHqRj syfw==
X-Gm-Message-State: AIkVDXL81tHT0iUE8EuSPx3xHmzdcW3wREHGHqCap8N7tRwndcA0iRU42ibzRJvLP5+y8VX4x4jTaAvrG+yC3bIJ
X-Received: by with SMTP id k11mr9273853uab.42.1484274691203; Thu, 12 Jan 2017 18:31:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 12 Jan 2017 18:31:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Fri, 13 Jan 2017 11:31:10 +0900
Message-ID: <>
Subject: Re: Review of draft-ietf-6man-rfc4291bis-06
To: Brian E Carpenter <>
Content-Type: multipart/alternative; boundary="f403045e34f4b8273e0545f0a1f6"
Archived-At: <>
Cc: IPv6 List <>, IETF <>,, Bob Hinden <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jan 2017 02:38:35 -0000

On Fri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter <> 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.