[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03



On 17-feb-2006, at 0:23, Tony Li wrote:

I don't think we are very far away from allowing the routers to change
the source locator in shim6, but I don't feel we collectively
(IETF+NANOG etc) know how useful such a capability would be.

I'm not convinced that letting routers change the source locator in
shim6 would be a good solution. This will add new mechanisms on the
routers, force them to maintain some additional state and could lead to
a NATification of IPv6.

Shim6 is a NATification of IPv6 anyway, it just colocates the NAT
function with the individual host.

Letting the routers change the the source locator turns out to be very, very useful in aiding the access ISP in doing source address filtering.
   Without that, we have the choice of unintentionally sending packets
with an inappropriate source locator to our access ISP, or warping our
IGP's and forwarding algorithms to work based on the source locator.
The latter is a major shift away from where IP has been since 1983.

There are two problems with allowing routers to rewrite source addresses:

1. The routers must know which packets are "legacy" and can't have their source address changed vs which packets are controlled by shim6 or another mechanism that can handle rewritten source addresses.

2. In current shim6, only previously negotiated source addresses may be used, which means the shim6-enabled hosts in a site and the rewriting routers must coordinate their efforts so correspondent hosts don't see unexpected source addresses.

The first issue is readily solvable by simply having shim6 hosts put a magic value in the upper 64 bits of the source address that indicates "rewriting permitted".

The second issue is a bit more complex but not fatally so, IMO.

So if we want to, we can explore source address rewriting.

The reason we haven't done so (or, at least, the reason I haven't pushed this) is that it doesn't solve anything in the short term because we can't depend on this capability in the forseeable future, so shim6 must also work without the rewriting capability present.