Subject: Re: Making private IPv4 addresses public

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"

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.

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: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 May 2006 15:32:44 -0700

Fred,

At the v6ops wg meeting during IETF64, I presented "Requirements
for IP-in-IP tunnel MTU assurance":

http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-01.txt

Paraphrasing from the minutes (see below), the plan was for
the document to try to find a home in a different working
group such as pmtud or softwires then brought back to v6ops
if the other avenues didn't pan out. Since IETF64, there has
been some discussion in the other groups but apparently no
sustainable traction, so I am returning again to v6ops as
suggested. Please advise on how to proceed from here.

Thanks - Fred
[email-masked]

Exceprt from IETF64 v6ops minutes:
**********************************
IP in IP tunnel MTU assurance (Fred Templin) 

	Draft presentation 

		Tunnel mechanisms have no means of assuring tunnel MTU 

		Issue: IPv4 fragmentation is bad, IPv4 path MTU is not
reliable (NAT, Firewall) 

		List of requirements 

	Dave Thaler: assurance might be too strong a word, we have no
assurance 
	on Ethernet for example, this is best effort. 

	Fred: best effort is what is meant, need to define the
terminology 

	Dave Thaler: this should be reviewed by the pmtud wg 

	Pekka: see some potential problems, maybe not as bad as author
sees. 

	Would be interested in working on this if this was done in the
venue that 
	will work on the solution 

	Fred: what would be the correct venue? Pmtud? 

	Pekka: maybe, need to look again at their charter 

	Dave Thaler: pmtud is the right place with the right expertise, 
	may require a charter update. Documenting the issue in v6ops 
	(and separating the requirement) is the right thing to do 

	Alain: the purpose of v6ops is to document operational issues, 
	so this document belongs here 

	Thomas Narten: Softwire may be the right place to fix the
problem 
	pmtud is focusing on TCP, this is a generic tunneling problem, 
	so softwire might be a better place. 

	Fred: go talk to chairs of pmtud and chairs of softwire if they
want to take it. 
	If this remains an issue, go back to v6ops and we will see with
AD what to do