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

Re: Fwd: I-D Action:draft-van-beijnum-modified-nat-pt-02.txt

Iljitsch van Beijnum wrote:

Hi,

I've updated my modified NAT-PT draft (again). It now includes:
- changes to NAT-PT in the form of using A records directly rather than syntetic AAAA records so no DNS issues - synthetic RFC 1918 source address coupled with the above allows for applications to see that they're doing IPv4 rather than IPv6 and that there is NAT involved 
- the above allows for non-IPv6 applications to work
- IPv4-to-IPv6-to-IPv4 translation without double NAT
- a mechanism for IPv6-only hosts to receive incoming sessions from the IPv4-only world
Please note that this is a discussion document, I'm not suggesting that everything in it is adopted as-is.
There were some ideas I floated in reply to Brian Carpenter's SHANTI proposal, which look like they may better fit in with your work - indeed, they look very similar, with one extra feature that allows for additional scaling of any ALGs if they are needed, on a per-port basis. 

Here's the highlights, followed by the rest of my ideas...
Do IPv4-to-IPv6 protocol translation - but now, the extra "twist" - embed the *port* in the IPv6 destination, *above* the IPv4 address. This lets us set up "generic" ALGs, based on covering aggregates for the "special" address space we use for the place where 6-back-to-4 happens. And, we can then set up ALGs on a per-port basis, which are more-specific addresses. And even more fine-grained port+IPv4 ALGs can be set up, e.g. when there is a need to do 4-6-4 for RFC 1918 space.
(rest of quoted stuff details stuff that may or may not be of interest or in-scope for your document) 

Since the host sees IPv4 "natively", no DNS tricks are needed.
There are even a few advanced tricks that can be accomplished, like reverse-port-mapping to request inbound port(s) and possibly inbound port+IPv4 address "reservation". Combined with dynamic DNS, it may be possible to extend the usefulness of a very small number of IPv4 addresses, to support a much larger of "servers" who need reserved ports, although possibly only intermittently. (Think SMTP for hosting, inbound with MX and relay.)
The implementation of things like DHCP (for IPv4) use well-know IPv4 "broadcast" address destination 255.255.255.255. But, having an IPv6 host listen on that address, transmogrified by the mapping including port, means a specific IPv6 address can act as a DHCP server (or relay).
NAT stuff built to handle this has an added advantage - the IPv4 client-side addresses can overlap, since the presumption is that all the hosts already have IPv6 - and can communicate via IPv6. So there would not be any need for support for "tromboned" traffic between pairs of hosts behind this 4-6-4-plus-NAT. The colliding addresses are disambituated in IPv4 by port (assigned by the NAT), and in the NAT back-end by IPv6 address.
There are details to work out, of course. But I think it could be an interesting starting point, which by virtue of presenting an IPv4 interface to the client, avoids most of the NAT-PT issues.
Oh, yeah, one other good thing - there is no requirement that the ALGs or NAT-PT exist on the same network, just that they be reachable via IPv6 natively. So, a small network could point their "ALG default" at an upstream, who then would handle all the NAT-PT stuff (presumably as either a value-add, paid, or bundled service) for access to the V4 Internet. 

Begin forwarded message:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Modified Network Address Translation - Protocol Translation 
    Author(s)       : I. van Beijnum
    Filename        : draft-van-beijnum-modified-nat-pt-02.txt
    Pages           : 16
    Date            : 2007-11-19



A smooth transition from IPv4 to IPv6 requires that either all hosts
are upgraded to dual stack before the first hosts can become IPv6-
only, or that there be some mechanism for IPv6-only hosts to talk to
IPv4-only hosts.  Expecting the former within a reasonable timeframe
isn't realistic, based on current adoption of dual stack combined
with the latest projections for the IPv4 depletion that point to a
date early in the next decade.  And the IETF has recently deprecated
the main mechanism that allows the latter: NAT-PT.
This document proposes modifications to NAT-PT that address the
reasons why the mechanism was deprecated.  This should allow future
deployment of the modified NAT-PT as an IPv4-to-IPv6 transition
mechanism, giving operators the option of running their networks
largely IPv6-only.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txt