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

TJ <trejrco@gmail.com> Fri, 21 September 2012 19:45 UTC

Return-Path: <trejrco@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534D921F869E for <ipv6@ietfa.amsl.com>; Fri, 21 Sep 2012 12:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0RRoy+ZiDVq for <ipv6@ietfa.amsl.com>; Fri, 21 Sep 2012 12:45:08 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7692021F869D for <ipv6@ietf.org>; Fri, 21 Sep 2012 12:45:08 -0700 (PDT)
Received: by wibhi8 with SMTP id hi8so2023476wib.13 for <ipv6@ietf.org>; Fri, 21 Sep 2012 12:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.180.104.197 with SMTP id gg5mr6359519wib.9.1348256707567; Fri, 21 Sep 2012 12:45:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.28.161 with HTTP; Fri, 21 Sep 2012 12:44:46 -0700 (PDT)
In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com>
References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <CALOgxGZ6QLhuoVoqpt+R6paLThEs1zBHBgYzVXuvOqWSdrD9ZA@mail.gmail.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com>
From: TJ <trejrco@gmail.com>
Date: Fri, 21 Sep 2012 15:44:46 -0400
Message-ID: <CALOgxGaDi7dfvkTGBswsJWNsjd=PEXSvqRiVP6rac377xzJaEA@mail.gmail.com>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: IETF IPv6 <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary=f46d041825bc1edf3804ca3b7a55
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: trejrco@gmail.com
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 19:45:10 -0000

On Fri, Sep 21, 2012 at 3:23 PM, George, Wes <wesley.george@twcable.com>wrote;wrote:

> Responding to  a couple of different things below inline with [WEG]
>
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] 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
involved.




> >>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 <trejrco@gmail.com> 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 :).


/TJ