I guess another problem here would be the en-route option processing in IPv4 which would make traffic to/from NATed boxes (even) slower and would require intermediate boxes to implement/process such option, so not sure how grafecul this mechanism would be.
Regards, Dimitris. -----Original Message----- From: Manfredi, Albert E [mailto:[EMAIL PROTECTED] Sent: 31 May 2006 18:10 To: ipv6@ietf.org Subject: Making private IPv4 addresses public Not sure if this is the right wg for this idea, or for that matter if I'm suggesting anything new. A comment yesterday made me wonder why private IPv4 addresses can't be used more effectively, with an updated version of the NAT. RFC 3022 explains that you can have "Basic NAT" or "NAPT." Basic NAT is very easy to use, because all you do is map one unique global address into one unique private address. No messing around with Port IDs at all. NAPT is used to map one public IP address to multiple private IP addresses behind the box (the common use of NAT). NAPT is great for expanding the usefuless of the 32-bit IPv4 address, but for the most part, it depends on applications from behind the NAT initiating sessions, and it has to change the value of TCP or UDP Port IDs. So this is not so great. Wouldn't it be nice if we could have NAPT without the TCP/UDP Port ID trick? What if the private IP addresses behind the NAT became explicitly visible from the WAN side of the NAPT box? Packets addressed to hosts behind the NAT would carry both the global IP address of the NAT and, appended, the private IP address of the host. The DNS would also carry that information. To enable this, one could assign an option in the IP header, conceptually similar to the source routing option. So at the end of the standard IP header would be appended the source and destination private IP addresses from behind the NAT. Dynamic DNS can be augmented to include this information. And note that the private IP addresses behind any given NAT can be reused by other NATs at will, just as they are now. DHCP would also work just as it does now in NAPT. When the packet arrives at the NAT, with the additional IP header option, the NAT routes directly to the explicitly identified host, without having to use the Port ID bits for this purpose. In principle, this creates a 64-bit address space for IPv4 (and possibly you could even concatenate the scheme to increase this further). The address notation might look something like 138.194.35.33:192.168.1.5 where the : separates the global from the private addresses. No reason why such a scheme can't be introduced gracefully, without precluding operating the old fashioned way at the same time. Thanks. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
