Internet DRAFT - draft-van-beijnum-shim6-suppress-header
draft-van-beijnum-shim6-suppress-header
Shim6 Working Group I. van Beijnum
Internet-Draft June 19, 2006
Expires: December 21, 2006
Suppressing the Shim6 Header
draft-van-beijnum-shim6-suppress-header-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The shim6 protocol defines a header that contains a "context tag" that
identifies packets as belonging to a certain shim6 context that exists
between two hosts. It has been suggested that this shim6 header is
inserted between the IPv6 header and the upper layer protocol such as
TCP in all packets where the shim layer has rewritten the source and/or
destination address. This document considers the suppression of this
header in situations where packets can be successfully demultiplexed by
the receiver without it.
1 Introduction
Including the shim6 header in all packets where one or both addresses
are rewritten has the advantage of simplicity and predictability. When
Van Beijnum Expires December 21, 2006 [Page 1]
Internet-Draft Suppressing the Shim6 Header June 2006
addresses are only rewritten when there is a failure, only relatively
few packets will contain this header, so the impact of the additional
overhead introduced is quite limited. However, on more than one
occasion, the operational community has stressed the importance of
traffic engineering: the practice of using multihoming techniques to
obtain a more desirable distribution of incoming and outgoing traffic
over the external connections available to a multihomed site. Since the
initial source and destination address in any communication session are
chosen by the host initiating the session with no mechanisms available
to consider traffic engineering needs, and because traffic engineering
can't be very successful if it's only applied when sessions start, the
use of traffic engineering regularly requires moving traffic that is
flowing through external connection over to another external connection.
With shim6 as a multihoming solution, this means that the source and/or
destination address must be rewritten. As suggested until now, this
would require inserting the shim header in the affected packets,
increasing their size slightly.
As defined currently in [SHIMPROTO], the shim6 header in data packets is
8 bytes. This increases the typical overhead of TCP with a 1280 byte MTU
from 180 bytes for 2440 bytes of data (two full-size 1280 byte data
packets and one acknowledgment, all with 60 bytes of IPv4 and TCP
overhead) to 204 bytes for 2424 bytes (68 bytes overhead per packet: 40
bytes IPv6 header, 8 bytes shim6 header and 20 bytes TCP header). This
is an increase from 7.4% to 8.4% overhead in the best case. If the
average packet size is smaller (which is typically the case on the
internet), the overhead and the increase in overhead are larger.
The author is of the opinion that such an increase in overhead on top of
the increase in overhead incurred by IPv6 in general over IPv4, makes
the shim6 multihoming solution less attractive, so it's worthwhile to
try and suppress the shim6 header where possible.
2 Demultiplexing
The main issue with suppressing the shim6 header is how to demultiplex
packets that have one or both addresses rewritten by the shim layer. Two
ways are suggested for this:
1. Equivalent locators per ULID
2. Transport demultiplexing
In the first case, rather than having two or more addresses which may
all function as either ULIDs or locators, a host has an ULID in every
relevant prefix, and then separate locator addresses that are uniquely
tied to a specific ULID in all other prefixes. For instance, a host with
prefixes A and B could have ULIDs A::1 and B::2, where B::1 is a locator
for ULID A::1 and A::2 a locator for ULID B::2. This means that whenever
Van Beijnum Expires December 21, 2006 [Page 2]
Internet-Draft Suppressing the Shim6 Header June 2006
a packet is received on a locator address, it's immediately obvious that
this is a packet with the destination address rewritten and the
destination address can be trivially rewritten. When the source address
was rewritten by a host using an equivalent locator, the source address
will match a locator address previously learned from a shim
correspondent, so this can be rewritten into the original ULID as well.
Alternatively, a host may be able to demultiplex a packet based on the
source and destination addresses (which may or may not have been
rewritten) along with upper layer multiplexing information such as the
TCP or UDP port number. However, this will only work when the sessions
between two hosts don't reuse upper layer demultiplexing information, so
the host sending packets must keep track of this information to make
sure this continues to be the case, and only suppress the shim header as
long as session uniqueness persists.
3 Capabilities exchange
In general, demultiplexing can only be successful when certain criteria
are met on both the originating and receiving host, so it's necessary to
communicate shim suppression capabilities between two hosts. For this
purpose, a modification to [SHIMPROTO] is suggested where each host
announces a group of at least eight flags to the remote host when
negotiating a shim context. Each flag is one bit, with the following
meaning:
Bit 0: Always suppress shim6 header
Bit 1: Equivalent locators per ULID supported
Bit 2: Transport demultiplexing supported
Bit 3 and higher: reserved for future use, MUST be 0 when sent
and ignored when received
When bit 0 is set, the host indicates that it knows how to demultiplex
packets belonging to the shim context being negotiated under all
circumstances, so the sender MUST NOT add a shim header to these
packets.
However, in most cases (as outlined earlier) the cooperation of the
sender is required to make sure that multiplexing can be done
successfully, so when bit 0 is set to zero, the shim6 header may only be
suppressed when the hosts involved have at least one capability in
common. If there is any doubt, the shim6 header MUST NOT be suppressed.
It has been suggested that the shim6 header suppression capability could
be added as an extension rather than include it from the start. The
author believes that would be a mistake, because it requires support for
Van Beijnum Expires December 21, 2006 [Page 3]
Internet-Draft Suppressing the Shim6 Header June 2006
both the case where the suppression capability (or at least its
negotiation) is present and the case where the suppression capability
isn't present. Also, it's a lot harder to go back and add a feature than
it is to include it from the ground up. As such, it's unlikely that the
suppression capability will be present in enough hosts to warrant the
effort unless it's present from the start. The complexity of adding the
minimum support required functionality is extremely modest: the hosts
must exchange a set of flags, and a host must suppress the shim header
when bit 0 is set. All other capabilities are optional.
4 Security Considerations
Suppression of the shim header makes it easier for an attacker to inject
packets with rewritten source/destination addresses into the
communication between two hosts because this way, the attacker doesn't
have to guess the context tag. However, since an attacker could also
easily inject packets that don't have their addresses rewritten, either
in the presence of the absence of the shim protocol, this doesn't open
up previously non-existing attack vectors.
Firewalls and other middleboxes will have to implement the header
suppression capabilities as well if they want to track shim6 use
successfully.
5 IANA Considerations
When shim header suppression is rolled into the shim protocol document,
the IANA will be asked to open a registry for capabilities flags.
6 References
[SHIMPROTO] E. Nordmark and M. Bagnulo, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-05 (work in progress),
May 2006.
7 Document and Author Information
This document expires December, 2006. The latest version will always be
available at http://www.muada.com/drafts/. Please direct questions and
comments to the shim6 mailinglist or directly to the author:
Iljitsch van Beijnum
Email: iljitsch@muada.com
Van Beijnum Expires December 21, 2006 [Page 4]
Internet-Draft Suppressing the Shim6 Header June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Van Beijnum Expires December 21, 2006 [Page 5]
