Subject: Making private IPv4 addresses public

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 31 May 2006 13:10:12 -0400

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 31 May 2006 21:13:10 +0200

On Wed, 2006-05-31 at 13:10 -0400, Manfredi, Albert E wrote:

First of all it's the 31st of May, not the 1st of April....
The mailheaders seem to be fine, but I still don't think they are
genuine. Please sign your messages with PGP then we know who the joke is
really coming from ;)

If you need more address space then go to the RIR in your area and
REQUEST the address space. Pay them the LIR fee and RECEIVE the address
space from them. But hurry current calculations say it is gone per 2015.
And because of things like: http://web.zshell.net/vhost.php maybe even
quicker.... otherwise said those sites can get IP addresses, then you
can also get them.

[..]
> appended, the private IP address of the host. The DNS would also carry

Why invent silly work arounds like this? This already exists:

 - Expanded address space: IPv6 : 128bits
 - DNS change: AAAA

Please, install IPv6 on your boxes not IPv4+weirdstuff.
Note also that your applications would have to be upgraded anyway to be
able to understand this construct, just like they have to already with
IPv6.

[..]
> The address notation might look something like

Which looks just like:

2002:aabb:ccdd:ee:ff:11:22:33::

Guess why there is IPv6....

Please read up on the large variety of transition mechanisms that the
IETF have already come up with over the years, there is bound to be one
that solves your problem.

Greets,
 Jeroen

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 31 May 2006 22:17:53 +0300

Hello,

Le Mercredi 31 Mai 2006 20:10, Manfredi, Albert E a écrit :
> 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.

Such a proposal would probably have made sense in the first half of the 
nineties. I'm actually pretty confident such a proposal has already 
been made, though I must admit I don't known - at that time I wouldn't 
have recognized the Internet (let alone IP and IETF) if it ate my ice 
cream as I was still attending primary school.

As you also mention, this would imply extending the Domain Name System, 
much like IPv6 already did (AAAA), re-did (A6), and then undid (back to 
AAAA). And it would require updating all IP stacks in, at least, end 
nodes and NAT boxes. Forgot to mention it would probably wreak havoc to 
the BSD socket API, and require re-investing all that has been done 
into IPv6-support in existing applications and network infrastructure 
again.

To sum up, ten years ago, while it would not have been as 
technically “clean” as IPv6, it would probably have been less costly 
and disruptive to deploy, all the more as it could probably have been 
completed in a shorter time frame. Nowadays, the cost would probably 
outweighs what's left (however huge) to be invested to pursue the IPv6 
transition.

Regards,

-- 
Rémi Denis-Courmont

---

From: "Eric Klein" <[email-masked]>
Date: Wed, 31 May 2006 22:04:16 +0200

Cross posting this to v6OPs as the whole NAT issue is under discussion that 
as part of  draft-ietf-v6ops-nap-02.txt

From: "Manfredi, Albert E"

As we are working to remove NAT from the general world of IPv6 I am 
concerned to see ideas about extending IPv4 NAT in to IPv6. NATPT is a 
limited use area and as I understand it should not be extropolated to the 
general rules for IPv6.

---

From: "Dimitrios Pezaros" <[email-masked]>
Date: Wed, 31 May 2006 20:31:48 +0100

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-masked]] 
Sent: 31 May 2006 18:10
To: [email-masked]
Subject: Making private IPv4 addresses public

Thanks.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 31 May 2006 16:46:00 -0400

> And it allows for global address expansion without even 
> bothering to request addresses from anyone. I don't think 
> this last feature is available with any other scheme I've seen so far?

Oh, not quite. More like, "It allows the IPv4 address space to be
expanded without having to request addresses from anyone, in a way that
is similar to IPv6 address autonconfiguration."

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 31 May 2006 16:27:47 -0400

> From: Dimitrios Pezaros [mailto:[email-masked]] 
> Sent: Wednesday, May 31, 2006 2:32 PM
> To: Manfredi, Albert E; [email-masked]
> Subject: RE: Making private IPv4 addresses public
> 

Thanks for all the comments.

I'm not sure what different the intermediate routers would have to do,
if anything. I suppose they would have to know to "ignore the private IP
address option in the IP header."

Yes, I do understand that this is not IPv6. It's a way of tackling the
address space problem without depending on a new version of IP or even
on a new address format.

And it allows for global address expansion without even bothering to
request addresses from anyone. I don't think this last feature is
available with any other scheme I've seen so far?

Bert