Subject: [mobile-ip] RE: NAT traversal addresses

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 6 Jul 2003 14:59:59 +0100

Hi Mike,

Please note that the IPv4/UDP tunnel encapsulates the IPv6 traffic for the traversal, but that everything (IPSec, end to end IPv4 traffic encaps, retransmissions) occur at IPv6 layer. The NAT will just see a protocol for which there's no ALG and let it through or not based on its policy. I do not see what the low end NAT you are mentioning would do with an IPSec that it does not even parse.

-----Original Message-----
From: Michael R. Cole [mailto:[email-masked]] 
Sent: dimanche 6 juillet 2003 06:29
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: NAT traversal addresses

Dear Pascal,
 
If a timesharing system has only 1 global IPv4 address (door) then the port number would serve as a 16-bit extension of the IPv4 which is essentially the same mess that a NAT box presents. You could still use 6to4 for this but the idea is to use the \80 suffix to carry information that allows the timesharing system to -easily- indentify not only the port number but possibly also the job numbers and so forth. Even if a timesharing system has a native IPv6 address and data line there still is the problem that each user needs its own IPv6 address in order to keep the port number from being used as an address extension in IPv6 - I am just suggesting a way that a timesharing system could systematically assign a unique address to each user that does not involve random number generation.
 
=> For the time sharing system, I do not understand your point. Is it supposed to be the mobile node or the Door? I suspect it's the MN. In that case, the source port can be chosen dynamically when creating the socket for the Doors tunnel, you do not have to bind the doors port on the MN. So the IPv4 address can be also used for other things, and you could have more than on Doors tunnel, if you wished. For instance if you have multiple CoA to multiple HAs.

I can understand wanting to use tunneling within UDP because UDP is the simpler protocol but if a firewall only allows TCP or if the user would rather use TCP because a link is noisy (such as a wireless ISP or off of one of the Hughes satellites) or some other restriction then there needs to be a way to allow TCP.

=> I agree with the requirement. The point is that making the Door stateful is against the principles of that draft and changes it too dramatically. But we could write another draft to propose a stateful transport such as XCP for satellites. I suspect that the Door would generate a locally significant II for each socket that would actually be the index in a connection table. 
 
There is also the problem that some of the cheaper NAT boxes tend to choke when somebody tries to run IPsec or HTTPS through it in which case we would need a flag that essentially says, "use some type of workaround or otherwise do what is needed to keep a low quality NAT box happy." One of the issues that I have seen discussed elsewhere is that some NAT boxes have incomplete implementation of some things that SHOULD be there. I have been told that some do not support FTP.

=> I need more specifics to understand that point. Again, those things occur above IPv6 and should not be checked by the NAT.

Pascal

---

From: "Michael R. Cole" <[email-masked]>
Date: Tue, 15 Jul 2003 15:43:37 -0400

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Michael R. Cole" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 06, 2003 9:59 AM
Subject: [mobile-ip] RE: NAT traversal addresses

> Hi Mike,
>
> Please note that the IPv4/UDP tunnel encapsulates the IPv6 traffic for the
traversal, but that everything (IPSec, end to end IPv4 traffic encaps,
retransmissions) occur at IPv6 layer. The NAT will just see a protocol for
which there's no ALG and let it through or not based on its policy. I do not
see what the low end NAT you are mentioning would do with an IPSec that it
does not even parse.
> If a timesharing system has only 1 global IPv4 address (door) then the
port number would serve as a 16-bit extension of the IPv4 which is
essentially the same mess that a NAT box presents. You could still use 6to4
for this but the idea is to use the \80 suffix to carry information that
allows the timesharing system to -easily- indentify not only the port number
but possibly also the job numbers and so forth. Even if a timesharing system
has a native IPv6 address and data line there still is the problem that each
user needs its own IPv6 address in order to keep the port number from being
used as an address extension in IPv6 - I am just suggesting a way that a
timesharing system could systematically assign a unique address to each user
that does not involve random number generation.
>
> => For the time sharing system, I do not understand your point. Is it
supposed to be the mobile node or the Door? I suspect it's the MN. In that
case, the source port can be chosen dynamically when creating the socket for
the Doors tunnel, you do not have to bind the doors port on the MN. So the
IPv4 address can be also used for other things, and you could have more than
on Doors tunnel, if you wished. For instance if you have multiple CoA to
multiple HAs.

Usually, a timesharing system is a stationary node, but the user should in
the modern office be able to transfer easily from a stationary node to a
mobile node (such as a PDA) and back again. I am also trying to say that a
system should be able to assign a unique address to each process in a way
that makes sense without having to use an associative table. Since most
modern workstations have multitasking just about any system can be a
timesharing system even if it has only 1 terminal.

There is also the problem with using EUI-64 fornat that using an active
manufacturer's ID could create a legal problem or a problem with Duplicate
Address Detection if DAD is used as part of an intrusion detection system.
I.e., an intruder tries to fool a firewall by spoofing a legitimate address.
>
>
>
> I can understand wanting to use tunneling within UDP because UDP is the
simpler protocol but if a firewall only allows TCP or if the user would
rather use TCP because a link is noisy (such as a wireless ISP or off of one
of the Hughes satellites) or some other restriction then there needs to be a
way to allow TCP.
>
>
> => I agree with the requirement. The point is that making the Door
stateful is against the principles of that draft and changes it too
dramatically. But we could write another draft to propose a stateful
transport such as XCP for satellites. I suspect that the Door would generate
a locally significant II for each socket that would actually be the index in
a connection table.

The idea of having some behavior flags is to carry some bookeeping
information with the address so as to avoid having hard states. I do not
believe that it is possible to have a truely stateless protocol but it would
certainly help to have what I would call stateleast where hard states are
minimized. Carrying some bookeeping information with the address would also
help to some extent when a NAT box is a cluster implementation.
>
> There is also the problem that some of the cheaper NAT boxes tend to choke
when somebody tries to run IPsec or HTTPS through it in which case we would
need a flag that essentially says, "use some type of workaround or otherwise
do what is needed to keep a low quality NAT box happy." One of the issues
that I have seen discussed elsewhere is that some NAT boxes have incomplete
implementation of some things that SHOULD be there. I have been told that
some do not support FTP.
>
> => I need more specifics to understand that point. Again, those things
occur above IPv6 and should not be checked by the NAT.

What I have been told is that some NAT boxes will not run FTP, HTTPS, IRC,
and a few other vital protocols. Some NAT boxes use packet snooping and
rewriting in an attempt to speed up communications. In actuality, packet
snooping is the job of the firewall and antivirus programs. For instance,
Wingate from deerfield.com does not support America Online 6.0 and they have
a whole list of protocols and Internet Service Providers that they do not
handle. On the other hand, Sygate Home Network form sybergen.com supports
everything that I want to do. One reason why I have kept America Online is
that if middleware will carry AOL it will probably carry everything else.

I do not think that we should cater to the crummier NAT boxes.