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]