Subject: RE: avoiding NAT with IPv6

From: [email-masked]
Date: Thu, 17 Jul 2003 10:41:18 +0100

I don't think this makes much sense. The node requirements doc is the wrong
place to introduce new requirements. More importantly there's no way to
enforce this in conformance testing. I understand the sentiment, but this is
the wrong solution.

Mat.

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[email-masked]]
> Sent: 17 July 2003 11:25
> To: [email-masked]
> Subject: Re: avoiding NAT with IPv6
> 
> 
> Hi John,
> 
> I know this is a difficult topic, and we don't enforce the 
> vendors, but we do "de facto".
> 
> 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 ...
> 
> 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.
> 
> Regards,
> Jordi
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Thursday, July 17, 2003 11:11 AM
> Subject: RE: avoiding NAT with IPv6
> 
> 
> Hi Jordi,
> 
> > 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.
> 
> I feel ambigious about this - avoiding NATs is a good thing, however
> IETF is not a protocol enforcement agency.  Interop & conformance
> testing happens outside of the IETF, so I am not sure this is
> in scope for the IETF.
> 
> Additionally, the WG chairs chartered the Node Requirements work
> to document existing requirements, and I actually don't think
> we have any IPv6 RFCs that have any related statements like
> 'You MUST NOT NAT IPv6' ... so I am unsure how to procede on
> this subject.
> 
> That noted, there are well known RFCs published already on
> the dangers of NATing, so I'm not sure what good it would do
> to put something in the Node Requirements document.
> 
> Finally, I actually don't know what a reasonable requirement
> would be to add to cover this.  If you think you have good text,
> please send it on the mailing list.
> 
> John
> 
> *****************************
> 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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 17 Jul 2003 13:58:06 +0100

> From: BAUDOT Alain FTRD/DMI/CAE
> Sent: 17 July 2003 14:48

> Sure. I just wonder if a /48 at home is really apprpriate.

My /48 is certainly appropriate for my home, and I'm very glad my provider
didn't assume otherwise.

Mat.

---

From: "BAUDOT Alain FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 17 Jul 2003 15:15:33 +0200

> Unless you think we are likely to exhaust the
> 35 trillion /48s quickly, it's entirely appropriate
> (because it keeps things simple).
> 
Agree on simplicity. A fix length is necessary. My concern is just about
the ratio between the /32 and the /something provided to everyone. And
then comes the need of an efficient process enabling to get hundreds of
/32 in order to have a reasonable number of happy customers. 

Alain.

---

From: "BINET David FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 17 Jul 2003 15:30:18 +0200

I agree with Eric.
I don't think the right thing to do is to forbid smth and to recommend to not support some translation mechanism.
If we want customers or end users do not use IPv6NAT, we have to adopt right policies, to enable "NAT assets" by other IPv6 means and maybe better communicate on NAT drawbacks but it seems difficult to forbid NAT and afterwards problem will be solved.
I do think that a right policy consists in not providing /64 to customers even if some mechanism such as ND-proxy maybe can be used to prevent NAT use.

> -----Message d'origine-----
> De : EricLKlein [mailto:[email-masked]]
> Envoyé : jeudi 17 juillet 2003 13:50
> À : [email-masked]
> Objet : Re: Fw: avoiding NAT with IPv6
> 
> 
> 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.
>