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 ----- Original Message ----- From: "Brian E Carpenter" <[EMAIL PROTECTED]> To: "JORDI PALET MARTINEZ" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, July 17, 2003 11:15 AM Subject: Re: Fw: avoiding NAT with IPv6 > 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 > > JORDI PALET MARTINEZ wrote: > > > > 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 PROTECTED]> > > To: <[EMAIL PROTECTED]> > > 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 PROTECTED] > > > -------------------------------------------------------------------- > > > > > > > > > ***************************** > > > 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 PROTECTED] > -------------------------------------------------------------------- > ***************************** 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 PROTECTED] --------------------------------------------------------------------
