Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa]

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 4 Apr 2005 18:30:51 +0200

Hi Hesham:

Since the subject was dormant for a long time, Doors was not updated,
maybe since you last read it :) To answer your question, we saw that
there are a few operations associated to NAT traversal. In the context
of doors:

a) as we said, keep alive, which doors associates with the BU lifetime.
We have a BU lifetime, the question is the duration, and whether we can
afford to turn it to a relatively low value in order to keep NATs
active. The MN has heuristics to select a roaming interface, and the
cost/bandwidth of that interface is used in that computation. 

After that, it's the node's policy: If the MN really wants to connect
and the only solution is via a NAT, or simply if it's the best way for
its seletion algorithm, then it'll pay the cost of a short lifetime and
go via the NAT.

b) MN operation: it restores its CareOf from the IPv4/UDP headers. Just
a few memory copies. The MN can see both the private and the public
addresses and ports being used, and compute whether they were NATed by a
simple comparison between those.

c) Doors gateway operation. Same, plus a specific operation on DHAAD
since the upper layer checksum is impacted by the CareOf modification.

~d) There's no impact on the HA or on the MIP6/NEMO protocol being run.
As Pekka says, Doors is not a MIP modification but yet another automatic
tunneling mechanism, that takes advantage of existing MIP6 mechanisms
and states.

Out of all this, there's nothing much to turn off. I'd say it automatic.
The lifetime adjustment is a MN algorithm based on its config and
policy. Same for accepting a NAT on the way.

Pascal

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf
Of
| Soliman, Hesham
| Sent: Monday, April 04, 2005 5:30 PM
| To: Pekka Savola; Henrik Levkowetz
| Cc: [email-masked]; [email-masked]; Ryuji Wakikawa
| Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-
| solimananddraft-wakikawa]
| 
| 
| 
|  > Note that AFAIK, NAT traversal between the bidirectional
|  > MN-HA tunnel
|  > is likely going to be rather simple (if keepalives are considered
OK
|  > in the scenario; as Hesham points out, they might be completely
|  > unacceptable in some sceanrios [but that's why it could be
|  > possible to
|  > turn them off it there is no NAT on the path]).
| 
| => Exactly right. This is why in draft-soliman the choice was made
| to not include the NAT traversal by default. It would be nice
| if something can be added/removed when needed. For instance,
| when managing local mobility there is no need for NAT traversal,
| when managing global mobility you might need it.
| I haven't read doors/teredo in a looong time and can't remember
| if there is anything that can be used to turn this on/off.
| 
| Hesham
| 
|  > --
|  > Pekka Savola                 "You each name yourselves king, yet
the
|  > Netcore Oy                    kingdom bleeds."
|  > Systems. Networks. Security. -- George R.R. Martin: A Clash of
Kings
|  >
|  > _______________________________________________
|  > Mip6 mailing list
|  > [email-masked]
|  > https://www1.ietf.org/mailman/listinfo/mip6
|  >
| 
| ===========================================================
| This email may contain confidential and privileged material for the
sole
| use
|  of the intended recipient.  Any review or distribution by others is
| strictly
|  prohibited.  If you are not the intended recipient please contact the
| sender
|  and delete all copies.
| ===========================================================
| 
| 
| _______________________________________________
| Mip6 mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6