Internet DRAFT - draft-chen-softwire-4rd-u-comment
draft-chen-softwire-4rd-u-comment
Softwires Working Group M. Chen
Internet-Draft FreeBit
Intended status: Informational April 10, 2012
Expires: October 12, 2012
A Commentary on 4rd-U Architecture and Semantics
draft-chen-softwire-4rd-u-comment-00
Abstract
4rd-U is proposed as an effort of unifying encapsulation and double
translation solutions for the softwire of IPv4 over IPv6 domain.
This attempt introduces new behaviors in the Internet transition
architecture as well as semantics other than that of well-known
Internet protocols. This documents provides a commentary on the
semantic changes and their impacts.
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 October 12, 2012.
Copyright Notice
Copyright (c) 2012 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
the Trust Legal Provisions and are provided without warranty as
Chen Expires October 12, 2012 [Page 1]
Internet-Draft 4rd-U Architectural Comments April 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
4. 4rd-U Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. General motivations . . . . . . . . . . . . . . . . . . . 6
4.2. Technical problems to solve . . . . . . . . . . . . . . . 6
4.3. Technical means of the solution . . . . . . . . . . . . . 7
5. Semantic Changes of 4rd-U and Potential Impacts . . . . . . . 9
5.1. Semantics: existence of fragment header . . . . . . . . . 9
5.2. Semantics: IPv6 packet identification . . . . . . . . . . 9
5.3. Semantics: Hop Limit of IPv6 . . . . . . . . . . . . . . . 10
5.4. Semantics: IP/ICMP relationship . . . . . . . . . . . . . 11
6. On Tunnel as Architectural Building Block . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chen Expires October 12, 2012 [Page 2]
Internet-Draft 4rd-U Architectural Comments April 2012
1. Introduction
The 4rd-U [I-D.despres-softwire-4rd-u] is proposed with the goal of
unifying encapsulation and double translation into a single standard.
That effort identifies its technical objective to realize the full
transparency as in encapsultion and meanwhile the visibility of L4
protocol data unit (PDU) as in double translation. The designers of
4rd-U expect it plays the role of a replacement of the MAP suites,
including MAP [I-D.mdt-softwire-mapping-address-and-port], MAP-E
[I-D.mdt-softwire-map-encapsulation], MAP-T
[I-D.mdt-softwire-map-translation] and the DHCP option for MAP
[I-D.mdt-softwire-map-dhcp-option]. Throughout this document, the
term "MAP", unless explicitly specified, refers to the suite of MAP
documents, as an entire description of the MAP architecture.
This commentary is purposed in sharing the observation on 4rd-U
proposal. It covers part of the 4rd-U principles, focusing on its
major semantics changes, especially those that possibly impact the
architecture of the Internet and its transition. The commentary
itself doesn't conclude if 4rd-U is or isn't a deployable
architecture for transition. It provides information for those who
would like to do such a judgement. The commentry can be referenced
by 1) implementors/testers of 4rd-U to cover the architectural
concerns when they set the test scenarios; 2) operators to evaluate
if 4rd-U is a safe choice fitting their own networking environment
and practice experiences; 3) the community of the Internet
engineering to evaluate 4rd-U technology.
This commentary sticks to the newest, currectly version -06, of the
4rd-U draft. Unless explicitly specified, the discussion doesn't
cover the feasures once involved into the 4rd-U early versions but
now already deprecated or obsolteted by other mechanisms.
This commentary covers only topics that the author(s) have
investigated. Co-authorship is welcome and input of further
investigations is expected.
Chen Expires October 12, 2012 [Page 3]
Internet-Draft 4rd-U Architectural Comments April 2012
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Chen Expires October 12, 2012 [Page 4]
Internet-Draft 4rd-U Architectural Comments April 2012
3. Acknowledgements
The author(s) thank Remi Despres for his efforts in continuously
improving 4rd-U design and discussions through maillist and private
communication. No matter if the 4rd-U will or will not become
standard, such an effort would be significantly valuable for the
collective understanding. A lot of contents of this commentary are
illuminated by the maillist discussion in the softwire WG, including
the view points contributed by Congxiao Bao, Wojciech Dec, Xing Li,
Satoru Matsushima, Wentao Shang, Ole Troan and others.
Chen Expires October 12, 2012 [Page 5]
Internet-Draft 4rd-U Architectural Comments April 2012
4. 4rd-U Overview
4rd-U draft contains a lot of features overlapping the problems that
MAP also having addressed. The following analysis on 4rd-U
motivations, major technical objectives and exclusive solutions is
based on the understanding of the commentary author(s) through
reading 4rd-U drafts, comparing 4rd-U and MAP suites, and discussing
with the 4rd-U designers.
4.1. General motivations
Generally, 4rd-U is motivated with the purposes of
(M1) unification of encapsulation and double translation for IPv4
residual deployment;
(M2) simplification of L4 protocol treatment;
(M3) simplification of address distinguishment in the environment
where there are also native IPv6 communications.
4.2. Technical problems to solve
Trying to solve the following problems makes 4rd-U different from
MAP.
(O1) DF=1/MF=1 transparency: [RFC6145], whose header processing of
translation is applied in MAP-T, doesn't cover the case where
IPv4 packet with both "Don't Fragment" (DF) and "More Fragment"
(MF) flags set. MAP-T points out that this corner case is very
minor and some literature (e.g., [IMC07]) argues such a case is
considered abnormal regarding IPv4 protocol [RFC0791], followed
by statistics on this abnormaly. 4rd-U argues it should be
supported no matter how minor it is observed in practice.
(O2) ToS transparency: DiffServ architecture ([RFC2475]) points out
that, (regarding the IPSec tunnel consideration,) whether DSCP
change in tunneling domain should be visible to the tunneled
protocol or not, depends upon the role of "tunnel" in the
architectural perspective. MAP-E follows [RFC2473] and keeps
it as unchanged. MAP-T follows [RFC6145] and copies the IPv4
ToS into IPv6 TrafficClass and vice versa. 4rd-U argues ToS
should be kept unchanged when the packet traverses the IPv6
domain, except the ECN bits.
Chen Expires October 12, 2012 [Page 6]
Internet-Draft 4rd-U Architectural Comments April 2012
(O3) IPv6 O&A tools fully functioning: when IPv4 packet is
encapsulated, IPv4 protocol details is hidden and existing IPv6
O&A tools are unable to view these hidden details, and
accordingly functions like filtering is not able to be
performed. 4rd-U argues this "drawback" of MAP-E should and
could be overcome without losing the full transparency of
encapsulation.
(O4) Deep L4 inspection: when IPv4 packet is encapsulated with IPv6,
typically middle boxes in the IPv6 domain doesn't have the
functionality of deep inspection on the Layer-4 protocol data
unit (PDU) in the encapsulated packet. This makes MAP-E
traffic is unable to be filtered with the existing IPv6 L4
filter rules . 4rd-U argues this "drawback" of MAP-E should and
could be overcome without losing the full transparency of
encapsulation.
(O5) Checksum transparency: MAP-T, along with [RFC6145], adjust L4
protocol checksum at the translator. 4rd-U argues [RFC6145]
optionally supporting DCCP checksum adjustment may cause wrong
checksum for receiver of MAP-T if IPv4-to-IPv6 translator does
the adjustment while the IPv6-to-IPv4 one doesn't. It also
argues checksum validity should be ensured through address in
order to simplify L4 processing.
4.3. Technical means of the solution
In order to achieve the goal of (M1) and to solve the problems listed
above, 4rd-U proposes a series of technical means. Essentially, a
"reversible header mapping" is defined through these means, having
IPv4 header fields (except options) reserved but the header is not
embedded as a whole. This is to achieve the support for deep L4
inspection as translation can, meanwhile to keep the IPv4 header
information unchanged the IPv6 domain. In details, these means
include:
(T1) Always-on fragment header: as a container preserving not only
the fragmentation-related information but also some other
fields.
(T2) DF preserver: at the leftmost bit of IPv6 packet identification
field of the fragment header, carrying the original IPv4
packet's DF bit.
(T3) ToS preserver: at the bits 8~15 of IPv6 packet identification
field of the fragment header, carrying the original value of
IPv4 packet's ToS field.
Chen Expires October 12, 2012 [Page 7]
Internet-Draft 4rd-U Architectural Comments April 2012
(T4) TTL preservers: TTL first bit preserved at the leftmost bit of
IPv6 HopLimit; TTL bits 1~7 preserved at bit 1~7 of IPv6 packet
identification field of the fragment header.
(T5) ICMPv4 being carried by IPv6: providing full transparency for
ICMPv4 messages traversing the IPv6 domain; also as a required
solution to deal with the problem that [RFC6145] has identified
regarding the PTB message with MTU less than 1280 bytes
(translated), and meanwhile keep the DF=1 transparent.
(T6) ICMPv6 being translated: with the same logic that [RFC6145]
defines for the ICMPv6 error messages generated by the middle
boxes in the IPv6 domain.
4rd-U also defines techinal means for (M2) and (M3), respectively.
Checksum neutrality preserver (CNP): in the end of IPv6 interface
identifier, with the value ensuring the mapped IPv6 address
having the same checksum with the original IPv4 address.
V-octet: as a mark for 4rd-U address, (0x03 for bits 64~71) in IPv6
address generated by the 4rd-U CE or BR, as a means
distinguishing 4rd-U traffic from native usage.
The current version of this commentary focuses on the architecture
issue and therefore motivation (M1), technical objectives (O1)~(O5),
and technical means (T1) through (T6) are in scope.
Chen Expires October 12, 2012 [Page 8]
Internet-Draft 4rd-U Architectural Comments April 2012
5. Semantic Changes of 4rd-U and Potential Impacts
The above technical means more or less change the well-known Internet
protocol semantics. It is not the task of this commentary to judge
if these changes are serious concerns or not. It is the task of it
to identify what kind of semantic changes they are and to identify
what potential impacts they have.
Sometimes MAP-E or MAP-T semantics is also clarified when the
clarification is considered helpful to share understanding. In the
term of header processing semantics, MAP-E is based on [RFC2473]
while MAP-T on [RFC6145].
5.1. Semantics: existence of fragment header
IPv6 semantics:
Indicating the source has fragmented the datagram.
RFC6145 semantics:
Indicating the source allows further fragmentation, informing
the IPv6-to-IPv4 translator clear the DF when making the IPv4
packet.
4rd-U semantics:
Indicating nothing specific to fragmentation facts, but always
being included.
Impact:
Always seeing fragment header is strange to middle boxes in the
IPv6 domain. The system administrators of any middle box
SHOULD be informed on the deployment of 4rd-U.
5.2. Semantics: IPv6 packet identification
IPv6 semantics:
32-bit packet identification.
RFC6145 semantics:
32-bit packet identification with, if translated from IPv4,
having the original IPv4 packet identification in lower 16 bits
while keeping the higher 16 bits zero.
4rd-U semantics:
If translated from IPv4, having the original IPv4 packet
identification in lower 16 bits while original DF in the
highest bit, TTL in the bits 1~7, DSCP in bits 8~13, ECN in
bits 14~15.
Chen Expires October 12, 2012 [Page 9]
Internet-Draft 4rd-U Architectural Comments April 2012
Impact:
a. Single translation, which is supported by RFC6145,
becomes incompatible in 4rd-U as the 32-bit full IPv6
identification cannot be distinguished (workaround:
V-octet may help the distinguishment with need of
verification.)
b. Session identification in middlex boxes (firewalls) is
confused because the same IPv4 datagrams might be
fragmented into packets and their value of TTL and ECN
may become different when entering the IPv6 domain,
causing different identification in IPv6. Therefore the
technical objective (O3) is not fully reached.
5.3. Semantics: Hop Limit of IPv6
IPv6 semantics:
One decrement per hop. In practice (e.g., some hop-security
mechanisms, like that is designed in RIPng ([RFC2080]), the
generic TTL-security ([RFC5082]), which is used in both OSPFv3
and BGP4+ products), Hop Limit is initialized to 255 and
receivers calculates the hop-distance from the source.
RFC2473 semantics:
Tunnel entry point initializes HopLimit to 255 in IPv6. Hop
Limit reaching 0 indicates that tunnel exit point is
unreachable due to, e.g., routing problems (count-to-infinity),
treated as an link failure. Therefore the "hop limit exceeded"
ICMPv6 error message generated in IPv6 domain is translated to
"host unreachable".
RFC6145 semantics:
Tunnel entry point copies TTL to Hop Limit in IPv6. Hop Limit
decrement in IPv6 domain is reflected to IPv4 TTL when packet
is translated back to IPv4, treated as multi-hop paticipant in
the end-to-end delivery path. Therefore the "hop limit
exceeded" ICMPv6 error message generated in IPv6 domain is
translated to "time to live exceeded in transit".
4rd-U semantics:
The leftmost bit of IPv4 TTL is copied to the leftmost bit of
Hop Limit field, while the bit 1~7 of Hop Limit is initialized
to 127. 4rd-U translates ICMPv6 "hop limit exceeded" message,
generated in the IPv6 domain, to "time to live exceeded" ICMPv4
message.
Chen Expires October 12, 2012 [Page 10]
Internet-Draft 4rd-U Architectural Comments April 2012
Impact:
a. The behavior of 4rd-U translation of "hop limit exceeded"
is contradictory to the behavior that IPv4 TTL is not
changed through the IPv6 domain.
b. The IPv6 domain maximum hop count must be limited below
127. (4rd-U draft considers it is not a problem in
practice.)
c. The criterion of IPv6 routing "count-to-infinity" is
changed. Even if the diameter of the IPv6 domain is
surely less than 127, considering the temporary route
loop often happens in dynamic routing, limiting hop below
127 is actually setting an allowed diameter far less than
this value.
d. IPv6 normal usage of Hop Limit larger than 127 is
confused. Impact involves the TTL-security mechanism for
IPv6 routing, application-layer hop count constraints,
etc. Host behind 4rd-U CE may generate attack packets
breaking the IPv6 TTL-security mechanism, through
spoofing CE's source address and applying any TTL value
with leftmost bit set. Wheter other mechanism of 4rd-U
(like V-octet) provides sufficient means of protection
needs to be further investigated and verified.
5.4. Semantics: IP/ICMP relationship
IPv4/v6 semantics:
ICMP is considered a companion of IP rather than a L4 protocol.
IPv4 [RFC0791] carries ICMPv4 [RFC0792] and served by ICMPv4;
IPv6 [RFC2460] carries ICMPv6 [RFC4443] and served by ICMPv6.
IPv4 address integrity is protected by IPv4 header checksum;
IPv6 address integrity is protected by ICMPv6 checksum, which
covers IPv6 pseudo-header.
RFC2473 semantics:
ICMPv4 is carried by IPv4 and the entire IPv4 PDU is
encapsulated by IPv6. The tunneled protocol contains header
checksum. As a tunnel link, the check on the tunneled protocol
is never supposed to be performed in the middle of the link but
only the tunnel end points.
RFC6145 semantics:
IPv4/ICMPv4 pair is translated to IPv6/ICMPv6 pair and vise
versa. Double translation may lose semantics accuracy for some
IPv4 error messages in acceptable level.
Chen Expires October 12, 2012 [Page 11]
Internet-Draft 4rd-U Architectural Comments April 2012
4rd-U semantics:
IPv4/ICMPv4 pair is mapped to IPv6/ICMPv4 pair and vise versa;
ICMPv6 generated in IPv6 domain (IPv6/ICMPv6 pair) is
translated to IPv4/ICMPv4 pair, following the same way as
RFC6145 does.
Impact:
a. IPv6 domain MUST set all filters in middle boxes to pass
protocol 1 (ICMP) as IPv6 payload in order to support
4rd-U functionality.
b. The IPv6 O&A tools that ensure ICMP error message being
destined to original source cannot function regarding
ICMPv4 as payload. This is not a mistake but doesn't
satisfy the technical objective (O3).
c. In the IPv6/ICMPv4 pair, both IPv6 header and ICMPv4
header doesn't contain checksum regarding addresses.
Integrity protection is totally lost.
Chen Expires October 12, 2012 [Page 12]
Internet-Draft 4rd-U Architectural Comments April 2012
6. On Tunnel as Architectural Building Block
Because 4rd-U calls it self a "tunneling" solution, it is necessary
to review the concept of "tunnel" and identify what kind of 4rd-U
tunnel is in the term of architectural building block in the Internet
transition.
In the background section of "A Scheme for an Internet Encapsulation
Protocol, Version 1" ([RFC1241]), it is stated:
A tunnel is essentially a Source Route that circumvents
conventional routing mechanisms.
It is further pointed out that the ways of making a tunnel includes
source routing option, new IP option, and IP encapsulation.
[RFC2475], mentioning different view of architectural building block
about "tunnel", also reflects such an understanding. In this
context, let's call it the tunnel of "general sense". General-sense
tunnel can be a one-hop virtual link or a multi-hop participant in
the delivery path.
On the other hand, the community has widely accepted "tunnel", unless
it is explicitly specified, as a conventional alias of the building
block provided by the technology of encapsulation. Let's call that
tunnel of "narrow sense". Narrow-sense tunnel, in architecture,
behaves as a one-hop virtual link.
With the understanding of "circumventing conventional routing
mechanism", surely double translation is also a sort of tunneling in
general sense, but behaves as the building block of multi-hop
participant.
4rd-U is surely a sort of general-sense tunneling technology.
However, when one claims 4rd-U having the advantages of tunnel in
comparison to translation approaches, the wording is obviously
talking about the narrow-sense tunneling. It needs further
investigation to ensure if 4rd-U is qualified to be called as a
tunnel in the narrow sense.
Chen Expires October 12, 2012 [Page 13]
Internet-Draft 4rd-U Architectural Comments April 2012
7. Summary
The observation is, 4rd-U introduces 3 types of behaviors:
Similar to encapsulation:
- IPv4 fields DF, ToS, TTL are kept unchanged, traversing the
IPv6 domain.
- Middle boxes in the tunnel are unable to check if ICMPv4
message is sent to correct destination.
Similar to double translation:
- Without protocol layering, position of IPv4 fields are
changed;
- IPv4 options are removed;
- Translation ICMPv6 messages generated in IPv6 domain to
ICMPv4 messages with the same logic of RFC6145.
Never seen in encapsulation nor in double translation:
- IPv6 carries ICMPv4 directly;
- TTL leftmost bit is copied to Hop Limit leftmost bit.
When setting the testing scenarios, it is recommended that the above
semantics changes and behaviors are fully considered. It is also
expected that the designer, implementator and tester provides
comprehensive evidence either to ensure those changes as well as new
behaviors are not of problem in practice or to clarify the boundary
conditions, with which as prerequisites 4rd-U can work safely and
reach its design objectives.
Chen Expires October 12, 2012 [Page 14]
Internet-Draft 4rd-U Architectural Comments April 2012
8. IANA Considerations
This specification does not require any IANA actions.
Chen Expires October 12, 2012 [Page 15]
Internet-Draft 4rd-U Architectural Comments April 2012
9. Security Considerations
There are no new security considerations pertaining to this document.
Chen Expires October 12, 2012 [Page 16]
Internet-Draft 4rd-U Architectural Comments April 2012
10. References
[I-D.despres-softwire-4rd-u]
Despres, R., Penno, R., Lee, Y., Chen, G., and J. Qin,
"IPv4 Residual Deployment via IPv6 - Unified Solution
(4rd)", draft-despres-softwire-4rd-u-06 (work in
progress), March 2012.
[I-D.mdt-softwire-map-dhcp-option]
Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C.
Bao, "DHCPv6 Options for Mapping of Address and Port",
draft-mdt-softwire-map-dhcp-option-02 (work in progress),
January 2012.
[I-D.mdt-softwire-map-encapsulation]
Troan, O., Matsushima, S., and T. Murakami, "MAP
Encapsulation (MAP-E) - specification",
draft-mdt-softwire-map-encapsulation-00 (work in
progress), January 2012.
[I-D.mdt-softwire-map-translation]
Bao, C., Li, X., Zhai, Y., Murakami, T., and W. Dec, "MAP
Translation (MAP-T) - specification",
draft-mdt-softwire-map-translation-01 (work in progress),
March 2012.
[I-D.mdt-softwire-mapping-address-and-port]
Bao, C., Troan, O., Matsushima, S., Murakami, T., and X.
Li, "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-03 (work in
progress), January 2012.
[IMC07] John, W. and S. Tafvlin, "Analysis of Internet Backbone
Traffic and Header Anomalies observed", Proc. of IMC
2007 , Aug 2007, <IMC07Traffic>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC1241] Woodburn, R. and D. Mills, "Scheme for an internet
encapsulation protocol: Version 1", RFC 1241, July 1991.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
Chen Expires October 12, 2012 [Page 17]
Internet-Draft 4rd-U Architectural Comments April 2012
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[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.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
Chen Expires October 12, 2012 [Page 18]
Internet-Draft 4rd-U Architectural Comments April 2012
Author's Address
Maoke Chen
FreeBit Co., Ltd.
13F E-space Tower, Maruyama-cho 3-6
Shibuya-ku, Tokyo 150-0044
Japan
Email: fibrib@gmail.com
Chen Expires October 12, 2012 [Page 19]
