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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf