IPv4 -> IPv6 "bridge" ?

[Fred Baker]

On Oct 12, 2010, at 2:03 AM, Xavier Beaudouin wrote:

> Hello,
> 
> The thread about IPv6 Future, how will you solve IPv4 connectivity, is for me also a problem.
> 
> I operate a new born cloud computing company in France (we do only this kind of business, exclusively), and we have the problem of IPv4 exhaustion...
> 
> We had an idea to do IPv6 only on all hosts and create a kinda bridge with our /21 (at starting) to do IPv4 -> "internal" IPv6 host that must be reachable from IPv4 "old internet", also this mapping has to be done in direction IPv6 host -> IPv4 when this host needs to reach some IPv4 stuff.
> 
> Unfortunatly it seems to be not easy, even in the free world (for example OpenBSD...)...
> 
> Anybody has some pointers, rfc or what else to implement that ?
> 
> Also we don't want dual stacks, VPN and some fscking from people that using too mutch RFC1918 networks will gave some ipv4 collisons... That's why we want to force end users to use IPv6 exclusively (since there is as least 2 ISP that provide native or near native IPv6 connectivity in France), this can be "the ipv6 killer application" to force the world to move really to IPv6....
> 
> Regards,
> Xavier

we have some about-to-be-RFCs on translation, which I think is what you're talking about. I'll put pointers to them at the end of this note. The premise here (following CERNET2, which developed and deployed the technology between itself and CERNET) is:

 * we have an IPv4 network (duh)
 * we are deploying an IPv6-only network
 * in that network, we have two classes of devices:
      - those that need to be accessed from the IPv4 network (servers)
      - those that merely need to access servers in the IPv4 network

The translator has a prefix it advertises into the IPv4 network and sub-divides into many smaller prefixes in the IPv6 network; these prefixes embed the IPv4 address into the network's IPv6 prefix. It also advertises that IPv6 prefix into the IPv6 network. Traffic from an IPv4-embedded address is translated statelessly, which has interesting values such as being load-sharable across multiple translators and such. Traffic from a more normal IPv6 address is translated in a manner similar to IPv4/IPv4 NAT.

Servers, following that rubric, are accessible in either direction. IPv4 systems cannot at will open sessions with IPv6 systems that don't have IPv4-embedded addresses, however.

This suffers the classic issues of network address translation; if the application (SIP/SDP, HTTP referrals, FTP, etc) carries an IP address and expects its peer to be able to use it, the peer is SOL, because the address is not meaningful. In this case, it isn't even understandable. What needs to happen, of course, is that applications use application layer naming rather than network layer naming. Every time I say that to an applications person, I get a blanch and a blank stare. Then I wonder why they don't insist on using MAC addresses - if the layer violation is so obviously sensible to the network layer, why not the MAC layer? But then it becomes clear that logic has nothing to do with this; they're just going to do it.

But none-the-less, yes there are tools, and companies are starting to implement them. IMHO, they are stopgaps until we have wide IPv6 deployment; at that point, the headaches will not be worth the effort, and folks will simply use IPv6.


http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework
  "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao
  Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-address-format
  "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian
  Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
  <draft-ietf-behave-address-format-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-dns64
  "DNS64: DNS extensions for Network Address Translation from IPv6 Clients
  to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews,
  Iljitsch van Beijnum, 1-Oct-10, <draft-ietf-behave-dns64-11.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate
  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker,
  18-Sep-10, <draft-ietf-behave-v6v4-xlate-23.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful
  "Stateful NAT64: Network Address and Protocol Translation from IPv6
  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van
  Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stateful-12.txt>

http://datatracker.ietf.org/doc/draft-arkko-ipv6-transition-guidelines
  "Guidelines for Using IPv6 Transition Mechanisms during IPv6
  Deployment", Jari Arkko, Fred Baker, 21-Aug-10,
  <draft-arkko-ipv6-transition-guidelines-06.txt>