Subject: [mobile-ip] NAT traversal addresses

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

Dear Thubert,

I would like to state more concisely what I wrote in my letters before subscribing to mobile-ip.

1. Using 6to4 for NAT traversal would not work because RFC 3513 states that unicast addresses that do not start with 000 binary must use EUI-64 format which means that you would have to waste 3 bytes on a real or fictitious manufacturer id.

2. I have a feeling that having both a global side port number and a site level aggregator would be redundant. The port number would provide the same information as the SLA.

3.You might want to have a second /16 prefix that says, "Forget about the NAT box and use the IPv6 router that advertises itself as bypassing the NAT box." You could use 6to4 + isatap for this but changing just the /16 prefix might be an easier and less mistake prone method.

Perhaps this address format would work:

bits
0    1   1                                4   4                     6   6                 7   8         9  9                     12
0    5   6                                7   8                     3   4                 9   0         5  6                       7

1001 : globalIPv4addressofdoor : globalportnumber : behavior flags : localport : localIPv4address

A /16 prefix along the lines of say 1002::/16 would tell the algorithm to bypass the NAT box by using an appropriate router; in this case the global port number would serve instead as an SLA.

Behavior flags - We would need:

Flag 0 (bit 64): NAT box can run TCP
Flag 1 (bit 65): NAT box can run UDP
Flag 2           : Need to 1s complement the local address and port number because we have a vile rewriting NAT
Flags 3 to 5 or 7: Number of LAN segments that are attached to the NAT box - the value of zero would be the special case of a timesharing system a.k.a. terminal server that has only one global IPv4 address and uses the port number as an extension of the IPv4 address  The local port and address fields would then be used by the system for job number or process ID.
Flag 8: Port restricter a.k.a. firewall present - expect connection setup to take some time.
Flag 9: NAT box supports IPsec

There are probably some other behavior flags that would be needed. Any comments on this?

MIke Cole, [email-masked] Seven Hills, Ohio (near Cleveland) U.S.A.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Jul 2003 09:52:47 +0100

Hi Michael

> Dear Thubert,

Actually first name is Pascal :)

> 1. Using 6to4 for NAT traversal would not work because RFC 3513 states that unicast addresses that do not start with 000 binary must use EUI-64 format which means that you would have to waste 3 byt…
 
Since we are defining an extension to this (what is a EUI 64 on an IPv4/UDP tunnel?) then this is playing with words. I proposed to reuse 6to4 for simplicity but there's no necessity. You still want a global aggregatable address so that the Door can get the packets from the HA. In a lot of cases (CGA, autoconf) the II is be forged as well.

> 2. I have a feeling that having both a global side port number and a site level aggregator would be redundant. The port number would provide the same information as the SLA.
 
Right, I proposed to use a global port to make UDP decaps easier.

> 3.You might want to have a second /16 prefix that says, "Forget about the NAT box and use the IPv6 router that advertises itself as bypassing the NAT box." You could use 6to4 + isatap for this but…
 
Right. But forcing this in all cases requires a outgoing door in each private domain. Actually there's something similar in the draft: If a local door can be found by means such as DHCP extension, then the MN could decide to use that door.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Jul 2003 10:25:29 +0100

Hi again,

I split because there are many points in your mail. 

> 3.You might want to have a second /16 prefix that says, "Forget about the NAT box 
> and use the IPv6 router that advertises itself as bypassing the NAT box." 
> You could use 6to4 + isatap for this but changing just the /16 prefix 
> might be an easier and less mistake prone method.

 
> A /16 prefix along the lines of say 1002::/16 would tell the algorithm to bypass 
> the NAT box by using an appropriate router; in this case the global port number 
> would serve instead as an SLA.

> Behavior flags - We would need:
 
If you use anything but datagram as transport (say TCP or SCTP ...), you need to maintain a context for the socket to the MN at the Door. Not infeasible, but it seems to me that you would want to keep a context information (an index of some sort) as the II of the CareOf that you send to the HA, as opposed to the IPv4 addresses. What do you think?

Whether we reuse the SLA field to apply some semantics on them is a good discussion. I hope the ML will help here.

> Flags 3 to 5 or 7: Number of LAN segments that are attached to the NAT box - 
> the value of zero would be the special case of a timesharing system a.k.a. 
> terminal server that has only one global IPv4 address and uses the port 
> number as an extension of the IPv4 address  The local port and 
> address fields would then be used by the system for job number or process ID.

But the Door has no specific process on that so why should it know? 

OK, this is interesting. You add controls to the address. Note that this control especially opens to DAD (SYN) attacks on the Door (since I understand that in your mind it is terminating TCP, right?).

IPSec that I had in mind was at IPv6 level, transparent to doors. Can you please elaborate on the use for this?

The key for the design of Doors is that it is stateless in the gateway, because it uses UDP and saves everything in the CoA in the binding cache. I believe that if we change that philosophy, the doc will become much more complex with security and scalability issues. I suspect it's easier to close something based on UDP first, and then if it's successful, to see how other transports could be used.

I'm interested in your suggestion for controls. Our implementation does not need any at this point but it may come up as we test in more situations.

Thanks a lot

Pascal