IETF Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
15 April 2002 Francis Dupont
ENST Bretagne
Nonfinal Mobility Header for Mobile IPv6
draft-ietf-mobileip-piggyback-00.txt
Status of This Memo
This document is a submission by the IETF Mobile IP Working Group
Working Group of the Internet Engineering Task Force (IETF).
Comments should be submitted to the mobile-ip@sunroof.eng.sun.com
mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This document specifies operations to allow inclusion of data along
with a mobility header (from Mobile IPv6) containing a Binding Update
or Binding Acknowledgement message. In this way, smoother handovers
and reduced jitter and bandwidth utilization can be achieved.
Interactions with IPsec-based verification of mobility messages are
described; basically, establishment of such IPsec-based methods
preclude the use of the mobility header specified in this document,
unless simple modifications to IPsec (outside the scope of this
document) can be utilized.
Perkins, Dupont Expires 15 November 2002 [Page i]
Internet Draft Nonfinal Mobility Header 15 April 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Nonfinal Mobility Message Header Format 3
4. Operation and Use of the Nonfinal Mobility Header 3
4.1. Rules for the Sender . . . . . . . . . . . . . . . . . . 3
4.2. Rules for the Correspondent Node . . . . . . . . . . . . 3
5. ICMP Payload Inclusion Control Message 4
6. IANA Considerations 4
7. Security Considerations 5
8. Acknowledgement 5
References 5
A. Requesting Isolation of Payload and Mobility Headers 6
B. Table of Nonfinal and Final Mobility Header vs IPsec-based
Security 7
C. Mobility Signals Which May be Included with Payload 8
Addresses 9
1. Introduction
When a mobile node moves to a new point of attachment, it can use
a Mobile IPv6 Binding Update message [3] to supply a new care-of
address to a correspondent node. This information can conveniently
be located in the same packet as data which the mobile node may be
already transmitting towards the correspondent node. In this way,
smoother handovers and reduced jitter and bandwidth utiliziation can
be achieved.
Perkins, Dupont Expires 15 November 2002 [Page 1]
Internet Draft Nonfinal Mobility Header 15 April 2002
Such operation has been described in Mobile IPv6 specifications until
recently, when concerns about IPsec policy ambiguity led to a more
restrictive approach towards verifying the authentication data in
the Mobility Header. Basically, establishment of such IPsec-based
security associations for verifying authentication data precludes
the use of the mobility header specified in this document, unless
simple modifications to IPsec (outside the scope of this document)
can be utilized. Some suggestions for possible improvements to
IPsec are included in an appendix, along with descriptions of other
interactions with IPsec-based verification of mobility messages.
The requirement is to use of two new header types: one extension
header that can be placed before a transport header, and one final
header type to enable use of IPsec for verifying authentication
data. Since an extension header cannot be protected according
to the strictest interpretation of RFC 2401 [4], and the final
header type is considered as transport, there is no requirement for
changing IPsec at all in any node, peer or intermediate. Since
these two headers have an identical format, the effect on mobility
implementation is minimal.
A node (HA, MN, or CN) MAY request that a sender always send mobility
control information without data, by indicating "No Piggybacking"
whenever the underlying security association is established (see
section 5). For the return-routability messages specified in in the
base Mobile IPv6 draft [3], this information can be supplied as a
option to the Home Address Test message sent back to the mobile node.
An implementation can have a policy which by default allows
piggybacking, by means of static configuration. If there is any
non-IPsec reason why the node cannot use the Nonfinal Mobility
Header, the default policy can be disabled by a management interface
to the policy. If IPsec is used, this default behavior must be
disabled.
2. Terminology
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 [1]. This
section defines other terminology used that is not already defined
in [3].
Piggybacking
The insertion of two packets from separate message flows or
sessions is often called "piggybacking". In this document,
Perkins, Dupont Expires 15 November 2002 [Page 2]
Internet Draft Nonfinal Mobility Header 15 April 2002
piggybacking refers to the insertion of a nonfinal Mobility
Header into an IPv6 packet that also contains payload.
3. Nonfinal Mobility Message Header Format
The format of the Nonfinal Mobility Header is identical to the
format of the final Mobility Header specified in Mobile IPv6 [3].
In this document, only message types for Binding Update, Binding
Acknowledgement, and Binding Request are specified as allowable types
for the Nonfinal Mobility Header.
4. Operation and Use of the Nonfinal Mobility Header
The basic rule is simple:
- If there is an IPsec security association which is established to
create verification data for binding cache messages, no payload
may be sent along with any binding cache message. Use the
"final" Mobility Header.
- Otherwise, payload MAY be sent. To do so, use the Nonfinal
Mobility Header specified in section 3, along with the Binding
Authentication Data option from [3], to validate the message.
The following subsections detail any necessary elaboration to the
above rule.
4.1. Rules for the Sender
The basic rule applies, except that:
If the correspondent node has requested that no payload
be included in packets containing a Mobility Header, then
the mobile node MUST NOT do so. However, the mobile node
MAY still Use the Nonfinal Mobility Header along with the
Binding Authentication Data option, with empty payload.
4.2. Rules for the Correspondent Node
For the most part, the correspondent node just follows the basic rule
for any IPv6 extension header [2]. If there exists an IPsec-based
security association that is to be used when validating binding cache
messages, the Nonfinal Mobility Header MUST be ignored, and any
payload processed just as if the Mobility Header were not present.
Perkins, Dupont Expires 15 November 2002 [Page 3]
Internet Draft Nonfinal Mobility Header 15 April 2002
If a correspondent node receives a Nonfinal Mobility Header with
payload, and if for any reason it would prefer to have the payload
received in separate packets, the correspondent node SHOULD send an
ICMP "Piggybacking Control" message back to the mobile node (see
section 5). However, in this case, the correspondent node MUST
NOT drop the packet. Processing for the contents of the Nonfinal
Mobility Header is governed by the basic rule, not the existence or
absence of payload.
5. ICMP Payload Inclusion Control Message
This specification introduces a new ICMP message type, for use when a
correspondent node would prefer to control the inclusion of payload
with the Nonfinal Mobility Header.
The ICMP "Payload Inclusion Control" has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is TBD. The Reserved field is sent as zero, and
ignored on reception. The Code field can have two valued:
0 Payload MAY be sent following the Nonfinal Mobility
Header
1 Payload MUST NOT be sent following the Nonfinal Mobility
Header
See appendix A for discussion about conditions under which a
correspondent node might utilize such a feature.
6. IANA Considerations
This specification reserves one extension header number for the
Nonfinal Mobility Header (see section 3).
This specification also reserves one ICMP number for the "Payload
Inclusion Control" ICMP message (see section 5).
Perkins, Dupont Expires 15 November 2002 [Page 4]
Internet Draft Nonfinal Mobility Header 15 April 2002
7. Security Considerations
This document describes a protocol extension header which allows for
interoperation with IPsec such that the IPsec selector granularity
requirement for protecting mobility signaling by IPsec headers can be
expressed in a policy.
A protocol number reserved as the end header allows for this with
IPsec while the other protocol number allows for use of the Nonfinal
Mobility Header for those times when there is no IPsec security
association governing the validation of binding cache messages. The
cache signaling is then protected by the non-IPsec method used with
route optimization.
Hence, the proposal solves the ambiguity problem that is result of
having only a single IPsec header available to protect both the
payload and the mobility cache management signaling. Furthermore,
this proposal enables a very strict interpretation of the clause [4]
which requires that IPsec policy selection be made only on the basis
of the final IP header type -- which is often the transport header.
When IPsec is to be used to validate binding cache messages, even
the strict interpretation allows IPsec to be used, as long as the
relevant message data resides in a final header as is specified
in [3]. However, some implementations would no longer allow payload
with the IPsec-protected mobility cache signaling. This proposal
solves that problem.
8. Acknowledgement
Appendices B and C were written by Vijay Devarapalli and Jari
Malinen, who also provided valuable comments on the other parts of
this draft.
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[3] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force,
March 2001.
Perkins, Dupont Expires 15 November 2002 [Page 5]
Internet Draft Nonfinal Mobility Header 15 April 2002
[4] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. Request for Comments (Proposed Standard) 2401,
Internet Engineering Task Force, November 1998.
A. Requesting Isolation of Payload and Mobility Headers
In this discussion, a few fundamental principles should be kept in
mind:
- IP has a MTU which is far larger than the typical capacity of a
radio bearer channel. Thus, in order to be IPv6 compliant, the
device driver for the bearer channel MUST be able to transmit
larger packets, presumably by a link-layer adaptation that
fragments and reassembles bearer frames.
Consequently, requirements related to packet sizing should
logically be considered as part of a "IP-over-foo" specification,
and neither part of the base Mobile IPv6 specification, nor this
specification. The "piggybacking" ICMP message are provided
merely for convenience.
- IP typically does not distinguish between the delivery of data
and control information. Expectations that binding cache control
information will be delivered out of band, represent assumptions
which can only be satisfied for particular systems. Again, the
logical place to specify protocol details that can enable such
expectations to be met, would be in a separate "IP-over-foo"
specification.
- If there is a "flow" which needs a certain reserved capacity
in order to achieve acceptable performance, then the natural
solution for meeting that need should involve a Quality
of Service negotiation for that flow, along with admission
control, and then the subsequent traffic shaping, conditioning,
and charging. Any expectation that a specific kind of data
will be the only allowable data that can flow over a radio
bearer channel, represents an unwarranted restriction that
should not persist in any generic IPv6 protocol specification.
Considerations which are unique for particular platforms or media
belong in separate "IP-over-foo" specifications.
It is expected that Mobile IPv6 will be deployed in systems that
carry voice data over such constrained radio bearer channels. In
this situation, it could be that the bearer channel is engineered
to fit the size of the voice data, and any extra data might cause
unintended effects. For convenience, the receiver (i.e., the
correspondent node) might then send an ICMP "Piggybacking Control"
to the transmitter (i.e., the mobile node), in order to forestall
Perkins, Dupont Expires 15 November 2002 [Page 6]
Internet Draft Nonfinal Mobility Header 15 April 2002
this possibility. The binding cache management information would
then presumably be delivered to the mobile node either during a time
when no voice data was available, or over an alternate channel. This
introduces nontrivial timing dependencies. In partcular, the mobile
node SHOULD NOT blindly send out Binding Update messages to all
correspondent nodes on its Binding List unless there is a reasonable
expectation that the correspondent node will be sending data to the
mobile node before the mobile node moves to yeat another point of
attachment to the Internet. Furthermore, a method is needed by which
the mobile node can determine whether the mobility signaling, or
the application payload data, has priority for transmission to the
correspondent node, in cases where the mobile node does have some
data to send.
Another possibility would be to allow the correspondent node to
instruct the mobile node about its needs for future binding cache
message handling by way of conditioning applied to the establishment
of the security association by which the binding messages are to
be validated. This method suffers from the disadvantage that the
isolation of binding cache messages and payload is no longer able to
be dynamically controlled.
B. Table of Nonfinal and Final Mobility Header vs IPsec-based Security
In order to include cache management signaling along with payload
when IPsec is in use, we have cases 1-4 in Table 1. We assume
the current IPsec selectors [4] and two mobility header types for
mobility signals: a final header (as defined in [3]), and a nonfinal
extension header (as defined in section 3). The node having IPsec
policies (controlling the insertion of an AH or ESP header) can
use the nonfinal extension header in cases 1 and 2, that is, when
mobility signaling does not have an IPsec policy.
Table 1: Nonfinal Mobility Header Inclusion with IPsec
IPsec policy for IPsec policy
Mobility Message for Payload Can piggyback?
1. no no | yes
2. no yes | yes
3. yes no | no
4. yes yes | no
In order for the mobility signaling to enforce this, the mobility
code of a sender needs to know the nature of the security policy
which controls mobility signaling. The easiest way to do this is
to record the information for use within the mobility processing,
Perkins, Dupont Expires 15 November 2002 [Page 7]
Internet Draft Nonfinal Mobility Header 15 April 2002
at the time the security association is set up for this purpose.
That is very natural, since the security association is itself
established for mobility management. In unforeseen cases where no
such records-keeping is possible, an implementation can make the
determination even after the security association is set up, as
follows. First, construct a mobility signaling packet, making the
header type final and causing a kernel IPsec policy lookup, in the
same way as a non-mobility kernel would do. IPsec already does this
for any packet. If no policy exists, the final header type MAY be
changed to an extension one to indicate that this signal can be
piggybacked. If a policy was found, the final header type MUST be
used.
A receiver needs no knowledge of mobility in its IPsec processing.
The header type determines whether a policy even can exist. If the
header is final and no policy exists, or a wrong policy exists, the
packet will be transparently rejected by IPsec. If the header is
an extension header, the header type determines that this signal
cannot have an IPsec policy. Whether it accepts the extension header
depends on policy of the non-IPsec protection.
Piggybacking is not possible on case 3, due to processing
difficulties at both the sender and the receiver. The scan for
transport protocol field as described in [4] does not allow for such
a mode. For case 4, conflicting IPsec policies make it impossible to
piggyback.
Putting the above together, the sender MAY piggyback for the cases
1 and 2 in Table 1 and MUST NOT piggyback for cases 3 and 4. This
leads directly to the basic rule formulated in section 4.
C. Mobility Signals Which May be Included with Payload
An implementation sends mobility signaling piggybacked when its
negotiation result with the peer allows and if it makes sense for the
mobility signal in question.
Mobility message types include binding cache management
messages (BU/BAck/BR) and the return routability test messages
(HoTI/HoT/CoTI/CoT). Piggybacking of BU/BAck messages between the
mobile node and its home agent is very rare, since the mobile node
rarely has any payload for the home agent other than the Binding
Update itself. However, the home agent MAY wish to include a
Binding Request message along with a Router Advertisement in order to
facilitate renumbering. Table 2 describes when a mobility signal can
be included with the payload to be sent between a mobile node (MN)
and a correspondent node (CN).
Perkins, Dupont Expires 15 November 2002 [Page 8]
Internet Draft Nonfinal Mobility Header 15 April 2002
"Maybe" indicates that piggybacking would be sometimes possible
(details in the design team writeup).
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Megisto Corp.
6000 Connection Dr. Suite 120
20251 Century Blvd
Irving, TX. 75039 Germantown MD 20874
USA USA
Phone: +1 972-894-6709 Phone: +1 847-202-9314
Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com
Questions about this memo can also be directed to the authors:
Charles E. Perkins Francis Dupont
Communications Systems Lab ENST Bretagne
Nokia Research Center Campus de Rennes
313 Fairchild Drive 2, rue de la Chataigneraie
BP 78
Mountain View, California 94043 35512 Cesson-Sevigne Cedex
USA FRANCE
Phone: +1-650 625-2986
Fax: +1 650 625-2502 Fax: +33 2 99 12 70 30
EMail: charliep@iprg.nokia.com Francis.Dupont@enst-bretagne.fr
Perkins, Dupont Expires 15 November 2002 [Page 9]
Internet Draft Nonfinal Mobility Header 15 April 2002
Table 2: Mobility Signals and Piggybacking, Assuming No IPsec Policy
Controlling Verification of Mobility Messages
Mobility Message Type Sndr Rcvr Piggyback?
--------------------- ---- ---- ----------
BU (Binding Update) MN CN Yes
BAck (Binding Acknowledgment) CN MN Yes
BR (Binding Request) CN MN Yes
Home Address Test Initiate MN CN Maybe
Home Address Test CN MN No
Care-of Address Test Initiate MN CN Maybe
Care-of Address Test CN MN No
Perkins, Dupont Expires 15 November 2002 [Page 10]
