[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Follow-up work on NAT-PT - a new approach
On 2007-11-10 08:04, Rémi Després wrote:
Brian E Carpenter wrote:
Yet, if it is possible to propose operational solutions without
unnecessary additional layers of complexity, the industry and users
On 2007-11-09 07:22, Rémi Després wrote:
Brian Dickson wrote :
If IPv6 hosts could be kept simple (i.e. unmodified for IPv6 to IPv4
connectivity), that would be a better perspective for IPv6 deployment.
Brian E Carpenter wrote:
The IAB request specifically asks for a solution for IPv6-only
I don't see that.
my analysis of RFC 4966 is that without
adding state in the IPv6 host, most of the problems identified
with NAT-PT cannot be mitigated.
This is the important TECHNICAL point.
A further analysis shows that :
1. Problems identified in RFC 4966 fall in fact into 3 categories.
(a) Related to an Pv6-IPv4 DNS-ALG, if present
(b) Related to fragmentation, if applicable
(c) Identical to IPv4 NATrelated limitations
2. All can be eliminated as follows:
- With my proposal below (as I see it, a straightforward extension of
DNS to make IPv6 to IPv4 connections practical), problems (a) can
See below, but basically that is my comclusion for the SHANTI scenario.
- Limiting IPv6 to IPv4 connections to paths where MTUs are at least
1500 (that of Ethernet) would be acceptable in the real world. Problems
(b) can then disappear.
This is probably realistic but it still means the IPv6 source needs to know
that limitation - SHANTI provides such knowledge to the IPv6 stack.
I can add that in the next version.
- Applications of IPv6 to IPv4 connections can, and for the sake of
simplicity should be limited to that which are available to IPv4 hosts
behind NATs. Thus, problems (c) would disappear.
That's essentially the "don't behave worse than IPv4 NAPT" principle,
which I believe is mathematically inevitable in any case.
One approach for this would be that the DNS would automatically
return IPv4 mapped addresses to IPv6 queries when they have no IPv6
address but have at least one IPv4 address.
SHANTI recommends doing the equivalent of this in the resolver.
Then dual-stack hosts will still see A records, and can be mixed
on the same network with SHANTI hosts.
Then boxes on the client-to-server paths which car support NAT for
IPv4 connections (typically customer edge routers) can do the
Yes, but they still have the ALG problem, and you have to be sure
the packets actually flow that way. SHANTI guarantees the packets are
routed to the translator, and pushes the ALG problem back where it belongs.