Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

Philip Homburg <> Sat, 11 March 2017 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A1F51204D9 for <>; Sat, 11 Mar 2017 03:49:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tpRtuCRwKVia for <>; Sat, 11 Mar 2017 03:49:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A50C3129418 for <>; Sat, 11 Mar 2017 03:49:28 -0800 (PST)
Received: from ([::ffff:]) by with esmtp (Smail #127) id m1cmfWW-0000HaC; Sat, 11 Mar 2017 12:49:24 +0100
Message-Id: <>
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
From: Philip Homburg <>
References: <> <> <> <> <>
In-reply-to: Your message of "Sat, 11 Mar 2017 09:57:07 +0100 ." <>
Date: Sat, 11 Mar 2017 12:49:23 +0100
Archived-At: <>
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: Sat, 11 Mar 2017 11:49:31 -0000

> Is there anything here that isn't covered by 5942?
> And creating an artificial separation of prefixes used for address
> assignment (SLAAC) and prefixes used for on-link determination
> seems fraught with dangers. E.g. from a router perspective you need
> a connected route aka an onlink prefix for the prefix used for
> address assignment, otherwise you have no reachability.

It seems to me that RFC 5942 doesn't say a lot about stateless
address configuration. So if we want to say something like 'the IID used
for SLAAC should be 64 bits' then RFC 5942 is not of help.

The classical example where a prefix is not onlink is NBMA networks.
But I can imagine that once IPv4 is out of the way, people will find 
more creative uses where it helps if a prefix that is used for SLAAC is not

Note that in the context of ND, onlink prefixes is mostly about host
behavior, because routers are (in practice) not using them to configure
what is onlink or not. Also note that hosts may consider a prefix not onlink
whereas the router considers the prefix onlink. ND can handle that.