Subject: avoiding NAT with IPv6

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 20 Mar 2003 12:02:45 +0100

After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-)

We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could
support this are:

1) Clearly show the advantages of end-to-end and no NAT model.
2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any
interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the
manufacturers to avoid supporting NATs.
3) Indicate that if someone wants to keep using NAT, should do it with IPv4.

I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link
deprecation ?

Regards,
Jordi

*****************************
Madrid 2003 Global IPv6 Summit
12-14 May 2003 - Register at:
http://www.ipv6-es.com

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2003 22:39:59 +0100

I'd vote for a MUST NOT in node requirements, if we can find a suitable
phrasing. It may well be violated by vendors, but it makes the situation
unambiguous.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Mar 2003 22:25:06 +0000

Brian,

If the phrasing focuses on rewriting of the source address, then we do
not preclude use of fec0::/10 for disconnected networks, router zeroconf,
or elsewhere.     We just say "IPv6 nodes MUST NOT rewrite IPv6 source
addresses when processing packets".   

As Pekka said, fec0::/10 need not be blackholed - it can be treated as
a global address instead with no special processing.

Clearly we do not want NAT, but we cannot ban it as such or stop vendors
providing what customers want.

However, we also still have to be realistic in enabling ad-hoc or 
intermittently connected networks, so I like the idea of discouraging the
functionality in products (even without site-locals, people will pick
address blocks to use, and we may see leakage of "hijacked" addresses and 
all manner of problems as a result...)

Still, I guess this morning's vote will focus minds :)

Tim

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 20 Mar 2003 14:50:00 +0100

Sorry, I don't agree: Yes we can STOP vendors. If they don't match the document, they will not be complaint with the RFC, and thus
pass interoperability/conformance test.

This is the same way we ask them to implement things. This time we ask them NOT to implement it.

Jordi

---

From: Quality Quorum <[email-masked]>
Date: Thu, 20 Mar 2003 20:05:33 -0500

On Thu, 20 Mar 2003, JORDI PALET MARTINEZ wrote:

> We know that the people will do it anyway, but we must do an effort
> to avoid is as much as possible, and some ideas that could
> support this are:

IETF is big and strong, market[lace is  much bigger and much stronger, in
all previous collisions with market IETF did not fare well.

Note - I am note arguing that NAT will win - my point is that if people
want it the resistance is futile.

> I'm not sure if the rest agree and what is the correct document to say this,
> may be as part of the changes for the local-link
> deprecation ?
>
> Regards,
> Jordi

Thanks,

Aleksey

BTW, I prepared a draft which spells out NAT6, it is absolutely trivial
thing compaing to NAT4, so if somebody would want it, they would not
need any permissions.

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 20 Mar 2003 17:21:15 -0800

I think this may be looking at the problem in the wrong way. The one 
compelling reason to get IPv6, in my opinion, is because it restores 
the end to end connectivity. IPv6 has enough addresses and ISP can give 
me my own block that I can assign to various devices in my apartment. 
The compelling part of IPv6 is that eliminates the need for me to have 
a NAT. If it weren't for NAT, Ipv4 works well enough, and we don't need 
IPv6. I would expect that the killer applications for IPv6 will be the 
ones that take advantage of IPv6's end to end connectivity. If some 
bozo does try to implement a NAT for IPv6, it will break those 
applications that make IPv6 compelling.

As an implementor of certain bits of software shipping with a 
mainstream operating system, I will do my part to make sure that no NAT 
traversal solutions for various pieces work with IPv6. I've recently 
been working on IPSec NAT Traversal. The spec notes how the protocol 
can detect and work around NATs on IPv4 and IPv6. Our implementation 
intentionally does not support NAT traversal over IPv6. If we can 
eliminate all of the gross hacks to make software work with NATs in the 
IPv6 versions, we could create a world in which a NAT can not be 
deployed because it breaks too much stuff. A vendor could not sell an 
IPv6 NAT in to such a world.

-josh

On Thursday, March 20, 2003, at 5:05PM, Quality Quorum wrote:

>> After the today's decision with site local, is clear to me that we 
>> don't
>> want to have NAT happening again ;-)
>>
>> 2) Have the specs indicating that an IPv6 node (host/router, 
>> whatever) MUST NOT support NAT or equivalent mechanisms. Any
>> interoperability/conformance test must fail if you fail to agree with 
>> this specification. This should be a clear sign for the