Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for next w eek's v6ops discussion

From: Senthil Sivakumar <[email-masked]>
Date: Fri, 05 Nov 2004 11:33:16 -0800

At 07:55 PM 11/5/2004 +0100, Elwyn Davies wrote:
>This email summarises the discussions that have taken place on the list
>since the publication of  draft-aoun-v6ops-natpt-deprecate-00 and is
>intended to servce as a basis for the debate at IETF-61.  I intend to
>quickly reiterate these points (as modified by mailing list input between
>now and then) at the meeting before we discuss how to proceed.
>
>1. Document content: The issues with NA(P)T-PT:
>- The general view appeared to be that the issues were pretty much complete
>and accurate.  I have some detailed comments from Tony Hain but
>unfortunately these relate to a pre-publication version of the draft and I
>need to go back over the points with him to determine which of them are
>still valid, as I think most of them had already been addressed.
>- There was some discussion over whether the issues which NAT-PT and NAT
>share should be duplicated or indeed be called out at all in this document.
>         o Part of the point is that if we can live with these points in
>respect of NAT,
>         these are not necessarily reasons to deprecate NAT-PT.  NAT solves
>an ongoing
>         problem in IPv4 whereas NAT-PT is intended to be a transition aid.
>On
>         the one hand we may feel it is easier to live with some issues if
>the mechanism
>         is not with us for ever, but on the other should we use a mechanism
>that has
>         all these issues at all?

It depends on what the needs of the scenario is. For example, e2e security does
not work well but does some one care if they does not need security. Should 
that
be a reason to deprecate ? Documenting and noting the issues that are common
to NAT and NAT-PT are fine but using them as the reasons to deprecate NAT-PT
does not make sense to me. The reasons to deprecate NAT-PT should be the
reasons that are unique to NAT-PT.

>       o Also these issues will apply to *any* translation mechanism rather
>than just
>         the SIIT + DNS-ALG version which we the document is trying to
>justify
>         deprecating
>My view is that the issues should be called out in the document, but we
>should make it more clear that they will apply to any translation mechanism
>as well.  I don't think it is good to have to point to a lot of v4 specific
>documents which cover other ground as well, particularly if we end up not
>deprecating NAT-PT completely.  Views are sought.

I agree.

>- How to handle the connection to all the prior drafts which are (partially)
>summarised in this document.  Is the current approach correct?

I am not very sure what new this document has brought out that the
other documents did not. The only section I see different from the previous
drafts is that there is an analysis section that states we recommend to
deprecate it for all of the above reasons.

>2. Use Cases for NAT-PT and other translation mechanisms
>- A number of use cases where NAT-PT is being used (whether appropriately or
>not) or is thought to be a possible solution were discussed. More input on
>other cases and details of identified cases has been asked for and is still
>wanted in some cases - please send in detailed info if possible.

As long as we can agree to the fact that there will be nodes/networks
that are v6only/v4 only and there will be a need for these nodes/networks
to talk to each other (your military scenario case is an example, wont be
the first and last), we will need a translation mechanism. You have also
mentioned that many of the issues identified is not specific to NAT-PT but
general translation issues. So it does not matter if we deprecate this and
write a brand new translation mechanism we will still inherit all the general
issues.

>- In some of these cases it looks as if NAT-PT is being used to solve a
>problem which it was not really intended (e.g. using back-to-back NAT-PTs to
>provide connection between (private) IPv4 domains across an IPv6 only
>backbone). I believe that NAT-PT was intended mainly to solve the problem of
>connecting an IPv4 only host/domain to an IPv6 only host/domain.  The
>back-to-back NAT-PT solution seems to be better covered by a 4 in 6
>tunneling solution.  Of course many of the issues called out in the draft do
>not apply in this situation because only the IP header needs translating and
>e2e IPsec will work because the packet is restored to its original form when
>it reaches the other end.  ALG's would not be required.  I am not clear that
>the standard form of the DNS-ALG proposed in 2766 applies to this use case.
>- Front ending a legacy v4 only server: This is clearly a good use for a
>straightforward translator, but there is little or no need for the
>generalised DNS-ALG in this case and the translator would generally have to
>handle a limited set of protocols and a limited set of v4 addresses defined
>by the server it was front ending.  This is not an application for the full
>generality of 2766 but I think we have to define a reduced version for this
>case.  Whether it is still called NAT-PT is a moot point.

Right, again this translator *will* be a subset of NAT-PT with all the issues
that a translator will have. (minus DNS-ALG specific issues).

>- The military case: I call it the military case but there are other related
>applications which have the same problem to solve.  As I see it the scenario
>involves a network of (newly created/adapted) v6 only devices that are
>unable to run dual stack because of resource constraints either in the
>devices or in the network connections.  These devices will, at least
>transiently, need to communicate with v4 devices in other domains (which
>have to remain v4 only for the same reasons of resource constraint).  The
>question is whether NAT-PT is the best technology to connect the domains.
>One question in my mind for the military case: The military specifically
>wanted to avoid putting NAT boxes in their  networks for good cause (single
>points of failure, routing constraints, security attack nexuses) - so why
>should they now want NAT-PT in their networks? On the other hand there will
>be at least some occasions when they have to work across domains during the
>transition, but ALGs/proxies may be a better solution given that these
>devices are likely to have a relatively limited set of applications.  There
>are also issues with using DNS in this sort of environment - it is a 'high
>availability/mobility' area and there may be worries about DNS caching
>lifetimes.  More input is needed here.

I think we could argue for ever over proxies vs NAT-PT, there is no clear 
documentation
that exists (atleast I am not aware of any), that concludes one way or the 
other.

>- 3GPP wireless: As mentioned in the draft, it may be better to consider
>using 4 in 6 or 6 in 4 tunnels to allow a single PDP context to carry both
>protocols.  This may require updates to RFC3314. More work is needed to
>ensure that header compression can reduce the impact on scarce bandwidth
>across the air interface (an extension of ROHC should be possible to cover
>tunnel headers).
>
>Do these cases cover all the expected scenarios?  Is the analysis correct?
>
>3. NAT-PT vs proxies
>Are proxies a better solution for most/all cases?  Either proxies or NAT-PT
>need to be extended to cope with new protocols in most cases.  Proxies may
>be more scalable (not all in the same box) and more adaptable to user needs
>(not dependent on a single vendor to do NAT-PT ALG upgrades). The most
>frequently used protocols today are HTTP, POP, SMTP, FTP and SSH: proxies
>are available for the first four - SSH is more problematic but is mostly a
>tool for power users (who are more likely to have dual stack support) and so
>SSH support may not be so important.
>
>Way forwards:
>- Tune the details
>- Show real examples, if any, where translators will really give better
>performance than proxies and are really vital. Make sure that backwards
>compatibility is fully considered, taking into account availability and
>migration of terminals from v4 to dual-stack/v6 plus the availability of
>tunnel support.
>- Either:
>    o Deprecate NAT-PT altogther and write other drafts with 'offspring of
>NAT-PT' to
>      cover the specialised use cases where a translator is useful, or

Same point as above, I am not sure how it would be free of all the translation
related issues.

>    o Turn this into a new applicability draft recommending only a very
>limited set
>      of uses, and produce modifications to cater for some of the specialised
>use cases.

I think that is what the previous applicability draft did.

>- Produce some recommendations on proxies and look to see which other
>proxies need specification (if any).
>- Ensure there are suitable specification(s) for 4 in 6 tunneling
>(configured, auto).
>- Ensure that the various scenario drafts recommend the 'right' solution.

Thanks
Senthil

>Regards,
>Elwyn
>
>----------------------------------------------------------------------------
>------
>
>Elwyn B Davies
>
>         Routing and Addressing Strategy Prime & IPv6 Core Team Leader
>         CTO Office, Portfolio Integration               Solutions Ready
>
>
>         Nortel Networks plc                     Email:
>[email-masked]
>         Harlow Laboratories                             ESN
>6-742-5498
>         London Road, Harlow,                            Direct Line
>+44-1279-405498
>         Essex, CM17 9NA, UK                     Fax
>+44-1279-402047
>         Registered Office:                      Maidenhead Office Park,
>Westacott Way,
>         Company No. 3937799                     Maidenhead, Berkshire, SSL6
>3QH
>----------------------------------------------------------------------------
>This message may contain information proprietary to Nortel Networks plc so
>any
>unauthorised disclosure, copying or distribution of its contents is strictly
>prohibited.
>----------------------------------------------------------------------------
>"The Folly is mostly mine"
>and the opinions are mine and not those of my employer.
>============================================================================
>======

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Nov 2004 16:49:39 -0800

> write a brand new translation mechanism we will still inherit all the 

I think this is the crux of the issue. NAT-PT is not just NAT for v4 to 
v6.
Because of its design, it adds new issue to the plate of NAT.

IMHO, the way forward is not to pretend any translation v6->v4 is bad, 
but to declare
that the specific method described in RFC2766 is problematic and thus 
should be deprecated.

If real need for v6 to v4 (and vice versa) emerge, it will be time to 
look again at the issue,
maybe resurrect my NAT64 and NAT46 proposals or design something else.

	- Alain.

---

From: "EricLKlein" <[email-masked]>
Date: Sat, 6 Nov 2004 10:22:59 +0200

From: "Alain Durand"
> maybe resurrect my NAT64 and NAT46 proposals or design something else.

I tend to disagree.

To borrow somthing Tony said in another thread:
"The IETF needs to be about developing a
growing and vibrant Internet, so resisting the inevitable change is counter
productive. In that light, it is time to remove the special status of
separate working groups for IPv6, and make it the default IP protocol for
all IETF work. "

Since we as a WG have decided to depriciate NAT and not support (allow) it
into IPv6 I think it is time that we just say that it is not supported and
start killing it off once and for all. Otherwise we will always have to work
the old NAT space and functions into the IPv6 space.

I understand the need for a transition mechanisim, but I do not feel that it
is strongly stated enough the NAT is out. Not even the why you don't need
NAT draft (draft-vandevelde-v6ops-nap-00) tries to do that.

We need to start pushing the new standards out to the market ASAP, or we
will be trying to back fix all sorts of propritary fixes (like the DHCPv6
issue) and will run out of addresses in the existing space ling before we
get real acceptance of IPv6.

Eric

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 8 Nov 2004 12:32:12 -0800

FWIW: like it or not we need a function that deals with IPv6-only devices
talking to IPv4-only legacy devices. That is the useful function of NAT-PT
and it works as well as IPv4-IPv4 nat as long as it is parked as close to
the IPv4-only device as possible. The DNS-ALG shouldn't be there because it
decreases the overall network value by confusing the IPv6 device. As such
the deprecate NAT-PT / NAT-PTbis effort needs to simply focus on removing
the DNS cruft. 

Legislating how people run their networks is not the job of the IETF.
Documenting how to get their job done efficiently is something the IETF can
and should do as creator of the tool set. The most we can do is document the
failings of nat as a technology, and refuse to standardize on an IPv6-IPv6
version. To some degree the NAP document is specifically trying to make the
case that mangling headers is not required once IPv4 is out of the
environment, and that all of the 'other marketed uses' of the technology are
possible using IPv6. If there are missing uses, or clearer language that
will make the case, please send text. 

Tony 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of EricLKlein
> Sent: Saturday, November 06, 2004 12:23 AM
> To: [email-masked]
> Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for
> next w eek's v6ops discussion
> 
> From: "Alain Durand"