Subject: RE: Making private IPv4 addresses public

From: Remi Denis-Courmont <[email-masked]>
Date: Thu, 1 Jun 2006 09:11:52 +0300

Selon "Manfredi, Albert E" <[email-masked]>:

> I'm not sure what different the intermediate routers would have to do,
> if anything.

Nothing. But policy boxes and firewalls would be slower because of the IHL
difference.

> 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.

It DOES depend on a new addres format. You'd not only have to define a way to
write host A behind NAT B, but you have to use a new sockaddr addresses
family so that this actually become usable in any application willing to
leverage this function. And you need a new DNS record type.

Besides it's obviously broken if you have more than one level of NAT because
sockaddr and DNS records would have a fixed length, so you couldn't put this
IP option multiple times.

And, it would cause a bunch of fragmentation headaches on the NAT box to
insert the IP option.

-- 
Remi Denis-Courmont
http://www.simphalempin.com/home/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 1 Jun 2006 12:18:20 +0200

So we can see that as a migration technique too: when you have a
plurality of IPv4 networks that you do not want to migrate immediately,
this might actually provide a way to migrate at your own rhythm. As you
point out it is easy to define the double-mapped format using a mix of
mapped address and 6to4. So if one end is IPv6 it can use a v6 header
and then the "NAT-PT" has a very simple operation to run. 

In the v4 space, I would not concatenate the realm Id and the private
address but use a format similar to tunnel. The source would encaps the
private to private packet in a realm to realm header. The packet would
reach the realm gateway which would take the inner destination and
overwrite (or swaps like we do with routing headers) with the outer
destination. Note that this operation is stateless, so it can be very
quick. 

The issue is that a every host needs to be upgraded to understand that
there is a realm Id and a host Id, in order to parse DNS records and
talk to a host in another (private) realm in the appropriate format.

Pascal

>-----Original Message-----
>From: Jeroen Massar [mailto:[email-masked]]
>Sent: Wednesday, May 31, 2006 9:13 PM
>To: Manfredi, Albert E
>Cc: [email-masked]
>Subject: Re: Making private IPv4 addresses public
>
>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.
>
>[..]
>> 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.
>
>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
>>
>> 138.194.35.33:192.168.1.5
>
>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