> Agreed. > > But I think there was a lot more discussion about this in the very > early days, when 128 bits was chosen, and when stateless address > autoconfiguration assumed that the Interface Identifier part of an > address was 48 bits, leaving 64+16 bits for routing. > > Then, we made the decision to make Interface Identifiers 64 bits, > shrinking the routing part to 64 bits. > > I agree completely that the /64 boundary was/is architectural. For > better or for worse, stateless address autoconfiguration (as currently > specifies) only works on links that have a /64 assigned to them. > > But the /48 boundary is not. Strongly disagree. The /48 boundary was a fairly direct consequence of the /64 boundary and of the decision to align DNS address lookups on 4-bit boundaries. There might not be any strong protocol dependence for the choice of /48, but the need to balance the needs of users for flexibility against the need to conserve address space made /48 a fairly obvious choice after the issues were considered. And no, it's not something that we should wire into our protocols any more than necessary - as we might find out in the future that the boundary needs to be moved one way or the other. That doesn't mean that it can be changed at the RIRs' whim.
(Really I wish we hadn't wired /64 into our protocols. But that's water under the bridge.) > We had a long discussion about that in > the IPv6 WG, and our specs were carefully cleansed to make sure there > were no real dependencies on such a boundary. Think Randy Bush saying > "your reinventing IPv4 classful addressing" about a thousand > times. :-) > He was certainly right in the sense that leaving flexibility in the protocol specs and implementations leaves wiggle room for later. On the other hand, what the RIRs are now showing us is that such flexibility gives others room to change fundamental design decisions without due consideration to the factors that produced the original compromise. Maybe fixed boundaries would have been better after all. (I don't really believe this, I just think that trust in the RIRs to make these decisions is misplaced.) > Indeed, even though the official IETF party line is that links have to > have 64 bits of subnet addressing assigned to them, a number of > operators screamed loudly that for internal point-to-point links, that > was horribly wasteful and they weren't going to stand for it. So, > products do indeed support prefixes of arbitrary length (e.g., /126s > and the like), and some operators choose to use them. This is one of > those situations where the IETF specs seem to say one thing, but the > reality is different. And we pretend not to notice too much. > I do wish we had some sort of feedback mechanism for observing when people don't implement our specifications and why. Such feedback shouldn't compel us to change our specifications to reflect "reality", but it might give us cause to change them in some way or other - either to provide a better way of doing what people need, or maybe to explain why a particular extension or practice is undesirable even though it appears (from a limited perspective) to be useful. >> Second, the notion that RIRs set addressing policy is one that >> has not been in place forever. Indeed, it has evolved very >> slowly and mostly by assertion by the RIRs that they have that >> authority --assertions that, in other contexts, might look a lot >> like either filling a vacuum or turf grabs depending on one's >> perspective. While they have always (since there have been >> RIRs) had broad discretion within their own regions, and it has >> always been recognized some coordination discourages >> forum-shopping and other bad behavior, global address policy was >> historically set by IANA in conjunction with the IAB, not by the >> RIRs (although I assume their advice was certainly welcomed). >> > > Understood. But I think the reality today is that we have the world we > live in and serious suggestions to overturn the current world order > better have a strong and compelling motivation. > Again, our job is not to wire (somebody's notion of) "the reality today" into protocol designs that need to serve us long into the future. Trying to make our protocols reflect current practice is like chasing one's own tail - rather pointless. >> Without taking any position on whether the ARIN decision is a >> reasonable one, I believe that the IETF has had, and continues >> to have, a role in the general design of addressing >> architectures and hence in allocation strategies. I also >> believe that the RIRs have some obligation to consult the IETF >> before making a major policy change and to pay careful attention >> to anything rational the IETF has to say. I also believe that >> things are seriously out of joint if we need to worry about >> whose toes are being stepped on before opinions are expressed. >> > > I think that has mostly been happening, though it could always be done > better. The proposed changes to the HD ratio and /48 boundary were > certainly discussed in the IPv6 WG when they took place. Perhaps, but I don't see any evidence of IETF-wide consensus on this. And it's not like it doesn't affect all of us. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
