Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in May 2002 November 13, 2001 IPv6 destination option header clarification Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract The IPv6 specification [1] defines a header chain with two kinds of headers, non-terminal and terminal. Two non-terminal headers can carry options and one is very specialized for hop-by-hop processing so the destination option header is used for many purposes, including some not considered in [1] like mobility [2]. This conflicts with the current advanced API [3] but the issue was solved at 49th IETF meeting [4] during the presentation of the first version of this document so the next advanced API should be able to support the "flexibility to allow new uses as new applications are conceived/developed". The purpose of this document is summary this discussion and to clarify any point to explicitly stated in [1]. draft-dupont-destoptupd-01.txt [Page 1] INTERNET-DRAFT IPv6 destination option header clarification Nov 2001 1. Terminology This document will heavily use the order of headers, the IPv6 header will be the first header, a hop-by-hop header can come "after" (or the IPv6 header is "before" the hop-by-hop header). The first item will be at the top of a list: IPv6 header Hop-by-hop Option header ... All the headers before the last one are intermediate or (better) non-terminal headers. The last one is final or upper layer or (better) terminal. The (non-)terminal property is an intrinsic property of a header type. The keywords "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 [5]. 2. Problems with current specification The current specification states that the order SHOULD be: IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. note 3: for options to be processed only by the final destination of the packet. (note 2 says that IPsec specification [6] does additional recommendation about the relative order of IPsec headers) The only restriction is the hop-by-hop option header can occur only once and just after the IPv6 header. draft-dupont-destoptupd-01.txt [Page 2] INTERNET-DRAFT IPv6 destination option header clarification Nov 2001 There are four problems with this: - the IPComp IPsec header [7] was forgotten - a destination option header at the note 1 placement makes no sense if there is no routing header, ie. a routing header MUST occur after a note 1 destination option header - for home address [2] and tunnel encapsulation limit [7] destination option, the good location is between the routing header and the fragment header - the current advanced API has no support for not listed here position of a header, for instance for the previous item. 3. Why a new location for destination option header Any header or option which modifies the source or destination address of a packet (ie. routing header and home address option) MUST be before IPsec headers because of processing rules of inbound IPsec headers ([6], section 5.2.1): - the destination address is used for the Security Association lookup - the source address can be used for the Security Association selector check. The home address option is for the final destination then the note 1 location does not apply to it (ie. it SHOULD be after routing header). In order to be firewall-friendly the home address option SHOULD be in every fragments then the good location is between the routing header (if any) and the fragment header (if any). The tunnel encapsulation limit SHOULD be available to any encapsulator device in any fragment in order to apply the limit when it is reached. 4. Conflict resolution At the 49th IETF meeting [4] the authors of the IPv6 specification stated that it is "important to keep flexibility to allow new uses as new applications are conceived/developed" so a new application MAY specify a new header order and the advanced API MUST support it. So the introduction of a new location for destination option header with a home address option is legitimate. draft-dupont-destoptupd-01.txt [Page 3] INTERNET-DRAFT IPv6 destination option header clarification Nov 2001 5. Rationale for mutable options It does not make sense to put a mutable option after the (last) routing header (because nothing should change it) and to allow mutable options after a IPsec header makes IPsec processing too complex. Note there is no defined mutable options today. Then we propose to add a mandatory behavior in new mutable option definition for misplaced cases, for instance reject the packet (ie. raise an error) or deal with the option as immutable (ie. ignore the mutable flag after a IPsec header). A new mutable option SHOULD be in the hop-by-hop or in the note 1 destination option headers. 7. Security Considerations Processing rules of inbound IPsec headers makes mandatory to have the home address destination option before any IPsec header. IPComp can use or not use an IPComp Association then in some situations (no IPComp Association and no other IPsec header) the IPsec header rule does not apply. But the new IPComp specification strongly suggests that the compression SHOULD NOT hide the home address, i.e. the IPComp header SHOULD be after the destination option header with the home address option. 8. IANA Considerations Any document specifying a new option SHOULD state the kind of headers and the possible positions of headers which carry it. If the option is mutable, this recommendation becomes a requirement (a MUST). 9. Acknowledgments My MobiSecV6 colleagues who developed IPv6 and mobile IPv6 support for a commercial firewall first showed the need for a new destination option header location. Charles Perkins refound the idea for the mobile IPv6 protocol. At the ETSI bake-off, IPv6 implementors complained that the destination option header processing was not clear enough. Mohan Parthasarathy and Robert Elz convinced me (by very different way) the issue had to be addressed as soon as possible. Brian Zill explained the mutable option issue. Steve Deering clearly stated how apparent conflicts with the IPv6 specification and the advanced API should be solved. draft-dupont-destoptupd-01.txt [Page 4] INTERNET-DRAFT IPv6 destination option header clarification Nov 2001 10. Normative References [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. 11. Informative References [2] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2001. [3] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, February 1998. [4] R. Hinden, S. Deering, "IPng Meeting Minutes", San Diego, IETF, 13-14 December 2000. http://www.ietf.org/proceedings/00dec/00dec-53.htm 12. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr Expire in 6 months (May 13, 2002) draft-dupont-destoptupd-01.txt [Page 5]