james woodyatt - le (m/j/a) 4/6/09 7:36 PM:
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.
Yes. Systematic encapsulation has for it its pragmatic simplicity.
[...]
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.
The RSIP solution has in my understanding many more points for further
study than SAM, but you are right: it does deal with the outgoing
gateway selection problem. Thanks.
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.
IMHO, a key is whether we wish to choose simplicity when and where it is
possible, leaving for possible later steps more complex mechanisms that
deal with more complex scenarios. (I call this "Functional Progressiveness".
RSIP necessitates a new TBD protocol and, using upon-request and
temporary mappings, has the various associated problems (how and when to
reclaim mappings; what if a node is turned off while having been
assigned some mapping etc.) None of this is needed with SAM which, based
on stateless mappings, just needs a few parameters to be advertised to
branch nodes (in DHCP, RAs, DNS-SD, and/or others (?)).
The choice could then be:
- are we interested in studying SAM now, for what it can offer rapidly,
thus letting examination of what a revised RSIP might add to it for a
later time?
- OR do we prefer to insist that dynamic mappings should be included
from the outset, even for all simple cases where stateless mappings are
sufficient?
Regards,
RD
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
