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

[TJ <[e-mail]>]

On Fri, Sep 21, 2012 at 3:23 PM, George, Wes <[e-mail]>wrote:

> Responding to  a couple of different things below inline with [WEG]
>
> From: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> 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