Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks

TJ <> Fri, 21 September 2012 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 534D921F869E for <>; Fri, 21 Sep 2012 12:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o0RRoy+ZiDVq for <>; Fri, 21 Sep 2012 12:45:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7692021F869D for <>; Fri, 21 Sep 2012 12:45:08 -0700 (PDT)
Received: by wibhi8 with SMTP id hi8so2023476wib.13 for <>; Fri, 21 Sep 2012 12:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=EShv+nLpRRH5rGQp07xKaILBFaCQVn7A3EpLKq0gCnU=; b=Jydviw5oyx8KYd2cnzdjO9vHtcbozV0MXJ/eB2HShNB6dvTBzdDpvbzrC6uypGy+x0 eAWVlPsC5cPRCCajCNwLuNMF8kVHGsYmP3ycdAhjvpeoXiGzsSLTtnloRY/LBKSzSacV N2KMcex0mO7wXfovZ6PKXaLI591VsAjGrn/a1ufwtHpONHlG4eBTHTaW+YAWBOf27GAy 6IxbgVdv619mN4t+drK1sSLZdEH3zcQVHntQHZtTRaJWnUCx+v+PDwGXaWOj8MKhrYnp hK0RrHrAv4EzK8O4dE5lSjQawAvYtFV4T59e+JElGnX+3ikyK4rhC4W8n7Z/GLVadX9q 6osg==
Received: by with SMTP id gg5mr6359519wib.9.1348256707567; Fri, 21 Sep 2012 12:45:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Sep 2012 12:44:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: TJ <>
Date: Fri, 21 Sep 2012 15:44:46 -0400
Message-ID: <>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: IETF IPv6 <>
Content-Type: multipart/alternative; boundary=f46d041825bc1edf3804ca3b7a55
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2012 19:45:10 -0000

On Fri, Sep 21, 2012 at 3:23 PM, George, Wes <>wrote;wrote:

> Responding to  a couple of different things below inline with [WEG]
> From: [] On Behalf Of
> Usman Latif
> >>"If you choose to do this, it is further recommended that you reserve
> the entire /64 so that - if needed in the future - you can expand this
> configuration _without_ a major renumbering event."
> [WEG] I’m not sure that renumbering P2P links is comparatively harder than
> changing the subnet mask, nor would I characterize one as a major
> renumbering event and the other not. You still have to touch all links, all
> devices, the only difference would be for things that are configured to use
> the link IP to communicate with the router, and a lot of those can be
> managed using make before break provisioning.  There are several IETF
> documents (and a whole WG) covering how to manage renumbering in a more
> painless fashion, and this is one that is pretty straightforward.

Indeed; however - if your addressing plan needs to be redone
to accommodate the renumbering there may be no small amount of pain

> >>This is the essence of what I want the IETF to put in one of its address
> recommendation RFCs because I have yet to see an RFC that says when you
> assign a /127 to a p2p link, you should/must reserve the whole parent /64
> for that p2p link also.
> [WEG] I think that part of the reason you haven’t seen that RFC is that
> there’s an argument to be made to the contrary as well – there’s some value
> from a configuration management and operational perspective in being able
> to use one line of config to manage things like route aggregation,
> filtration, management tools access, access lists, etc.  Yes, you can do
> that with a larger block (e.g. allocate the top /48 of your /32 for
> infrastructure) but that adds a lot of addresses to be permitted through
> the filters that simply aren’t necessary nor will ever be used, and exposes
> you to other attack vectors in a way that isn’t necessarily justifiable, at
> least IMO. This is very much a case of YMMV, so I’m not sure that “reserve
> the whole /64 for each /127” is universally something we could or should
> recommend, especially if it’s mainly a “just in case, you never know what
> craziness those protocol wonks in IETF might come up with that would break
> it in the future...mumble mumble…” kind of reason.

While I do not set out to tell anyone how they must run their network, I do
embrace the idea of minimizing future problems / rework ... :)

> >>Without this stated clearly there is likely to be some instances where
> readers interpret it the wrong way and end up assigning multiple p2p links
> with /127 subnets from a single given /64 and end up having to re-address
> their network in future when/if future standards use lower order 64 bits
> for special purposes.
> [WEG] Given the fact that there is a standard that documents the use of a
> /127 for P2P links (6164), future standards can’t use lower order 64 bits
> for special purposes without considering the potential impact to this
> standard, and even if the standard didn’t exist, the existing installed
> base cannot be ignored in good conscience. The question to ask here is what
> problem we’d be trying to solve with “future standards that use lower-order
> 64 bits for special purposes” that would make supporting it necessary on
> P2P links where the IP address assigned often doesn’t even matter except
> for diagnostics? In many cases, the P2P link neither sources nor receives
> traffic except the odd ICMP response, and even that type of traffic could
> be configured to use the loopback (see also ip unnumbered). Some carriers
> don’t even put those links in their IGP for security reasons. To underscore
> the relative unimportance of the P2P link address, there are even
> discussions happening within IETF right now about using ULA space for P2P
> internal links. (Note: I’m just noting that the discussion is happening,
> not endorsing it). Not all implementations fit this model, but I think the
> risk of the need for a renumber in this case is being oversold somewhat.
> The reality is that few of us are going to get the numbering plan 100%
> right the first time, no matter how smart we try to be in the way that we
> future-proof our allocation plan, because there’s no one size fits all
> solution. We can talk about best practice based on what we know today, but
> anything more is just educated guessing, and my 8 ball is no better than
> anyone else’s.

Again, agreed - but if I can, with relative ease, mitigate a potential
source of that problem I'll take it :).

> On 21/09/2012, at 10:02 PM, TJ <> wrote:
> >>WRT Point-to-point links (only, any multi-access link REALLY should be a
> /64): For those that insist on using something else, it is loosely accepted
> that a /127 can work
> [WEG] Let’s be clear. RFC 6164 is a product of IETF consensus and a
> proposed standard, and the reason that it was pushed forward and the
> previous guidance was amended was that multiple large operators came
> forward and said “this is what we’re *already* doing, you’re welcome to be
> wrong, or you can update your guidance.” That’s not “loosely accepted”. I’m
> not saying that it’s universally supported by all IPv6 stacks, nor that
> consensus = unanimous agreement, but it’s not a corner-case hack either.

Fair point - other values for PrefLen have been proposed/mentioned over the
years  (/112 and /126 come to mind).
Just that, IMHO, if you aren't using a /64 a /127 is the next best thing
... I'm always interested in hearing additional justifications / deployment
drivers :).