james woodyatt - le (m/j/a) 4/4/09 2:53 PM:
On Apr 4, 2009, at 00:31, Rémi Després wrote:
Isn't Christian Huitema's point about multi-homing relevant
here?
Any reference where the point is described?
<http://www.ietf.org/mail-archive/web/nat66/current/msg00200.html>
Thanks for the ref.
> 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.
I also think it could use some discussion to show how SAM can be
compatible with any-source multicast using embedded rendezvous point
ULA addresses. I think the two methods of overloading the IID
portion of addresses with routing information are compatible, but I'd
like to see a discussion of it.
If rendez-vous points are SAM capable and addressed in the global space,
I don't see why they wouldn't work but, agreed, this justifies specific
a specific discussion.
I confess I am completely lost in regards to the SAM privacy option.
It's clear that that my first text on it needs a lot of clarification
and simplification. Apologies for having not done more of these yet.
The main idea is as follows.
- CPEs exercise a reversible translation of subnet identifier and port
number between internal packets and external packets.
- Parameters of this reversible translation are communicated to hosts.
- Hosts can then do the same translation of between internal packets and
application APIs.
Thus:
- Internal routing can be performed with untranslated subnet numbers
and, in the case of port extended IPv4, on untranslated ports.
- Addresses and ports seen by applications are those that traverse the
global Internet.
Which algorithms to use for the reversible translation could be seen at
this stage as a secondary point. (Gabor Bajko, for example, pointed out
that a modulo n multiplication by an odd number would be pushing too far
the trade off between simplicity and functional effectiveness in the
direction of simplicity, which I accept.)
In my understanding, SAF does need encapsulation in the multihoming
case.
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.
Going further, why to exclude publishing an e2e transparent
solution before a non-transparent one, if this is possible. (Of
course, it can only be possible if tried :-))
Agreed. If we're going to insist on publishing a losing solution for
using translators to make perverse loops fast, can we please, at
least, minimize the damage we do end-to-end in the process?
Thanks.
RD
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
