[v4v6interim] "IPv4->IPv6 is hard"

[Fred Baker <[e-mail]>]

I'm fairly disturbed by Mark's dismissal of IPv4->IPv6 translation as  
"hard". I'll take this note to say why. I am obviously a proponent of  
a particular class of solution, IVI, which is specifically targeted at  
solving this problem, so let me declare bias up front. But I do not  
consider the issue hard if correctly analyzed and approached.

In this analysis, I am going to leave out the dual stack case, which I  
frankly consider the strongly preferable deployment model. Wherever it  
is used, matters get simplified. I am expressly looking at the more  
difficult IPv4-only/IPv6-only case.

Mark's dismissal - I call it that because he spent an hour talking  
about CGN solutions and then spent less than a minute charging through  
two slides that discussed actually deploying IPv6 and declaring them  
both "hard" and therefore not worthy of consideration - is based on  
the observation that mapping 2^128 addresses into 2^32 bits is hard. I  
will agree with him that making it possible for every IPv6 address to  
be mapped into IPv4 in a scalable manner has issues. The question that  
I will ask is: is that the real requirement? I don't think it is.

While the addressing issue resolves to hosts, the connectivity problem  
is about applications. I think that today's applications can largely  
be broken down into two broad categories, and speakers in those  
applications into three. These are: the clients of client/server  
applications, the servers in client/server applications, and the peer  
in peer-to-peer applications. In an IPv4-only/IPv6-only gateway, we  
have actually only our session initiation problems to solve:

     IPv6 client->IPv4 server
     IPv4 client->IPv6 server
     IPv6 peer -> IPv4 peer
     IPv4 peer -> IPv6 peer

Once a session is initiated, we can obviously continue the conversation.

IPv6 client->IPv4 server is pretty simple. The DNS ALG advertises IPv4  
addresses as mapped IPv6 addresses, and the gateway keeps 1:n overlaid  
mappings in a manner not all that different from current IPv4/IPv4  
NATs. On the IPv6 side of the gateway, we simply use the mapped  
address; on the IPv4 side, we use IPv4 address+port overlay as we do  
in IPv4/IPv4 NATs.

An IPv4 client accessing an IPv6 server is equally simple given a 1:1  
mapping such as NAT64 or IVI describes. One maps the headers and the  
addresses.

IPv6 peer->IPv4 peer is simple enough; it is essentially the same  
problem as IPv6 client->IPv4 server, and is solved the same way.

Initiating a session from an IPv4 peer to an IPv6 peer with an  
unmapped address is "hard"; that winds up calling for complex  
machinery like NAT-PT proposes. However, it is unnecessary to solve  
the case. p2p technologies open TCP connections between systems, leave  
them open long periods of time, and use them to transport data. They  
are in effect overlay networks. If one IPv6 peer opens a session to an  
IPv4 peer, connectivity is established between IPv4-only and IPv6-only  
p2p networks and the problem is solved.

So to my mind, the requirement is that the gateway provide three  
services:
   - a DNS algorithm that maps IPv4 addresses to a subset of IPv6
     addresses.
   - a 1:1 NAT algorithm that statelessly supports the common case of
     IPv4 clients accessing IPv6 servers, which will be used by a
     relatively small set of hosts in the IPv6-only domain.
   - 1 1:n NAT algorithm that statefully maps general IPv6 to IPv4
     address plus port, which might be used by an arbitrarily large
     number of hosts in the IPv6-only domain, but unlikely to be all
     at the same time and diminishing as IPv6 deployment grows.

None of those models is "hard" in light of our present experience with  
SIIT and IPv4/IPv4 NAT.

Now, here is my issue with NAT64/SIIT's addressing model, which we  
deployed and then deprecated in RFC 4291. There are two. First, it is  
a lot like a default route, and limits the network administration's  
options in route management; to fix that, we need to have a prefix  
appropriate to the gateway as opposed to a flat "must be zero" style  
prefix. Second, th addressing architecture is essentially that of CIDR  
and therefore allows routing prefixes to be as long or as short as  
needed, but we have given clear guidance that router vendors should  
think about host routes or prefixes of /64 or shorter, not normally  
prefixes in the 65..127 length range. If we believe that - and RFC  
4291 clearly does - then enabling the gateway to support routing to  
multiple sites within the IPv6 domain using a single IPv4 prefix  
advertised in the IPv4 domain (as opposed to doing host routing to  
IPv4-mapped addresses in the IPv6-only domain) is important for  
scaling. IVI moves the address around to put IPv4-mapped prefixes  
within the /64 length rule.

So the fundamental argument for IVI is that it works well with  
routing, and makes interchange of both p2p and client/server  
applications across the IPv4/IPv6 gateway simple.

IPv4 access to the IPv6 network is most definitely *not* hard if the  
problem is correctly parsed and addressed.

No pun intended.
_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim