Follow-up work on NAT-PT

"Olaf M. Kolkman" <olaf@NLnetLabs.nl> Wed, 10 October 2007 19:39 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhP8-0000YE-86; Wed, 10 Oct 2007 15:39:38 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhP5-0000Td-SD; Wed, 10 Oct 2007 15:39:35 -0400
Received: from open.nlnetlabs.nl ([213.154.224.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfhP5-0008CA-A5; Wed, 10 Oct 2007 15:39:35 -0400
Received: from [127.0.0.1] (open.nlnetlabs.nl [213.154.224.1]) by open.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id l9AJYCA4034247; Wed, 10 Oct 2007 21:34:12 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl)
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <5FCD348C-5927-4F18-A002-0E3BF21ED5F4@NLnetLabs.nl>
From: "Olaf M. Kolkman" <olaf@NLnetLabs.nl>
Date: Wed, 10 Oct 2007 21:34:10 +0200
To: The Internet Engineering Steering Group <iesg@ietf.org>
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
X-Mailer: Apple Mail (2.752.3)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 10 Oct 2007 21:34:12 +0200 (CEST)
X-Spam-Status: No, score=-104.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.3
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on open.nlnetlabs.nl
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: IAB IAB <iab@ietf.org>, IETF@ietf.org
Subject: Follow-up work on NAT-PT
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1807812316=="
Errors-To: ietf-bounces@ietf.org


Dear Colleagues,

The IETF has previously standardized NAT-PT as a means of  
intercommunication by packet translation at the Internet layer.  
However subsequent analysis revealed a number of issues with NAT-PT  
that make it a poor choice for a general purpose interconnection  
mechanism.  The IESG recently approved RFC 4966 which states:

    Although the [RFC2766] form of packet translation is not generally
    applicable, it is likely that in some circumstances a node that can
    only support IPv4 will need to communicate with a node that can only
    support IPv6; this needs a translation mechanism of some kind.
    Although this may be better carried out by an application-level  
proxy
    or transport-layer translator, there may still be scenarios in which
    a revised, possibly restricted version of NAT-PT can be a suitable
    solution; accordingly, this document recommends that the IETF should
    reclassify RFC 2766 from Proposed Standard to Historic status to
    avoid it from being used in inappropriate scenarios while any
    replacement is developed.


As noted in the approved text quoted above, there may still be  
scenarios in which a revised, possibly restricted version of NAT-PT  
may be appropriate.

For example, one such scenario may be increasingly likely given the  
current rate of consumption of IPv4 address space.  Namely, there may  
be legacy IPv4-only hosts in one part of the Internet that want to  
talk to dual-stack hosts in another part of the Internet that do not  
have public IPv4 addresses.  The servers follow today's  
recommendation to be dual-stack, but the scenario still does not  
work, therefore the general recommendation that servers be dual-stack  
is clearly  not sufficient.

Furthermore, classic v4-v4 NAT is also not sufficient for this  
scenario.  For example, one cannot put multiple web servers behind  
the same classic v4-v4 NAT since web browsing uses port 80, and the  
NAT has fewer public IP addresses than the number of servers behind  
it or else the NAT wouldn't be needed.

While the IETF has reclassified RFC 2766 as Historic, up to now there  
has been no replacement to RFC 2766 for such scenarios.  The IAB note  
that the IESG has now begun discussion on what work is needed for  
transitioning to IPv6 and where it should be done, and the IAB  
encourages the IESG to strongly consider the scenario outlined above  
when chartering IETF work.


-- The IAB



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf