On Fri, Sep 21, 2012 at 3:23 PM, George, Wes <wesley.geo...@twcable.com>wrote:
> Responding to a couple of different things below inline with [WEG] > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@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 <trej...@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
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
