Subject: RE: Stupid NAT tricks and how to stop them.

From: "Michel Py" <[email-masked]>
Date: Tue, 28 Mar 2006 01:54:52 -0800

> Tim Chown wrote:
> If you deploy IPv6 NAT, you may as well stay with IPv4.

Tim,

You're the one who convinced me some three years ago that there will be
IPv6 NAT no matter what, what's the message here?
 
> See also
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt

Remember: Users don't read drafts/RFCs.

> We have deployed IPv6 in our enterprise (throughout).

Could you have done it if you did not have the
research dollars^H^H^H^H pounds?

> Artur Hecker wrote:
> the (static) statement that "90% of phones are
> analog" seems very wrong to me.

My bad, I should have said land lines.

> Hallam-Baker, Phillip wrote:
> I have never seen a coherent, rational argument as to why
> the network numbering on my internal network should be the
> same as the network numbering on the Internet.

Phillip, there a few (such as: NAT typically requires hard state, which
is a pain to replicate if there is more than one edge router). NAT is
not completely evil, but it's far from being clean. Pretending that
there are no good reasons against NAT is going to achieve the same as
trying to eliminate it: nothing.

> People will still want to do NAT on IPv6.

Yes, and since site-locals have been deprecated they will also hijack an
unallocated block of addresses to use as private, same what happened
prior to RFC 1597 for the very same reasons (difficult/pricey to get
PI).

> Austin Schutz wrote:
> ...that opportunity may be to enhance NAT rather than throw it away

Austin, this has been tried many times and never went anywhere. As there
are no changes in the reasons it has failed in the past I don't see how
this could make it this time.

>> Michel Py wrote:
>> A protocol that would be only v4 with more bits in the first place, 
>> with routers / NAT boxes that would pad/unpad extra zeroes (also 
>> including extra TBD fields). As this would be 100% compatible with v4

>> this could be deployed without too many headaches.

> Keith Moore wrote:
> huh?  there is no way to make a protocol that can address more hosts
> than v4, that is 100% compatible with v4.  and there's no good way to
> divide up the net into v4 enclaves and v6 enclaves because the
> applications that need v6 addressing don't fit neatly into enclaves.

As long as you don't use the extra bits, no problem. IPv4 on one side,
IPv4+ on the other; when going from v4 to v4+ add a bunch of zeroes,
when going to v4+ to v4 remove a bunch of zeroes. Initially it's a total
waste of bits, but silicon is cheap these days.

When people will begin to scream bloody murder to use the extended bits
(because v4 is getting near exhaustion) the infrastructure could be
already in place, and then the pressure will be on software developers
to recode their stuff with 128-bit addresses. When that has happened,
then we can make use of all these reserved fields for better purposes,
and possibly allocate PI to everybody which is another pre-requisite to
get rid of NAT.

Michel.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 28 Mar 2006 12:13:56 +0200

[cc trimmed]

> prior to RFC 1597 for the very same reasons (difficult/pricey to get

I guess you missed out on:
http://www.iana.org/assignments/ipv6-address-space

FC00::/7              Unique Local Unicast    [RFC4193]

You can use that to generate your local prefix and it is much better
than site-locals as the chance of collisions is fairly low. And as you
know you simply don't want to do a NAT from 10/8 to 10/8 at one point in
time when two big companies merge ;)

> >> this could be deployed without too many headaches.
(I almost got lost in the attribution level here)

Then why is IPv6 causing so many headaches? As one can see 6to4 is
mostly making up your IPv4+ address from the IPv4 one by doing:
 2002 + <ipv4 address> + padding bytes ;)

Ah, of course, one actually need to upgrade most of the internal stuff
and upgrade all the applications, convince managers, get money to do it,
do training.... etc...

Also for the rest of the thread, overlaying IPv6 over IPv4: RFC4380
Which is more or less a p2p overlay network using IPv6 as the addressing
part and thus leveraging a lot of applications already.

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Mar 2006 13:08:48 +0100

> IPv6 NAT no matter what, what's the message here?

I think there will be IPv6 NAT, because some people will want it.  That
doesn't mean it's rational to deploy it :)
  
> Remember: Users don't read drafts/RFCs.

And users don't walk into PC World and say 'I'd like a NAT router for my
home network please'.   They probably ask for a broadband modem, or 
something that doesn't specify NAT.
 
> research dollars^H^H^H^H pounds?

While we ironed out many issues with research funding assistance in 6NET,
I would say the deployment we have now could be done as part of a natural
evolutionary procurement process.   The 'cost' is real terms is not that
high.  We have had to invest time in updating OSS-type elements, but much
of the rest comes 'out of the box'.   I guess we would have had some
training costs as a 'normal' enterprise, but we've helped address that in
the academic community by running hands-on IPv6 workshops (just as the
Internet2 people do for their community).
 
> trying to eliminate it: nothing.

I note Phillip's extremes of view on IPv6 and DNSSEC.  It's interesting
to compare how critical these two elements are, and his views on them.
 
> prior to RFC 1597 for the very same reasons (difficult/pricey to get

There are now ULAs, http://www.ietf.org/rfc/rfc4193.txt.
 
> and possibly allocate PI to everybody which is another pre-requisite to

And there's always IPv8 ;)

-- 
Tim/::1

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Mar 2006 22:51:47 +0200

> IPv6 NAT no matter what, what's the message here?

I've travelled to this strange land where there is IPv6 and it's  
NATed... Some enterprising souls apparently took it upon themselves  
to build IPv6 support into a firewalling package that (as so many  
firewalls do) supports NAT. With the result that if you know how to  
enable this, you can make it do IPv6 NAT. Simple client-server  
protocols such as HTTP worked without incident as expected. However,  
I also tried FTP, which really isn't that bad as NAT-breaking  
protocols go. It didn't work because the server saw an illegal EPRT  
request. In IPv4 with NAT that wouldn't have happened because:

1. The FTP client would have used EPSV in order to be NAT-friendly, or
2. The FTP ALG would have intercepted the private address and  
rewritten it

Moral of the story: do IPv6 NAT at your peril. Now of course it's  
possible to argue all of the stuff that makes IPv4 NAT work to the  
degree that it does today can also be added to IPv6, and that is  
true, strictly speaking. But will the vendors bother, and will the  
customers require it? I don't think so. As Tim said: if you can live  
with NAT, why not stay with IPv4? That saves you several headaches  
and it only costs you a few IPv6 nice-to-haves such as stateless  
autoconf that haven't been able to get people to IPv6 anyway.

> My bad, I should have said land lines.

The interesting thing is that even though ISDN doesn't amount to much  
in the US and it's mainly used for businesses in Europe, GSM which is  
the biggest mobile phone technology, uses ISDN Q.9xx signalling, so  
ISDN was never a waste of time.

>> People will still want to do NAT on IPv6.

Not enough to make it work well enough.

> unallocated block of addresses to use as private,

You can still use FEC0::/10 even though the special case handling  
will be removed from future implementations and there are unique site  
locals for which there is a specific hijacking methodology that  
minimizes the dreaded ambiguity of private space.

> and possibly allocate PI to everybody which is another pre- 

The trouble is that if you use IPv4-compatible IPv6 addresses (in the  
loose sense of the word, not thinking of any RFC) for instance by  
having the first 96 bits of the IPv6 be zero, you get to translate  
between v6 and v4 transparently, but you still never get to use  
addresses that are longer than 32 bits, so the only thing it gains  
you is simpler IP processing (no header checksum etc) but not more  
address space. For this, you need a mechanism so that the initiator  
of the communication knows that the recipient supports longer  
addresses. That's what we do with AAAA records in the DNS today.  
There are no shortcuts here.

BTW, Michel, you said you were about to return from the dark side in  
true Star Wars fashion. What gives?  :-)

---

From: "Fortenberry, Thaddeus" <[email-masked]>
Date: Tue, 28 Mar 2006 16:55:22 -0500

>> And there's always IPv8...

Wasn't that IPv9 fun?  ;)

-Thaddeus

-----Original Message-----
From: Tim Chown [mailto:[email-masked]] 
Sent: Dienstag, 28. März 2006 07:09
To: [email-masked]
Subject: Re: Stupid NAT tricks and how to stop them.

  

 

 

-- 
Tim/::1