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

[Usman Latif <[e-mail]>]

Thanks Wes for the feedback.
Some points I'd like to further comment on:

i. You mentioned that a re-address event is no different from re-masking the links- 
this is true to an extent but I think changing subnet mask would still be relatively easier to manage than having to re-address all links and loopback interfaces. If we can think of an alternative to re-masking, I am open to consider and talk about it.
I think the impact is considerable and obviously different people may have different views on the extent of impact.
Note: having to renumber loopbacks that have been assigned /128 from the same /64 e.g. is an even bigger risk because protocol adjacencies and a lot of control plane peering relationships are bound to it
Also as a service provider, the impact may not just be limited to the SP backbone but also the SP's end-customers which which means there will be political and legal issues arising out of SP wanting its customers to renumber e.g PE-CE links where the SP may have used /127s from the same /64 block
So IMO the impact is significant!

ii. You also mentioned that IP address on p2p links don't matter and that the risk is being oversold.
I think not all implementations have p2p links with local significance only and also a router may not need to advertise the p2p link to its routing peers but it would still pose a problem if the router is in the forwarding path of packets destined to/from addresses that conflict with specially assigned addresses (current/future) using lower-64 bits of the v6 address space. Again the loopbacks need to be considered here too for the same reason mentioned above.

iii. You raised a point around RFC 6164 that future implementations would need to take it into consideration and in good conscience existing implementations that have used /127 or similar on p2p links from the same /64 block cannot be ignored.
I agree to this point but I think if a new RRC or even the existing RFC 6164 mentions this explicitly that a carrier may or may not have /127 from the same /64 block, it would cover all bases and ensure that we don't end up in any controversy in future.


Regards,
Usman

Sent from my iPhone

On 22/09/2012, at 5:23 AM, "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.
> 
>>> 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.