> From: William Herrin <[email protected]>
>>> a fundamental problem of Loc/ID split solutions based on address
>>> rewriting when hosts have only a single local address but their edge
>>> network is multhomed to the outside world.
> The problem is that A received a return packet from B that might have
> been from 3 and might have been from 4. But A has no idea what to do
> with a packet from 4.
Ah, got it. Hence the reference to "based on address rewriting", in the
original message. Since I'm mostly thinking in a 'wrapping' world these days,
I'm unfamiliar with these problems... :-)
The wrapping has the benefit of allowing one to not have to discard
information (which one has to when one doesn't have enough fields at hand to
hold them all); one can keep the original identifier, and have the locator
too. (Which is fundamentally the problem above - trying to put the proverbial
10 pounds in a single 5-pound field...)
> Per Michael, the solution is either:
> 1. Stateful NAT. ... so that [it] can put source 3 back on the outbound
packet.
> 2. Host modification. ... The host echos this in the return packet
Well, the second is clearly infeasible. The first isn't so hot either.
Which leads me, in the context of Tony's earlier observation (that the RG
more or less unanimously now holds that separation of location and identity
is a crucial underlying piece of foundation for solving the routing
scalability issue), to a proposition...
I wonder if we can say that, at an architectural level, wrapping solutions -
or, more generally, any solutions which carry both the locator and the
identifier in the packets - are inherently and inescapably superior? This
seems fairly logical, to me: clearly, if one can't carry both locator and
identifier, one has to throw one away; and having done that, there are almost
inevitably going to be problems caused by cases where one needs whichever one
of the two one no longer has...
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
