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" <[email protected]> wrote: > Responding to a couple of different things below inline with [WEG] > > From: [email protected] [mailto:[email protected]] 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 <[email protected]> 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
