At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote:
>The flaw in your argument is that you're assuming that the only reason
>to do NAT is because of the address space problem. My concern is that
>it may turn out that some transport/routing people may conclude that we
>may also need to do NAT to solve the routing problem. In which case,
>we're back to where we started.
>
>I'd feel a lot better if we could get key routing/transport people to
>sign some contract in blood stating that the IPV6 address is guaranteed
>to be invariant, and that any attempt to design boxes which muck with
>the IPV6 address in transit is architecturally out of bounds. That may
>seem to you to be obviously true, but I 10 years ago we assumed the same
>would be true for IPV4 addresses.
I'm not sure that this is possible - part of the characteristics of today's
Internet is that its is flattening out. The concept of hierarchical
connectivity with 'upstreams' and 'downstreams' is one which appears to
have relied on a high marginal cost of communications services. Now as I
understand the current deployment plan there are TLAs and sub TLAs, and an
apparent hierarchical view of the world again.
Imagine, for a second, what the topology of the Internet would be if
communications services were free. Now turn up the unit cost knob an little
and do the same thought experiment.
Part of the issue we faced in the Big Internet discussions, and part of the
issue we face now is the semantics of the address and the level to which
these semantics are overloaded. Is an address an identification of
identity? A key to absolute location? A key to relative location? An
encoding of the local topology? My concern, and the reason why I'm chiming
on Ted's signing blood proposal is that in looking at the structure of V6
addresses, at least the structure of the immediate deployment 1/4 or so of
the addresses, we appear to have adopted an approach which is not far
removed from the provider address hierarchy structure of V4 today. My
lurking concern is that it is not working in the V4 routing system given
the large percentage of table entries which are more specific
advertisements of aggregate announcments (approx 40%) and it won't work for
V6 either (using the term 'work' very loosely in terms of being able to
route accurately, efficiently and with a clear scaling property).
It appears that the intended address structure and deployment structure
appear to be at variance, and when that happens the temptation to alter the
address in flight to suit each local region's environment may well be
overwhelming. So I'd prefer to keep my blood to myself, thanks as its a
contract I suspect we'll break within the operations environment. (and no I
don't think that this would be a clever move, and yes, we will regret it
afterwards.)
