Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in May 2001 November 16, 2000 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 current IPv6 specification [1] is not very clear about destination option headers and is very hard to implement. For instance the advanced API [2] has to artificially limit the freedom in header placement in order to make it trackable. The purpose of this document is to propose a simpler to understand and easier to implement specification for some particular points, mainly for destination option headers which will be heavily used for mobility [3]. 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 ... draft-dupont-destoptupd-00.txt [Page 1] INTERNET-DRAFT IPv6 destination option header clarification Nov 2000 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 [4]. 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 [5] 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. There are four problems with this: - the IPComp IPsec header [6] 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 [3] and tunnel encapsulation limit [7] destination option, the good location is between the routing header and the fragment header - to have more than possible location for a header of the same type gives too complex implementations and this is the case for the destination option header. draft-dupont-destoptupd-00.txt [Page 2] INTERNET-DRAFT IPv6 destination option header clarification Nov 2000 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 ([5], 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. New types for destination option headers Destination option header processing is hard with two different locations with different meanings. With three the situation becomes too complex then we propose to use a different type for two of the three locations: - the before routing header location (note 1) will be named the Intermediate Destination Options header and should get a new type from IANA if there is a consensus to keep it - the between routing and fragment header (new one) will keep the Destination Options header name and type - the after IPsec headers will be named the Final Destination Options header and should get a new type from IANA. 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 intermediate destination option headers. draft-dupont-destoptupd-00.txt [Page 3] INTERNET-DRAFT IPv6 destination option header clarification Nov 2000 6. Per-option rationale If an option cannot occur in an option header and is found in it then it MUST be considered as unrecognized. Pad1: can occur in any option header PadN: can occur in any option header Jumbo Payload: can occur only in the hop-by-hop option header NSAP Address: can occur only in the destination and the final destination option header Tunnel Encapsulation Limit: can occur only in the destination option header Router Alert: can occur only in the hop-by-hop option header Binding Update: can occur only in the final destination option header Binding Acknowledgment: can occur only in the final destination option header Binding Request: can occur only in the final destination option header Home Address: can occur only in the destination option header Endpoint Identification: we don't know, seems to be the same than for NSAP Address. 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. This issue should be addressed by the revised IPComp specification. 8. Acknowledgements 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 becomes a nightmare. Mohan Parthasarathy and Robert Elz convinced me (by very different way) the issue must be addressed as soon as possible. Brian Zill explained the mutable option issue and Vladislav Yasevich proposed the Intermediate name. draft-dupont-destoptupd-00.txt [Page 4] INTERNET-DRAFT IPv6 destination option header clarification Nov 2000 9. References [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, February 1998. [3] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-13.txt, November 2000. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [6] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998. 10. 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 16, 2000) draft-dupont-destoptupd-00.txt [Page 5]