On Apr 6, 2009, at 08:43, Rémi Després wrote:
james woodyatt - le (m/j/a) 4/4/09 2:53 PM:
[...]
I've read the draft. I don't think SAM is a SAF mechanism; it does
not support reversible translation, i.e. what I prefer to think of
as tunnel compression.
True. Tunnel compression could be added to SAM if the complexity/
new-service is found favorable. But at least in the multi-homing
case with multiple CPEs tunnels are AFAIK unavoidable.
The only way to avoid it would be to upgrade all the IPv6 routers in
the path traversed between hosts and realm gateways to be aware of the
reversible translation (i.e. tunnel compression) mechanism in use.
That approach, while technically plausible I think, would not be
terribly pragmatic.
[...]
I think the point Christian Huitema makes in the message I
referenced above is that NAT66 as currently proposed simply doesn't
work-- and can't reasonably be made to work-- in the multi-homing
scenario he outlines.
With SAM, there are combined parameters for mapping and encapsulation.
In Fred's example, Alice uses her source address the ISP prefix of
which is that of the Bob's root SAM, rule 2 of page 9 in draft-
despres-sam-02 is such that the local destination must be Bob's
local address.
In Christian's example, the same rule is such that Carol sends its
SYN via DAN, it must be with a global source address that includes
the ISP prefix of Dan. Alice's SYN ACK will therefore not return via
Bobby.
In my understanding, this is precisely where SAM solves an otherwise
unsolved multihoming problem.
I think RSIP solved this problem, too, but differently.
Where SAM innovates is by encoding all the routing and tunnel endpoint
configuration into the IPv6 addresses, thereby avoiding the need for a
client-server session at the expense of making it require IPv6 in the
outer tunneling layer.
RSIP is designed to permit both IPv4 and IPv6 at both inner and outer
tunneling layers, but at the expense of requiring an explicit client-
server protocol between hosts and realm gateways.
Which of the two is better is a tough call for me to make right now.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
