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

["George, Wes" <[e-mail]>]

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.

>>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.

>>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.

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.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.