Internet DRAFT - draft-dupont-destoptupd
draft-dupont-destoptupd
Internet Engineering Task Force Francis Dupont
INTERNET DRAFT ENST Bretagne
Expires in May 2001 November 16, 2000
IPv6 destination option header clarification
<draft-dupont-destoptupd-00.txt>
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]
