[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT-PT: To deprecate or not to deprecate: the question for next w eek's v6ops discussion
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:
elwynd@nortelnetworks.com
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.
============================================================================
======