Subject: Fw: avoiding NAT with IPv6

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 17 Jul 2003 10:59:47 +0200

I feel that we need to "revive" this thread.

If we include, for example, in the node-requirements, that one of the IPv6 node requirements is to "avoid" the support of NAT or any
other kind of address translation mechanism (I'm not suggesting exactly this way to say it), any vendor that do that, can be
"banned" by the community and the Interop/Conformance test, because he is not complying with the specs.

Some still will do that, but we can then tell the network managers and users, that the product is NOT IETF complaint.

Regards,
Jordi

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 20, 2003 1:02 PM
Subject: avoiding NAT with IPv6

> 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]
> --------------------------------------------------------------------
>
>
> *****************************
> Madrid 2003 Global IPv6 Summit
> 12-14 May 2003 - Register at:
> http://www.ipv6-es.com
>
>

*****************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on-line 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, 17 Jul 2003 11:15:53 +0200

I'm very sympathetic, but I think it is conditioned by
what we are discussing today - having an agreed replacement
for the ambiguous FEC0:: space (which is an open invitation
to NAT). Once we have such a thing, we can make positive
requirements for exploiting it that make NAT look silly.

   Brian

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 17 Jul 2003 11:29:19 +0200

IETF is slow, and we know it.

We should work in parallel as much as possible, and I feel we have an opportunity now with the node-requirements.

I think is much better that the 2nd option a BCP, as this will not so easy for conformance test ...

Regards,
Jordi

---

From: "EricLKlein" <[email-masked]>
Date: Thu, 17 Jul 2003 14:49:48 +0300

As we still have not provided a replacement for the FEC0:: addresses I would
be hesitant to start trying to make rules about what is allowed and not
allowed until a replacement is defined.

As it is the WG is spending a lot of time debating items that make a lot of
sense rather than offering reasonable alternatives.

As I understand it we have removed site locals (FEC0::) after they were
included in an RFC and implemented in many places, so now it was recommended
to not assign this range to prevent conflicts (which makes it a de facto
usable site local). Lets not make the same mistake.

A best practices or RFC that gives a solution is better than trying to tell
people that is bad and not supported so if you do it you are not compliant.

If NAT is so bad, then offer an alternative not a critisim. Network Admins.
have gotten in the habit of blocking reall addresses from the public network
and will need a good altnative before they stop doing it, so let's find an
alternative.