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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
