Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07

Fred Baker <> Tue, 07 March 2017 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C36A12956B for <>; Mon, 6 Mar 2017 19:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3WLIZ4nf9Piv for <>; Mon, 6 Mar 2017 19:35:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CEB812706D for <>; Mon, 6 Mar 2017 19:35:41 -0800 (PST)
Received: by with SMTP id 77so29345063pgc.1 for <>; Mon, 06 Mar 2017 19:35:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j8oClpuzR31X/xomgAylVmoGLhSVAdQTGobIFlTqFYk=; b=eNxjILp7F4jkpPGfMwOTOhDnKSRJTzUzZphzzaP4Q6GkI3tNtdQ8xeFijeHQjntHpb B1r84jr2o3e+2kKm7uPMHrEqAtXE6s8q1vWSIpOBX2mo6y9kP7YYPZn3484LtpycE4YL WKHeIqleqJa37BOLCAVBBHMqofvchKP3jYkfoANxmsB/ciqrFCiETL/CeN41V3rIhkyl DgrPz6jVLEi4RLcw9Oa4j3i/rP/t+o5hk/e1LFEUN25wEOMimJqdt01cjdzi5AapWmuY h4RV6hxYOBKqBCce6h62YuggeSx48oFrpu0QL4Wes8m0vENnUnUv4hLdWgcKx/mZlxRb qjCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j8oClpuzR31X/xomgAylVmoGLhSVAdQTGobIFlTqFYk=; b=E7OmRh6nkBhOvP2czsLBIEOWncLr67YwfNmmzE8i2DTGcEjNqV4QK0ma5ZGlTjmfH7 BVBwGHreUUjbZYzjAo3CRyqrpl3GTJEL2+OZZD4IGbsnQi2MurlvcmhtQuh5YxA7pM0A qItH6Qt6vY2OLw92o6zJKqfIlFbbMsKMB094tHmHwMgtv1cb//ridQlwgpyhEyP9aocz QvQm0Kx8Aw48IiAioCRQPqBigusWnA4+EGergXs0ixsrbM4kidfbCQD2ZTI76jePWyzJ FzpsTFTvkwwVWIUsaeP0qa8X1mxQngdAtJkmqF0R8qA9uHAGJ97TLENuwTSqIJZdorV+ FW8w==
X-Gm-Message-State: AMke39lWuVbl1v4eXVSWiI/HU9EL0CNeCiVaxCSGPuqPSu4v4kquO0obbJBGv9MsVoJdPw==
X-Received: by with SMTP id t2mr24957633pgn.152.1488857740538; Mon, 06 Mar 2017 19:35:40 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c195sm42119971pfb.60.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 19:35:39 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07
From: Fred Baker <>
In-Reply-To: <>
Date: Mon, 6 Mar 2017 19:35:38 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Lorenzo Colitti <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>
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: Tue, 07 Mar 2017 03:35:42 -0000

On Mar 6, 2017, at 7:18 PM, Lorenzo Colitti <> wrote:
> I can't help fill in the [...] because I personally don't see what you can do with a /113 that you can't do with a /64 (other than conserve addresses, which has always been a non-goal), but there seem to be several participants who do see a problem. What I'm saying is that if we want to change the standard, the people who see a problem with it should articulate that problem in a way that it's possible to find a solution using informed and documented engineering trade-offs rather than opinions.


As you know, I'm not in favor of a standard IID or prefix length. If a given algorithm, SLAAC, requires it, so be it where it is in use (not that this this is a statement of probability, it's a statement of network addressing policy). Of a network chooses to do something different in the absence of that limitation, I understand the Internet Architecture to give it that latitude and the authority to impose an address allocation mechanism and policy.

That said, ...

The argument I have heard for serial lines is that, with high probability, if there are more than 2^1 addresses on a link, selecting a random address for one's peer has a high confidence of selecting an address the peer isn't using, resulting in an ICMP error instead of a response. That, assuming I understand it, is the fundamental argument behind /127. Reduced to simpler terms - if the environment makes assumptions, the addressing should make the same assumptions. 

RFCs in context:
3627 Use of /127 Prefix Length Between Routers Considered Harmful. P.
     Savola. September 2003. (Format: TXT=12436 bytes) (Obsoleted by
     RFC6547) (Status: HISTORIC) (DOI: 10.17487/RFC3627)
6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B.
     Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011.
     (Format: TXT=16057 bytes) (Updated by RFC6547) (Status: PROPOSED
     STANDARD) (DOI: 10.17487/RFC6164)
6547 RFC 3627 to Historic Status. W. George. February 2012. (Format:
     TXT=4917 bytes) (Obsoletes RFC3627) (Updates RFC6164) (Status:
     INFORMATIONAL) (DOI: 10.17487/RFC6547)