Actually, what might be reasonable is for the next revision of RFC 2460 to contain a list of header fields that are mutable end to end (such as the hop limit and the traffic class) plus a statement that all other header fields MUST be delivered unchanged. Then a future version of node requirements can cite this.
None of which will stop NAT salespersons. Only a more attractive carrot than NAT will do that. Brian JORDI PALET MARTINEZ wrote: > > John, > > Yes, probably you're right. Let's then put it in another way (the positive one): > > An IPv6 node (having forwarding capability for packets for what isn't the end > destination), MUST NOT translate the source or > destination addresses. > > We can add part of my previous text to explain this. > > Regards, > Jordi > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, July 17, 2003 4:17 PM > Subject: RE: avoiding NAT with IPv6 > > > Hi Jordi, > > > > > I mean, if a vendor don't pass a given RFC in a > > > conformance/interoperability, because they do NAT, then a lot of customers (ISPs, > > > Telcos) will not purchase it, because that's what the market > > > do most of the time. And this is a "market" enforcement ... > > > > Is this true, there are a number of RFCs that tell about the bad > > things NATs do, but NATs are not slowing down at all. > > > > http://www.ietf.org/rfc/rfc2993.txt?number=2993 > > > > http://www.ietf.org/rfc/rfc3027.txt?number=3027 > > > > http://www.ietf.org/rfc/rfc3424.txt?number=3424 > > > > > What about something like: > > > > > > IPv6 has enough addressing space that allows avoid the need > > > of any kind of address translation, that is considered harmful according > > > [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind > > > of address translation. > > > > A purely procedural problem exists - the above drafts are > > information, so I don't think they can be used as a justfication > > for use of MUST NOT in this document. Someone correct me if I am > > wrong. > > > > John -------------------------------------------------------------------- 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] --------------------------------------------------------------------
