[Softwires] 4rd-U - The Unified stateless solution for IPv4 Residual Deployment via IPv6

[Rémi Després <[e-mail]>]

Hello, all,

 The new version of the 4rd-U draft has just been posted. 
It is available at www.ietf.org/id/draft-despres-softwire-4rd-u-02.txt.

 As previously announced, it should be a starting point for contributions from those who believe that, for stateless deployments residual IPv4 via IPv6, one standard would be better than two.


 It is written a self-contained specification, in principle sufficient for compatible implementations, but has been too rapidly written to be without a number of inadequacies.
 If you are interested in becoming contributor, please let me know.

 Clarification questions are most welcome from anyone, even if not interested in becoming contributor.

 Best wishes for a happy new year.

RD




Abstract

   This document specifies an automatic tunneling mechanism tailored for
   residual deployment of public IPv4 via IPv6 networks (the reverse of
   6rd whose purpose is rapid deployment of IPv6 via IPv4).  In order to
   deal with the IPv4-address shortage, customers can be assigned shared
   IPv4 addresses with statically assigned restricted port sets.
   Operation is stateless, with no per-customer state in network nodes.

   4rd-U unifies in a synthesis features of double-translation-based
   solutions (in particular compatibility with some IPv6-only middle-box
   tools inside IPv6 networks), and those of IP-in-IP encapsulation
   solutions (in particular complete end-to-end transparency to IPv4
   packets).  It is proposed as a unified standard replacing the two
   standards that are otherwise envisaged.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  The 4rd-U Model  . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Reversible Header Mapping from IPv4 to IPv6  . . . . . . .  6
     5.2.  Mappings Rules . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  Mappings from IPv6 prefix to Residual-IPv4 prefix  . . . . 10
     5.4.  Mapping from Residual-IPv4 address to IPv6 address . . . . 12
       5.4.1.  From Residual-IPv4 address to IPv6 prefix  . . . . . . 12
       5.4.2.  From IPv6 prefix to IPv6 address . . . . . . . . . . . 14
     5.5.  Fragmentation Considerations . . . . . . . . . . . . . . . 16
       5.5.1.  Ports of Fragments sent to Shared-Address CEs  . . . . 17
       5.5.2.  Datagram-Identification Updates in BRs . . . . . . . . 17
     5.6.  Translating Tunnel-Generated ICMPv6 into ICMPv4  . . . . . 17
     5.7.  Provisioning 4rd-U parameters to CEs . . . . . . . . . . . 18
     5.8.  BR and CE Behaviors  . . . . . . . . . . . . . . . . . . . 19
   6.  Use-Case Examples  . . . . . . . . . . . . . . . . . . . . . . 25
     6.1.  Moving from IPv4-only to IPv6 and Residual IPv4  . . . . . 25
     6.2.  Residual-IPv4 Service via a Third-Party IPv6 Network . . . 27
     6.3.  Adding Residual IPv4 to an IPv6-only network . . . . . . . 28
     6.4.  IPv6 and Residual-IPv4 added to a net-10 network . . . . . 29
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   9.  Contributors and Acknowledgements  . . . . . . . . . . . . . . 31
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     10.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34