One document matched: draft-despres-softwire-4rd-u-01.txt
Differences from draft-despres-softwire-4rd-u-00.txt
Internet Engineering Task Force R. Despres
Internet-Draft October 24, 2011
Intended status: Informational
Expires: April 26, 2012
Unifying Double Translation and Encapsulation for 4rd (4rd-U)
draft-despres-softwire-4rd-u-01
Abstract
This document proposes a new packet format for IPv4 packets to
traverse IPv6 networks. Its purpose is to get, for Residual
Deployment of public IPv4 across IPv6 networks (4rd), the best of
Encapsulation and Double-translation solutions. For this, it ensures
end-to-end transparency of IPv6 networks to IPv4 packets, and makes
it possible to configure existing IPv6 Operation & Management tools
so that they operate also on 4rd packets.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Despres Expires April 26, 2012 [Page 1]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. The 4rd-U Header Mapping . . . . . . . . . . . . . . . . . . . 6
3. 4rd-U Address Mapping - Checksum Neutrality . . . . . . . . . 8
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Despres Expires April 26, 2012 [Page 2]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
1. Problem Statement
Stateless solutions for residual deployment of IPv4 across IPv6
networks, with shared and non-shared IPv4 addresses, have been found
desirable by a number of operators (ref
[I-D.ietf-softwire-stateless-4v6-motivation]). The most general
configurations to be supported are shown in Figure 1, where CE stands
for Customer-edge router, and BR for IPv6-network Border router.
one or more
identical BRs
Customer per IPv4 one or more
sites CEs 4rd Domain provider IPv4 providers
| | | | |
V V V V V
+----------------------+
| IPv6 routing | +--------------------
-------------+ | | |
| | +'-----'+
Derived +'-'+ | |
IPv4 | |<= CE IPv6 +.-----.+ <= One or more
add space +.-.+ prefix | ... | Domain
| | +'-----'+ IPv4 prefixes
-------------+ | | |
| +.-----.+
| | |
... | | +--------------------
| | ...
| | +--------------------
-------------+ | | |
| | +'-----'+
Derived +'-'+ | |
IPv4 | |<= CE IPv6 +.-----.+ <= One or more
add space +.-.+ prefix | ... | Domain
| | +'-----'+ IPv4 prefixes
-------------+ | | |
^ | +.-----.+
| | | |
\ | | +--------------------
\ +----------------------+
\
One or more statelessly advertised Mapping rules
Figure 1: 4rd Domain Model
Despres Expires April 26, 2012 [Page 3]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
For IPv6-domain traversal, different IPv6 packet formats have been
proposed to convey IPv4 packets. Some are based on Double
translation (e.g. in [I-D.xli-behave-divi] and
[I-D.xli-behave-divi-pd] ); some are based on Encapsulation (e.g. in
[I-D.murakami-softwire-4rd]). Both formats having advantages of
their own, this document proposes to combine them in a unified
approach (4rd-U).
An important advantage of Encapsulation is that it fully preserves
network transparency to IPv4 packets, while Double translation, based
on the IP/ICMP translation algorithm of [RFC6145], introduces the
following limitations to network transparency:
o IPv4 options at the IP layer are not translated.
o The "don't fragment" bit of IPv4 (DF bit) is not translated.
o The IPv4 Type-of-service octet (TOS) cannot be preserved if the
traversed IPv6 network has constraints on the IPv6 Traffic-class
octet (TC).
The first limitation, lack of IPv4-option support, can be accepted
for the following reasons: (1) IPv4 options are very rarely used; (2)
they don't influence which applications are supported; (3) Error
messages are available to inform sources that options they tried to
use are not supported ([RFC0792] has an ICMP error massages meaning
"something is wrong with the type code of the first option").
The second limitation, lack of preservation of the DF-bit by IPv4-
IPv6 translators, is more problematic:
Its origin is that IPv4 and IPv6 treat packet fragmentations
differently. In IPv4, sources MAY fragment packets and indicate,
on a per packet basis, whether the network MAY itself fragment
packets or not [RFC0791]: if a packet has its DF = 1 and is too
big for the next link to be traversed without fragmentation, the
network MUST discard this packet (the ICMP error message specified
for this case in [RFC0792] is "fragmentation needed and DF set");
if a packet has its DF = 0 and is too big for the next link to be
traversed without fragmentation, the network MUST fragment it, and
forward its fragments. In IPv6, sources MAY fragment packets, but
networks MUST NOT fragment them: if a packet is too big for the
next link to be traversed without fragmentation, the network MUST
discard it (with the returned ICMPv6 error message "Packet too
big" [RFC4443].
Despres Expires April 26, 2012 [Page 4]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
Now, if an IPv4 packet having DF = 0 is too long to traverse an
IPv6 network as a single packet (e.g. has 1400 octets and needs to
traverse an IPv6 link whose limit is 1280 octets), the IPv4 packet
MUST be fragmented and forwarded to comply with IPv4 rules,
independently of the value of its DF bit. The problem of
translation is then that IPv6 packets have no field to convey the
DF-bit value. At IPv6 network exit, where the IPv6 packet has to
be translated back to IPv4, one cannot determine whether: (a) the
IPv4 packet had been fragmented by its source with with DF = 1 and
with a size small enough to need no fragmentation to traverse the
IPv6 network; or, (b), the IPv4 packet had been sent with DF = 0
and needed fragmentation to traverse the IPv6 network. The
original DF bit is lost.
Consequences of not complying end-to-end with the IPv4-
fragmentation specification may be limited, but there is no way to
guarantee they will remain negligible. If choice exists,
solutions that avoid this risk SHOULD therefore be preferred.
The third limitation, lack of guaranteed transparency to the IPv4
TOS, has consequences that are difficult to predict because of the
diversity of existing supports of TOS and TC octets. In some IPv6
networks, the IPv4 TOS can without problem be mapped into the IPv6 TC
at IPv6-network entrance, and mapped back to the IPv4 TOS at IPv6-
network exit. But in some other IPv6 networks, the IPv6 TC to be
used for domain traversal has to comply with local constraints. To
avoid that these constraints interfere with the semantics of the IPv4
TOS, the original TOS at domain exit MUST in this case be restored.
On the other hand, Double translation has a significant advantage
over Encapsulation: a number of existing Operation & Maintenance
functions that work for IPv6 can be configured to work also for IPv4,
even if concerned with transport-layer ports (e.g. Access control
lists), or with valid transport-layer checksums (e.g. for web
redirection).
The problem is then to find a new design, if it exists, that keeps
the best of both proposed approaches: (a) end-to-end transparency to
IPv4; (b) applicability of IPv6 Operation & Maintenance tools of
IPv6-only domains to IPv4 packets.
Such a design happening to be possible, it is proposed in Section 2.
Despres Expires April 26, 2012 [Page 5]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
2. The 4rd-U Header Mapping
The approach of 4rd-U to meet requirements of Section 1 consists in
specifying a header mapping from IPv4 to IPv6 that:
o is reversible (network transparency to IPv4),
o has no impact on UDP and TCP checksums (checksum neutrality).
Its IPv6 packet format, compared to those of Double Translation and
those of Encapsulation is shown in Figure 2.
IPv4 packet 4rd-U IPv6 packet
+-----------------+ _ _ +-----------------+
| IPv4 Header | _| --> | | IPv6 Header |
+-----------------+ | +-----------------+
| IP Data | |_ |IPv6 Frag. Header|
+-----------------+ +-----------------+
| IP Data |
+-----------------+
Double translation for UDP/TCP (ref. RFC 6145)
+-----------------+ _ _ +-----------------+
| IPv4 Header | _| --> | | IPv6 Header |
+-----------------+ _ | +-----------------+
|Transport Header | _| -. |_ |IPv6 Frag. Header| (if needed)
+-----------------+ \ _ +-----------------+
| Transport Data | '-> |_ |Transport Header | (adjusted cksm
+-----------------+ +-----------------+ if needed)
| Transport Data |
+-----------------+
Encapsulation (ref I-D.murakami-softwire-4rd)
+-----------------+ _ _ +-----------------+
| IPv4 Header | _| --> | | IPv6 Header |
+-----------------+ | +-----------------+
| IP Data | | |IPv6 Frag. Header| (if needed)
+-----------------+ | +-----------------+
|_ | IPv4 Header |
+-----------------+
| IP Data |
+-----------------+
Compared Packet Formats of 4rd-U - Translation - Encapsulation
Figure 2
Despres Expires April 26, 2012 [Page 6]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers=4 |HeadL=5|Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Identification |0|D|M| IPv4 Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Payload |
| |
||
\/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers=6 | TrafClass | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length |Next Header=44 | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Source Address +
| (Mapped from IPv4 address or address + port) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Destination Address +
| (Mapped from IPv4 address or address + port) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | IPv6 Fragment Offset | 0 |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| 0 | IPv4 TOS | IPv4 Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Payload |
| |
4rd-U Header Mapping
Figure 3
Despres Expires April 26, 2012 [Page 7]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
The 4rd-U header mapping is detailed in Figure 3. In it, D stands
for DF, and the Flow Label should by be set to 0. Values of all
other fields can be determined by simple rules known by anyone
familiar with IPv4 and IPv6 packet formats.
This header mapping takes advantage of the following favorable
technical facts:
o IPv6 packets MAY contain Fragment headers
o In IPv6 fragment headers, Identification fields used for
reassembly have 64 bits, i.e. 32 bits more than in IPv4. (This is
enough to transparently convey IPv4 fields that need to be
restorable at IPv6-domain exit, namely the DF bit an the TOS octet
as explained in Section 1).
o IPv6 addresses used to convey IPv4 packets can be made checksum
neutral (see Section 3).
3. 4rd-U Address Mapping - Checksum Neutrality
For residual IPv4 deployments across IPv6 networks, a number of
address-mappings between IPv4 addresses, or IPv4 addresses plus
ports, and IPv6 addresses have been proposed. One of them has even
been proposed as a unified address mapping for Double translation and
Encapsulation solutions [unifAddMapp]. But it was devised before a
further unification, with a unified packet format like that of 4rd-U,
had been envisaged. It misses one important feature: the checksum
neutrality discussed in Section 2.
The proposal below, is devised to keep all significant properties of
[unifAddMapp] and to add checksum neutrality. It sacrifices for this
the length indicator that was included in IPv6 addresses but was
necessary neither for routing 4rd packets in IPv6 networks, nor for
4rd functions at exit of IPv6 networks. (It could have been useful
to facilitate maintenance, but in a way that appears quite
secondary.)
Figure 4 shows steps whereby an IPv6 destination address is derived
from an IPv4 destination address and from the value of the field
where transport protocols have their destination ports ("DST port
field"). If the IP payload has less that 4 octets, missing octets of
the DST port field are replaced by 0s to keep uniformity of
treatment.
Despres Expires April 26, 2012 [Page 8]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
32 16
+----------------------+---------------+
| DST IPv4 address |DST port field |
+----------------------+--+------------+
: : : 12 :
: : +------------+
: : | Max PSID |
: : +------------+
: : / /
: 44 :/ /
+-----------------------------------+
| DST max 4rd prefix |
+----------------+------------------+
: : :
: 0 to 32 : :
+----------------+ :
|Rule IPv4 prefix| :
+----------------+ :
max 64 : max 44 :
+------------------+------------------+
| Rule IPv6 prefix | DST max index |
+------------------+------------------+
: max 104 :
: : min 0
+-------------------------------------+-------------------+
| DST max IPv6 prefix | Padding = 0 |
+-------------------------------------+-------------------+
: :
: 104 :
+---------------------------------------------------------+
| DST padded max IPv6 prefix |
+----------------------------------+----------------------+
: 64 :\ 40 \
: +-+ Checksum +--------+
: |V| neutrality | CNP |
: +-+ preserver +--------+
: :4: : 16 :
+----------------------------------+-+----------------------+--------+
| DST IPv6 address |
+--------------------------------------------------------------------+
128
From DST IPv4 Address plus DST Port field to DST IPv6 address
Figure 4
Despres Expires April 26, 2012 [Page 9]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
Successive steps are the following:
1. Build the DST max 4rd prefix by concatenating the DST IPv4
address and the last 12 bits of the DST port field.
2. Build the DST padded max IPv6 prefix by replacing, in this DST
max 4rd prefix, bits that match the IPv4 prefix of a mapping rule
by the IPv6 prefix of this mapping rule, and by padding the
result with 0s if necessary to reach 104 bits.
3. Build the DST IPv6 address by concatenating: (a) the first 64
bits of the DST padded max IPv6 prefix; (b) The 4rd V octet, a
mark that never appears in any other IPv6 address, and whose
proposed value is 0x03 (it permits to use the same CE IPv6 prefix
for 4rd packets and for other IPv6 packets); (c) the last 40 bits
of the DST padded max IPv6 prefix; (d) A Checksum neutrality
preserver CNP (in one's complement arithmetic, it is the sum of
the two 16 bit fields of the IPv4 address minus the sum of 16 bit
fields of (a).(b).(c)).
Unless something has been missed, this address mapping has, in
addition to its checksum neutrality, all properties needed for
scenarios of previously documented Encapsulation and Double-
translation solutions.
In particular, with a mapping rule whose IPv4 prefix is 0/0, it can
support scenarios where full IPv4 addresses are contained in IPv6
addresses, e.g. those of [I-D.xli-behave-divi].
It can also support scenarios where IPv6 routing plans are
independent from any consideration on IPv4, like those permitted by
[I-D.despres-softwire-4rd-addmapping]. For these, the way in which
CEs derive their IPv4 prefixes, IPv4 addresses, or IPv4 addresses
plus restricted port sets, from their IPv6 pre-assigned prefixes,
needs no change to be consistent with the 4rd-U address mapping as
specified above (see Figure 5).
Despres Expires April 26, 2012 [Page 10]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
max 104
+---------------------------+
| CE IPv6 prefix |
+---------------------------+
: :
: max 64 max 44 :
+------------------+--------+
| Rule IPv6 prefix |CE index|
+------------------+--------+
: :
max 32 : :
+----------------+ :
|Rule IPv4 prefix| :
+----------------+ :
: :
: max 44 :
+-------------------------+
| CE 4rd prefix |
+-------------------------+
:\_________________ :\______________
: \ : \
: ___:____/ :
: max 32 / : 32 1 to 12:
+--------------+ +---------------+------+
|CE IPv4 prefix| OR |CE IPv4 address| PSID |
+--------------+ +---------------+------+
: :
4 : :
+--+ +---------+
|y | | x |
+--+ +---------+
: :
: 32 :
+-------------------+
|Port in CE port set|
+-------------------+
y > 0, x any value
From IPv6 prefix to IPv4 prefix or IPv4 address + Port set
Figure 5
Despres Expires April 26, 2012 [Page 11]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
4. Conclusion
This proposal is submitted to the Softwire WG as a short term
technical contribution, not as a document expected to become per se
an RFC.
The expectation is that its substance, duly evaluated by the WG, and
amended as much as found necessary, can quickly be a basis of a
unified standard, suitable for all desirable scenarios for stateless
deployments of residual IPv4 across IPv6 networks.
5. Acknowledgements
The original idea of unifying Encapsulation and Double translation
has been influenced by thorough discussions, at the Softwire interim
meeting in Beijing, on compared merits of these two approaches. In
particular, contributions of Xing Li, Congxiao Bao, and Wojciech Dec,
have to be acknowledged.
Improvements made since the first version of this document have been
influenced by remarks received, on the Softwire mailing list and
privately, in particular from Satoru Matsushima, Mark Townsley, and
Maoke Chen.
6. References
6.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
6.2. Informative References
[I-D.despres-softwire-4rd-addmapping]
Despres, R., Qin, J., Perreault, S., and X. Deng,
"Stateless Address Mapping for IPv4 Residual Deployment
(4rd)", draft-despres-softwire-4rd-addmapping-01 (work in
progress), September 2011.
[I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
Despres Expires April 26, 2012 [Page 12]
Internet-Draft Unified Translation-Encapsulation for 4rd October 2011
draft-ietf-softwire-stateless-4v6-motivation-00 (work in
progress), September 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03
(work in progress), July 2011.
[I-D.xli-behave-divi-pd]
Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun,
"dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix
Delegation", draft-xli-behave-divi-pd-01 (work in
progress), September 2011.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[unifAddMapp]
"Proposed Unified Address Mapping for encapsulation and
double-translation - http://www.ietf.org/mail-archive/web/
softwires/current/msg02994.html", October 2011.
Author's Address
Remi Despres
3 rue du President Wilson
Levallois,
France
Email: despres.remi@laposte.net
Despres Expires April 26, 2012 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 03:02:38 |