> From: John C Klensin <john-ietf@xxxxxxx>
> For _that_ problem, we had a reasonably effective IPv4 solution .. for
> many years
We only has a "solution" as long as we had a small network. It was not a
solution which would scale. If that was a "solution", then IPv4 is a
"solution" to the need for address space.
> when we imposed CIDR, and the address-allocation restrictions that went
> with it, it became impossible for someone to get the PI space that is
> required ...
> I'll stipulate this is a routing problem as much, or more, than it is
> an address-availability problem.
CIDR was always a single set of mechanisms (ubiquitous use of address masks)
which solved two completely separate problems: i) allocation of address space
in finer-grained chunks, to slow the rate of use, and ii) address table
bloat, leading to routing instability. The routing aspect was not an
afterthought or a later discovery, but an integral aspect from the very
beginning. Thinking of CIDR as a address space allocation mechanism is broken.
> I'll also agree that there appears to be little evidence that IPv6 is
> significantly more routing-friendly than IPv4
"little" -> "none".
> any real routing-based solutions that help the one will help the other.
One of the painful pills the WG members have had to swallow is that there *is
no* "routing-based solution" to providing support for wide-spread
multi-homing (at least in anything like the current routing architecture,
i.e. packets which include only source and destintion addresses, as opposed
to a source route).
If you (or anyone else) doesn't understand why, please review the WG mailing
list archives before claiming otherwise.
> (i) if any of the options turn out to require an
> approach similar to the one that continue to work for
> big enterprises with PI space in IPv4, then we are going
> to need (lots) more address space.
Since the precursor is not going to happen, we don't need to worry about
the hypothetical consequence.
> there is very little that we do on the Internet today that require
> connection persistence when a link goes bad
I made this exact point some time back, and asked if this was therefore
really a requirement, and was told that it was. I remained extremely dubious,
but had no interest (for obvious reasons) in correcting it if wrong.
I will note in passing that if this capability were not really needed, one
might ask why SCTP added it.
> it may speak to the IETF's sense of priorities that the efforts to
> which you refer are predominantly going into the much more complex and
> long-term problem, rather than the one that is presumably easier to
> solve and higher leverage.
The general approach (of multiple addresses) is the only realistic one. Any
analysis of whether the additional requirement (for connection survivability)
has a reasonable cost/benefit ratio needs to start with this ground truth.
It may be that the differential complexity to go from i) multiple addresses,
and established connections cannot switch, to ii) multiple addresses, and
established connections can switch, is minimal. I can't say; I haven't
bothered to look at the (to me, boring) engineering details.
Noel