[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The argument for writing a general purpose NAT for IPv6

james woodyatt writes:
At this point, I'm now persuaded that having a proxy remote from the filtering router will require the path between them to use some kind of encapsulation that looks like a routing extension header. I'm still convinced that type code zero is the *wrong* one, but whatever... (at the diversion point, on the return path from the proxy, the source address needs to be rewritten to match the real destination, not the proxy, and normal routing extension header processing doesn't do that.) I agree I'm guilty of a poor choice in words. The IETF has defined a way to scribble on the destination addresses in IPv6 headers, and despite my long habit of calling that behavior by the name "network address translation," I should stop calling it that because, with IPv6, there is only one address realm involved. Of course, I do need a way to scribble on source addresses as well as destination addresses...
I admit that I have not read the full document, but the following abstract seems to address some of your concerns by creating an overlay that would be used to address application level needs: ----------Forwarded message ---------- 
Date: Fri, 27 Apr 2007 14:20:16 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Internet Area <int-area@ietf.org> 
Subject: [Int-area] FW: RFC 4843 on An IPv6 Prefix for Overlay Routable
Cryptographic Hash Identifiers (ORCHID)
A new Request for Comments is now available in online RFC libraries. RFC 4843 Title: An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) Author: P. Nikander, J. Laganier, 
                    F. Dupont
        Status:     Experimental
        Date:       April 2007
Mailbox: pekka.nikander@nomadiclab.com, julien.ietf@laposte.net, Francis.Dupont@fdupont.fr 
        Pages:      14
        Characters: 32483
Updates/Obsoletes/SeeAlso: None I-D Tag: draft-laganier-ipv6-khi-07.txt URL: http://www.rfc-editor.org/rfc/rfc4843.txt 
This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID) as a new, experimental class of IPv6-address-
like identifiers.  These identifiers are intended to be used as
endpoint identifiers at applications and Application Programming
Interfaces (API) and not as identifiers for network location at the
IP layer, i.e., locators.  They are designed to appear as application
layer entities and at the existing IPv6 APIs, but they should not
appear in actual IPv6 headers.  To make them more like vanilla IPv6
addresses, they are expected to be routable at an overlay level.
Consequently, while they are considered non-routable addresses from
the IPv6 layer point-of-view, all existing IPv6 applications are
expected to be able to use them in a manner compatible with current
IPv6 addresses. 
This document requests IANA to allocate a temporary prefix out of the
IPv6 addressing space for Overlay Routable Cryptographic Hash
Identifiers.  By default, the prefix will be returned to IANA in
2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.
EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. 
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.