Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

David Farmer <> Thu, 16 February 2017 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15D72129A3A for <>; Thu, 16 Feb 2017 06:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 4406TDwxCzZ4 for <>; Thu, 16 Feb 2017 06:38:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1912812961A for <>; Thu, 16 Feb 2017 06:38:59 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 97139720 for <>; Thu, 16 Feb 2017 14:38:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fhjFODDCdxRe for <>; Thu, 16 Feb 2017 08:38:58 -0600 (CST)
Received: from ( []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5563C82C for <>; Thu, 16 Feb 2017 08:38:58 -0600 (CST)
Received: by with SMTP id r136so9334590vke.6 for <>; Thu, 16 Feb 2017 06:38:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lBE5T7g+T8VK+HvU1gv3XaXRoy3afvHHUqf2WzIOThQ=; b=j4D4j2lncNZybdSy2tH2T/PtBuq6ZMX2kpf6ygIK9IvEWPfC/P4sqOymLKHthwMck/ PxLgNq5Q17TdXBaivaHPbFn+0vOaLGSFmLh4wyBx8fZhJsNilenxne6fONIZVOMK277Z JEikYDn4GnFoVy6kujrODvzTWnugxfRlcfcxmdRAo31iqvKK+HIzvq5kWE3akQ87rhlg 5YQgG8cSeXVtuwFmGtf3MrHoxXLWu28KNUm8HwHXVNgi8tV2iItmwF5igcCpWV3Y8fuM r2+Q4ERLZT5O0qgldRLP4SwMbH3He6LeB7qCngeIRSO9vui6WQQwoF5Z1FzyVrE04yOR Ajdg==
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=lBE5T7g+T8VK+HvU1gv3XaXRoy3afvHHUqf2WzIOThQ=; b=Zp2YHd+gWScbON4C8LQjvf/DZmENwfThwZaC8XTGb7tr5vynrTHoCg6s5hxXU31piD kJolt9/Om+nTpxC2oxTCRqPbv7LDcmt7NkwbYynsnQst+vFwXq/zaMwMs/FCCJBcXTKv VuMCLjdSHfcr8PDW4a1F12SNgi8x2taMTWL+86pZE7jw+lTzxzYHAap0N3gkMhOurHBg qrpERRPFvlhqVm00I+Ul5keRHBPw8S5yvU1P6M981KQ/UMvOevmNxPKcL7nUtiiRFlJ8 5MfjdXZBmo8gvD559CItBMMitxx1i8t2rj0hqgKtZNB3VgWy6W/DrIljzeWZzD6CiRo1 l+mg==
X-Gm-Message-State: AMke39l9ZRP3cbLSh6PXUSnN2Ilj++u3o6Iy0kKXlsCB/qr0sIMHo2owAh8rFqhFfHTc9s8Ux+Y7XH0sW2tomkRRArtRGXybvv11ufOe23TSU/burhEntNzH74pJcBpN45HVGN5urNRuFZ87hgY=
X-Received: by with SMTP id c63mr1309802vkb.117.1487255937685; Thu, 16 Feb 2017 06:38:57 -0800 (PST)
X-Received: by with SMTP id c63mr1309786vkb.117.1487255937438; Thu, 16 Feb 2017 06:38:57 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Feb 2017 06:38:56 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: David Farmer <>
Date: Thu, 16 Feb 2017 08:38:56 -0600
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Ole Troan <>
Content-Type: multipart/alternative; boundary="001a1148481ed76d090548a6c123"
Archived-At: <>
Cc: Randy Bush <>,, 6man WG <>, IETF-Discussion Discussion <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 14:39:01 -0000

On Thu, Feb 16, 2017 at 3:09 AM, <> wrote:

> Dear Randy,
> >>>> If your statement is that we only have the 64 bit boundary because of
> >>>> SLAAC I believe you are wrong.
> >>>
> >>> cite, please.  what else actually needs it?
> >>
> >>
> >
> > that excuses it.  cite where it is actually needed to do something
> > useful other than slaac.
> "something useful" makes it subjective.
> If you only care about technical issues, then:
> SLAAC, NPT66, ILNP are the biggest one that I can think of.
> Trivial to make SLAAC work with variable length prefixes of course.
> As well as we don't know the consequences for implementations.
> 7421 seems to indicate it mostly works.
> But then you have people who write code like this:
> Where it clearly will not work with a longer prefix than 64.
> Feel free to contribute a patch, but make sure to count the cycles spent
> through that code.

So, is that code right or wrong?  To be honest, I feel the current text
says its correct to embed 64 in your code.  If you truly think current text
is correct, then have the courage of your convictions and embed 64 in your
code too.

However, I take your example as evidence that the current text doesn't have
the balance right.  Is the proposed text too far the other way?  Maybe.
Well... actually probably it is too far the other way, but I don't see you
even acknowledging there is an issue with the current text.

As far as I'm concerned, this is a policy statement masquerading as a
technical requirement.  Policy is all about nuance and shades of gray, and
technical requirements are about clarity and making things ether black or
white.  The problem as I see it is, we are trying to use technical
requirements language too describe something that is truly a policy issue.
So we are probably doomed to fail!

How do we move forward? What I think we need is to make it clear that there
are real exceptions to 64, and it is therefore not acceptable to embed 64
in code.  The historic exception of addresses that start with 000 has been
too amorphous, no one thinks it real. I've provided two exception that are
clearly based on current standards track work, but I fear that still isn't
enough.  I fear some will still embed 64 and just add code for the
exceptions, if it's even really needed.

Can you help me find something a little more?

What about an additional exception for manual configuration?

David Farmer     
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952