draft-ietf-seamoby-ctp-07.txt   draft-ietf-seamoby-ctp-08.txt 
Seamoby WG J. Loughney (editor) Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri Internet Draft M. Nakhjiri
Category: Experimental C. Perkins Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-07.txt> R. Koodli <draft-ietf-seamoby-ctp-08.txt> R. Koodli
Expires: July 13, 2004 January 13, 2004 Expires: July 21, 2004 January 21, 2004
Context Transfer Protocol Context Transfer Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 8 skipping to change at page 2, line 8
This document presents a context transfer protocol that enables This document presents a context transfer protocol that enables
authorized context transfers. Context transfers allow better support authorized context transfers. Context transfers allow better support
for node based mobility so that the applications running on mobile for node based mobility so that the applications running on mobile
nodes can operate with minimal disruption. Key objectives are to nodes can operate with minimal disruption. Key objectives are to
reduce latency, packet losses and avoiding re-initiation of signaling reduce latency, packet losses and avoiding re-initiation of signaling
to and from the mobile node. to and from the mobile node.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1 Conventions Used in This Document 1.1 The Problem
1.2 Abbreviations Used in the Document 1.2 Conventions Used in This Document
1.3 Abbreviations Used in the Document
2. Protocol Overview 2. Protocol Overview
2.1 Context Transfer Scenarios 2.1 Context Transfer Scenarios
2.2 Context Transfer Packet Formats 2.2 Context Transfer Packet Formats
2.3 Context Types 2.3 Context Types
2.4 Context Data Block 2.4 Context Data Block
2.5 Messages 2.5 Messages
3. Transport, Reliability and Retransmission of Feature Data 3. Transport, Reliability and Retransmission of Feature Data
4. Error Codes 4. Open Issues
4.1 Failure Handling
5. Examples and Signaling Flows 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 5.1 Network controlled, Initiated by pAR
5.2 Network controlled, Initiated by nAR 5.2 Network controlled, Initiated by nAR
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3 Mobile controlled, Predictive New L2 up/old L2 down
6. Security Considerations 6. Security Considerations
7. IANA Considerations 7. IANA Considerations
7.1 Context Profile Types Registry
8. Acknowledgements 8. Acknowledgements
9. References 9. References
9.1 Normative References 9.1 Normative References
9.2 Non-Normative References 9.2 Non-Normative References
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Appendix B. Multicast Listener Context Transfer Appendix B. Multicast Listener Context Transfer
Author's Addresses Author's Addresses
1. Introduction 1. Introduction
skipping to change at page 8, line 6 skipping to change at page 8, line 6
| Cxt-Type | Length |P| Feature Profile Type (FTP) | | Cxt-Type | Length |P| Feature Profile Type (FTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) | | Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ data + + data +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cxt-Type Single octet, defined by IANA Cxt-Type Single octet, defined by IANA
Length message length in octets Length message length in units of 8
octet words
'P' bit 0 = No presence vector 'P' bit 0 = No presence vector
1 = Presence vector present. 1 = Presence vector present.
FPT 16 bit integer, listing the feature profile FPT 16 bit integer, listing the feature profile
type contained in the data field. type contained in the data field.
data Context type-dependent data, whose length is data Context type-dependent data, whose length
is defined by the Length Field. If the data is defined by the Length Field. If the data
is not 64-bit aligned, the data field is is not 64-bit aligned, the data field is
padded with zeros. padded with zeros.
The Cxt-Type indicates the type of the feature context message itself The Cxt-Type indicates the type of the feature context message itself
(such as QoS Context Request, QoS Context Transfer etc.), and Feature (such as QoS Context Request, QoS Context Transfer etc.), and Feature
Profile Type (FPT) identifies the way the particular feature context Profile Type (FPT) identifies the way the particular feature context
is organized. The 'P' bit specifies whether or not the "presence is organized. The 'P' bit specifies whether or not the "presence
vector" is used. When the presence vector is in use, the Presence vector" is used. When the presence vector is in use, the Presence
Vector is interpreted to indicate whether particular data fields are Vector is interpreted to indicate whether particular data fields are
skipping to change at page 9, line 51 skipping to change at page 9, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) | | Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) | | Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTAR = 1 Type CTAR = 1
Length message length in octets Length message length in units of 8
octet words
MN's IP Address Field contains either: MN's IP Address Field contains either:
IPv4 Address as defined in [RFC 791]. IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373]. IPv6 Address as defined in [RFC 2373].
nAR / pAR IP Address Field contains either: nAR / pAR IP Address Field contains either:
IPv4 Address as defined in [RFC 791]. IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373]. IPv6 Address as defined in [RFC 2373].
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to zero
by the MN. by the MN.
skipping to change at page 11, line 22 skipping to change at page 11, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP address | | Mobile Node's Previous IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved | | FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTAR = 2 Type CTAR = 2
Length message length in octets Length message length in units of 8
octet words
Reserved Reserved for future use. Must be set to Reserved Reserved for future use. Must be set to
zero by the sender of CTAA Message, i.e. zero by the sender of CTAA Message, i.e.
pAR or nAR. pAR or nAR.
'V' flag When set to '00', indicate presence of IPv6 'V' flag When set to '00', indicate presence of IPv6
Previous (New) address only. Previous (New) address only.
When set to '01' indicate presence of IPv4 When set to '01' indicate presence of IPv4
Previous (New) Address only. Previous (New) Address only.
When set to '10' indicate presence of both When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses. IPv6 and IPv4 Previous (New) addresses.
MN's Prev IP Address Field contains either: MN's Prev IP Address Field contains either:
IPv4 Address as defined in [RFC 791]. IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373]. IPv6 Address as defined in [RFC 2373].
FPT 16 bit integer, listing the FTP that FPT 16 bit integer, listing the FTP that was not
was not Successfully transferred. Successfully transferred.
Status Code An octet, containing failure reason. Status Code An octet, containing failure reason.
2.5.3 Context Transfer Data (CTD) Message 2.5.3 Context Transfer Data (CTD) Message
Sent by pAR to nAR, and includes feature data (CTP data). This Sent by pAR to nAR, and includes feature data (CTP data). This
message should handle predictive as well as normal CT. An message should handle predictive as well as normal CT. An
acknowledgement flag, A, included in this message indicates whether a acknowledgement flag, A, included in this message indicates whether a
reply is required by pAR. reply is required by pAR.
skipping to change at page 12, line 37 skipping to change at page 12, line 39
'V' flag When set to '00', indicate presence of IPv6 'V' flag When set to '00', indicate presence of IPv6
Previous (New) address only. Previous (New) address only.
When set to '01' indicate presence of IPv4 When set to '01' indicate presence of IPv4
Previous (New) Address only. Previous (New) Address only.
When set to '10' indicate presence of both When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses. IPv6 and IPv4 Previous (New) addresses.
'A' bit The MN requests an acknowledgement. 'A' bit The MN requests an acknowledgement.
Length message length in octets Length message length in units of 8
octet words
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to
by the pAR. zero by the pAR.
Elapsed Time The number of milliseconds since the Elapsed Time The number of milliseconds since the
transmission of the first CTD message. transmission of the first CTD message.
MN's Prev CoA Address Field contains either: MN's Prev CoA Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
IPv6 Address as defined in [RFC 2373]. IPv6 Address as defined in [RFC 2373].
MN's New CoA Address Field contains either: MN's New CoA Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
IPv6 Address as defined in [RFC 2373]. IPv6 Address as defined in [RFC 2373].
This is only applicable for the PCTD
This is only applicable for the PCTD message. message.
Algorithm Algorithm for carrying out the computation Algorithm Algorithm for carrying out the computation
of the MN Authorization Token. Currently only of the MN Authorization Token. Currently
one algorithm is defined, HMAC_SHA1 = 1. only 1 algorithm is defined, HMAC_SHA1 = 1.
Key Length length of key, in octets. Key Length Length of key, in octets.
When CTD is sent predictively, the supplied parameters including the When CTD is sent predictively, the supplied parameters including the
algorithm, key length and the key itself, allow nAR to compute a algorithm, key length and the key itself, allow nAR to compute a
token locally and verify against the token present in the CTAR token locally and verify against the token present in the CTAR
message. This message MUST be protected by IPsec. message. This message MUST be protected by IPsec.
As described previously, the algorithm for carrying out the As described previously, the algorithm for carrying out the
computation of the MN Authorization Token is HMAC_SHA1. The input computation of the MN Authorization Token is HMAC_SHA1. The input
data for computing the token are: the MN's Previous IP address, the data for computing the token are: the MN's Previous IP address, the
FPT objects and the Replay field. When support for transferring all FPT objects and the Replay field. When support for transferring all
skipping to change at page 13, line 45 skipping to change at page 13, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP Address | | Mobile Node's Previous IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved | | FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....... | | ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTDR = 5 (Context Transfer Data) Type CTDR = 5 (Context Transfer Data)
Length message length in octets Length Message length in units of 8
octet words
'V' flag When set to '00', indicate presence of IPv6 'V' flag When set to '00', indicate presence of IPv6
Previous address only. Previous address only.
When set to '01' indicate presence of IPv4 When set to '01' indicate presence of IPv4
Previous Address only. Previous Address only.
When set to '10' indicate presence of both When set to '10' indicate presence of both
IPv6 and IPv4 Previous addresses. IPv6 and IPv4 Previous addresses.
'S' bit When set to one, this bit indicates that all 'S' bit When set to one, this bit indicates that all
the feature contexts sent in CTD or PCTD were the feature contexts sent in CTD or PCTD were
received successfully. received successfully.
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to zero
skipping to change at page 14, line 19 skipping to change at page 14, line 24
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to zero
by the nAR. by the nAR.
MN's Prev IP Address Field contains either: MN's Prev IP Address Field contains either:
IPv4 Address as defined in [RFC 791]. IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373]. IPv6 Address as defined in [RFC 2373].
Status Code A context-specific return value, present Status Code A context-specific return value, present
when 'S' is not set to one. when 'S' is not set to one.
FPT 16 bit integer, listing the FTP that is FPT 16 bit integer, listing the FTP that is being
being acknowledged. acknowledged.
Status Code 0 = not successfully transfered Status Code 0 = not successfully transfered
1 = successfully transfered 1 = successfully transfered
2.5.5 Context Transfer Cancel (CTC) Message 2.5.5 Context Transfer Cancel (CTC) Message
If transferring a context cannot be completed in a timely fashion, If transferring a context cannot be completed in a timely fashion,
then nAR may send CTC to pAR to cancel an ongoing CT process. then nAR may send CTC to pAR to cancel an ongoing CT process.
0 1 2 3 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 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=CTC | Length | Reserved | | Type=CTC | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTC = 6 (Context Transfer Data) Type CTC = 6 (Context Transfer Data)
Length message length in octets Length Message length in units of 8
octet words
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to zero
by the nAR. by the nAR.
2.5.6 Context Transfer Request (CT Request) Message 2.5.6 Context Transfer Request (CT Request) Message
Sent by nAR to pAR to request start of context transfer. This message Sent by nAR to pAR to request start of context transfer. This message
is sent as a response to CTAR message by the MN. The fields following is sent as a response to CTAR message by the MN. The fields following
the Previous IP address of the MN are included verbatim from the CTAR the Previous IP address of the MN are included verbatim from the CTAR
message. message.
0 1 2 3 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 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=CTREQ | Length | V | Reserved | | Type=CTREQ | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 25 skipping to change at page 15, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) | | Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) | | Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTREQ = 7 Type CTREQ = 7
Length message length in octets Length Message length in units of 8
octet words
'V' bits When set to '00', indicate presence of IPv6 'V' bits When set to '00', indicate presence of IPv6
Previous (New) address only. Previous (New) address only.
When set to '01' indicate presence of IPv4 When set to '01' indicate presence of IPv4
Previous (New) Address only. Previous (New) Address only.
When set to '10' indicate presence of both When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses. IPv6 and IPv4 Previous (New) addresses.
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to zero
by the nAR. by the nAR.
skipping to change at page 16, line 51 skipping to change at page 17, line 8
I | | | I | | |
M | |<------- CTD ----------| M | |<------- CTD ----------|
E |--------CTAR--------->| | E |--------CTAR--------->| |
: | | | : | | |
| | |-------- CTDR -------->| | | |-------- CTDR -------->|
V | | | V | | |
| | | | | |
5.2 Network controlled, initiated by nAR 5.2 Network controlled, initiated by nAR
in 6
MN nAR pAR MN nAR pAR
| | | | | |
T | CT trigger | T | CT trigger |
I | | | I | | |
M | |----- CT Request ----->| M | |----- CT Request ----->|
E | | | E | | |
: | |<------- CTD ----------| : | |<------- CTD ----------|
| | | | | | | |
V |--------CTAR--------->| | V |--------CTAR--------->| |
| |----- CTDR (opt) ----->| | |----- CTDR (opt) ----->|
skipping to change at page 18, line 51 skipping to change at page 19, line 8
transfers between ARs. Another important consideration is that the transfers between ARs. Another important consideration is that the
mobile node should claim it's own context, and not some other mobile node should claim it's own context, and not some other
masquerader. One method to achieve this is to provide an masquerader. One method to achieve this is to provide an
authentication cookie to be included with the context transfer authentication cookie to be included with the context transfer
message sent from the pAR to the nAR and confirmed by the mobile node message sent from the pAR to the nAR and confirmed by the mobile node
at the nAR. at the nAR.
6.3. IPsec Considerations 6.3. IPsec Considerations
Access Routers MUST implement IPsec ESP [ESP] in transport mode with Access Routers MUST implement IPsec ESP [ESP] in transport mode with
non-null encryption and authentication algorithms to provide per non-null encryption and authentication algorithms to provide per-
packet authentication, integrity protection and confidentiality, and packet authentication, integrity protection and confidentiality, and
MUST implement the replay protection mechanisms of IPsec. In those MUST implement the replay protection mechanisms of IPsec. In those
scenarios where IP layer protection is needed, ESP in tunnel mode scenarios where IP layer protection is needed, ESP in tunnel mode
SHOULD be used. Non-null encryption should be used when using IPSec SHOULD be used. Non-null encryption should be used when using IPSec
ESP. ESP.
7. IANA Considerations 7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Authority (IANA) regarding registration of values related to the
skipping to change at page 20, line 12 skipping to change at page 20, line 17
Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their
help and suggestions with this document. help and suggestions with this document.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
Requirement Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay-
load (ESP)", RFC 2406, November 1998. load (ESP)", RFC 2406, November 1998.
skipping to change at page 21, line 14 skipping to change at page 21, line 18
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast [RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast
Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999.
[RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery [RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery
for IP Version 6 (IPv6)," RFC 2461, December, 1998. for IP Version 6 (IPv6)," RFC 2461, December, 1998.
[RFC2462] Thompson, S., and Narten, T., "IPv6 Address [RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfiguration,"
Autoconfiguration," RFC 2462, December, 1998. RFC 2462, December, 1998.
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the Basic Mobile IP handover signaling can introduce disruptions to the
services running on top of Mobile IP, which may introduce unwanted services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for certain types of latencies that practically prohibit its use for certain types of ser-
services. Mobile IP latency and packet loss is being optimized through vices. Mobile IP latency and packet loss is being optimized through
several alternative procedures, such as Fast Mobile IP [FMIPv6] and several alternative procedures, such as Fast Mobile IP [FMIPv6] and
Low Latency Mobile IP [LLMIP]. Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute Feature re-establishment through context transfer should contribute
zero (optimally) or minimal extra disruption of services in zero (optimally) or minimal extra disruption of services in conjunc-
conjunction to handovers. This means that the timing of context tion to handovers. This means that the timing of context transfer
transfer SHOULD be carefully aligned with basic Mobile IP handover SHOULD be carefully aligned with basic Mobile IP handover events, and
events, and with optimized Mobile IP handover signaling mechanisms, with optimized Mobile IP handover signaling mechanisms, as those pro-
as those protocols become available. tocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms Furthermore, some of those optimized mobile IP handover mechanisms
may provide more flexibility is choosing the timing and order for may provide more flexibility is choosing the timing and order for
transfer of various context information. transfer of various context information.
Appendix B. Multicast Listener Context Transfer Appendix B. Multicast Listener Context Transfer
As an example of how context transfer can improve the performance of As an example of how context transfer can improve the performance of
IP layer handover, we consider transferring IPv6 MLD state [RFC2710]. IP layer handover, we consider transferring IPv6 MLD state [RFC2710].
MLD state is a particularly good example because every IPv6 node must MLD state is a particularly good example because every IPv6 node must
perform two MLD messaging sequences on the wireless link to establish perform two MLD messaging sequences on the wireless link to establish
itself as an MLD listener prior to performing router discovery itself as an MLD listener prior to performing router discovery
[RFC2461] or duplicate address detection [RFC2462] or before [RFC2461] or duplicate address detection [RFC2462] or before
sending/receiving any application-specific traffic (including Mobile sending/receiving any application-specific traffic (including Mobile
IP handover signaling, if any). The node must subscribe to the IP handover signaling, if any). The node must subscribe to the Soli-
Solicited Node Multicast Address as soon as it comes up on the link. cited Node Multicast Address as soon as it comes up on the link. Any
Any application-specific multicast addresses must be re-established as application-specific multicast addresses must be re-established as
well. Context transfer can significantly speed up re-establishing well. Context transfer can significantly speed up re-establishing
multicast state by allowing the nAR to initialize MLD for a node that multicast state by allowing the nAR to initialize MLD for a node that
just completed handover; without any MLD signaling on the new just completed handover; without any MLD signaling on the new wire-
wireless link. The same approach could be used for transferring less link. The same approach could be used for transferring multicast
multicast context in IPv4. context in IPv4.
An approximate qualitative estimate for the amount of savings in An approximate qualitative estimate for the amount of savings in
handover time can be obtained as follows. MLD messages are 24 bytes, handover time can be obtained as follows. MLD messages are 24 bytes,
to which the headers must be added, because there is no header to which the headers must be added, because there is no header
compression on the new link, with IPv6 header being 40 bytes, and a compression on the new link, with IPv6 header being 40 bytes, and a
required Router Alert Hop-by-Hop option being 8 bytes including required Router Alert Hop-by-Hop option being 8 bytes including pad-
padding. The total MLD message size is 72 bytes per subscribed multicast ding. The total MLD message size is 72 bytes per subscribed multicast
address. RFC 2710 recommends that nodes send 2 to 3 MLD Report messages address. RFC 2710 recommends that nodes send 2 to 3 MLD Report mes-
per address subscription, since the Report message is unacknowledged. sages per address subscription, since the Report message is unack-
Assuming 2 MLD messages sent for a subscribed address, the nowledged. Assuming 2 MLD messages sent for a subscribed address, the
mobile node would need to send 144 bytes per address subscription. If mobile node would need to send 144 bytes per address subscription. If
MLD messages are sent for both the All Nodes Multicast Address and MLD messages are sent for both the All Nodes Multicast Address and
the Solicited Node Multicast address for the node's link local the Solicited Node Multicast address for the node's link local
address, a total of 288 bytes are required when the node hands over address, a total of 288 bytes are required when the node hands over
to the new link. Note that some implementations of IPv6 optimize by to the new link. Note that some implementations of IPv6 optimize by
not sending an MLD message for the All Nodes Multicast Address, since not sending an MLD message for the All Nodes Multicast Address, since
the router can infer that at least one node is on the link (itself) the router can infer that at least one node is on the link (itself)
when it comes up and always will be, but for purposes of this when it comes up and always will be, but for purposes of this calcu-
calculation, we assume that the IPv6 implementation is conformant and lation, we assume that the IPv6 implementation is conformant and that
that the message is sent. The amount of time required for MLD signaling the message is sent. The amount of time required for MLD signaling
will, of course, depend on the wireless link bandwidth, but some will, of course, depend on the wireless link bandwidth, but some
representative numbers can be obtained by assuming bandwidths of 20 representative numbers can be obtained by assuming bandwidths of 20
kbps or 100 kbps. The former is approximate for a narrowband 3G kbps or 100 kbps. The former is approximate for a narrowband 3G cel-
cellular links and the latter for a heavily utilized 802.11b WLAN link, lular links and the latter for a heavily utilized 802.11b WLAN link,
both running Voice over IP (VoIP). With these two bit rates, the both running Voice over IP (VoIP). With these two bit rates, the sav-
savings from not having to perform the pre-router discovery messages ings from not having to perform the pre-router discovery messages are
are 115 msec. and 23 msec., respectively. If any application-specific 115 msec. and 23 msec., respectively. If any application-specific
multicast addresses are subscribed, the amount of time saved could be multicast addresses are subscribed, the amount of time saved could be
substantially more. Considering most ATM-based 3G voice cellular substantially more. Considering most ATM-based 3G voice cellular pro-
protocols try to keep total voice handover delay less than 40-80 tocols try to keep total voice handover delay less than 40- 80 msec.,
msec., MLD signaling could have a large impact on the performance MLD signaling could have a large impact on the performance of inter-
of inter-subnet VoIP handover. subnet VoIP handover.
The context-specific data field for MLD context transfer included in The context-specific data field for MLD context transfer included in
the CTP Context Data Block message for a single IPv6 multicast the CTP Context Data Block message for a single IPv6 multicast
address has the following format: address has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Subnet Prefix on nAR Wireless Interface + + Subnet Prefix on nAR Wireless Interface +
skipping to change at page 24, line 39 skipping to change at page 24, line 39
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
charliep@iprg.nokia.com charliep@iprg.nokia.com
Intellectual Property Considerations Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to per-
pertain to the implementation or use of the technology described in tain to the implementation or use of the technology described in this
this document or the extent to which any license under such rights document or the extent to which any license under such rights might
might or might not be available; neither does it represent that it or might not be available; neither does it represent that it has made
has made any effort to identify any such rights. Information on any effort to identify any such rights. Information on the IETF's
the IETF's procedures with respect to rights in standards-track procedures with respect to rights in standards-track and standards-
and standards-related documentation can be found in BCP-11. Copies related documentation can be found in BCP-11. Copies of claims of
of claims of rights made available for publication and any assurances rights made available for publication and any assurances of licenses
of licenses to be made available, or the result of an attempt made to be made available, or the result of an attempt made to obtain a
to obtain a general license or permission for the use of such general license or permission for the use of such proprietary rights
proprietary rights by implementers or users of this specification by implementers or users of this specification can be obtained from
can be obtained from the IETF Secretariat. the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Copyright (C) The Internet Society 2004. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/