Re: [v4v6interim] [46translation] [BEHAVE] Proposal for new BEHAVE charter

The real or perceived reasons to deploy NAT are covered in RFC 4864,
so yes there's more than were listed in below.

However the point of that RFC is to show that NAT is not the only
way to get those benefits.  It contains at least existence proofs
that benefits can be obtained with some other solution (not to
say that an example listed is necessarily the only or even the best
alternative).

-Dave

> -----Original Message-----
> From: 46translation-bounces@employees.org [mailto:46translation-
> bounces@employees.org] On Behalf Of TJ
> Sent: Monday, October 20, 2008 12:30 PM
> To: 46translation@employees.org; v4v6interim@ietf.org; 'Behave WG'
> Subject: Re: [46translation] [v4v6interim] [BEHAVE] Proposal for new
> BEHAVE charter
>
>
> I am not entirely excited about this conversation, but WRT
>         "3/ topology hiding"
>
> NAT66 would accomplish something.  While it doesn't "hide" the specific
> host
> _right now_, it does hide the underlying topology (no 1:1 correlation
> of
> outside and inside addresses / network architecture) as well as hide
> the
> specific host as time moves forward.
>
>
>
> ... hoping that if it does get defined it gets very little use ...
> /TJ
>
>
> >-----Original Message-----
> >From: v4v6interim-bounces@ietf.org [mailto:v4v6interim-
> bounces@ietf.org] On
> >Behalf Of Rémi Denis-Courmont
> >Sent: Monday, October 20, 2008 6:58 AM
> >To: 46translation@employees.org
> >Cc: v4v6interim@ietf.org; 'Behave WG'
> >Subject: Re: [v4v6interim] [46translation] [BEHAVE] Proposal for new
> BEHAVE
> >charter
> >
> >On Monday 20 October 2008 13:37:05 ext Iljitsch van Beijnum, you
> wrote:
> >> Interestingly, I did a small survey about whether people _expect_
> >> there to be NAT66 in the future and the majority said "yes".
> >>
> >> On the one hand we can do nothing and if all goes well there will be
> >> no IPv6 NAT so we're all happy because not doing anything made the
> >> right thing happen. (Although I've used a NAT66 implementation
> myself
> >> some years back, so there is at least one out there.)
> >>
> >> But if we do nothing, we run the risk that someone will do a quick
> >> search and replace on their NAT44 code and create a port overloading
> >> NAT66. The port overloading is 90% of the harmful stuff that NAT
> boxes
> >> do.
> >>
> >> What we could do is come up with a stateless, transport-agnostic 1-
> >> to-1 NAT66 spec so we at least avoid the port overloading and
> nothing
> >> much breaks except referrals.
> >
> >I share your analysis that, _assuming_ we have NAT66, it should be
> >transport-agnostic. IPv6 has a large enough address space, and we are
> >painfully aware of the problems of transport-dependent NAT(44).
> >
> >However, when I look at the reasons for deploying NAT:
> >1/ address space shortage
> >2/ inbound firewalling
> >3/ topology hiding
> >4/ prefix delegation "bypass"
> >
> >(1) is a non-issue for IPv6. (2) is solved with stateful firewalling
> and
> >does not require NAT. 1:1 NAT fails to solve (3) as it does hide the
> >subnetting scheme, but fails to hide individual hosts. This leaves
> only
> (4).
> >Did I miss anything?
> >
> >I still believe we will see NAT66. Not because it's immediately
> useful.
> >Rather because someone will figure out it's easy to adapt NAT44 code
> to do
> >NAT66.
> >For instance, much of the Linux Netfilter framework has become IP
> version-
> >independent lately, with NAT being the only one big remaining IPv4-
> specific
> >chunk.
> >
> >
> >
> >I guess only time would tell whether a NAT66 1:1 spec would help
> prevent
> >such the transport-dependent NAT66 being _deployed_. It cannot hurt to
> write
> >that spec, I suppose. In any case, the abomination will be
> _implemented_
> :-(
> >It is too natural/easy/tempting.
> >
> >--
> >Rémi Denis-Courmont
> >Maemo Software, Nokia Devices R&D
> >_______________________________________________
> >v4v6interim mailing list
> >v4v6interim@ietf.org
> >https://www.ietf.org/mailman/listinfo/v4v6interim
>
> _______________________________________________
> 46translation mailing list
> 46translation@employees.org
> https://www.employees.org/mailman/listinfo/46translation

_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim