draft-ietf-seamoby-ctp-05.txt   draft-ietf-seamoby-ctp-06.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-05.txt> R. Koodli <draft-ietf-seamoby-ctp-06.txt> R. Koodli
Expires: May 25, 2004 October 25, 2003 Expires: July 1, 2004 January 1, 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 The Problem 1.1 Conventions Used in This Document
1.2 Conventions Used in This Document 1.2 Abbreviations Used in the 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. Error Codes
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
6.1 Threats
6.2 Security Details
6.3 IPsec Considerations
7. IANA Considerations 7. IANA Considerations
7.1 Context Profile Types Registry 7.1 Context Profile Types Registry
7.2 UDP Port
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 3, line 21 skipping to change at page 3, line 21
* Messages to initiate and authorize context transfer, and notify * Messages to initiate and authorize context transfer, and notify
a mobile node of the status of the transfer. a mobile node of the status of the transfer.
* Messages for transferring contexts prior to, during and after * Messages for transferring contexts prior to, during and after
handovers. handovers.
The proposed protocol is designed to work in conjunction with other The proposed protocol is designed to work in conjunction with other
protocols in order to provide seamless mobility. The protocol protocols in order to provide seamless mobility. The protocol
supports both IPv4 and IPv6, though support for IPv4 private supports both IPv4 and IPv6, though support for IPv4 private
addresses is for future study. addresses is for future study.
The Problem
"Problem Description: Reasons For Performing Context Transfers "Problem Description: Reasons For Performing Context Transfers
between Nodes in an IP Access Network" [RFC3374] defines the between Nodes in an IP Access Network" [RFC3374] defines the
following main reasons why Context Transfer procedures may be useful following main reasons why Context Transfer procedures may be useful
in IP networks. in IP networks.
1) The primary motivation, as mentioned in the introduction, is the 1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch. An example of a protocol flows for those services from scratch. An example of a
service is included in Appendix C. service is included in Appendix C.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
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
present (and containing non-default values). The ordering of the present (and containing non-default values). The ordering of the
bits in the presence vector is the same as the ordering of the data bits in the presence vector is the same as the ordering of the data
fields according to the context type specification, one bit per data fields according to the context type specification, one bit per data
field regardless of the size of the data field. field regardless of the size of the data field.
The Length field indicates the size of the CDB in 8 octets including The Length field indicates the size of the CDB in 8 octets including
the first 4 bytes starting from Cxt-Type. the first 4 bytes starting from Cxt-Type.
Cxt-Type = 0 is reserved for a general error message. The data field
contains error codes information, and is defined by in specific
context types.
Notice that the length of the context data block is defined by the Notice that the length of the context data block is defined by the
sum of lengths of each data field specified by the context type sum of lengths of each data field specified by the context type
specification, plus 4 bytes if the 'P' bit is set, minus the specification, plus 4 bytes if the 'P' bit is set, minus the
accumulated size of all the context data that is implicitly given accumulated size of all the context data that is implicitly given
as a default value. as a default value.
2.5 Messages 2.5 Messages
In this section, a list of the available context transfer message In this section, a list of the available context transfer message
types is given, along with a brief description of their functions. In types is given, along with a brief description of their functions. In
skipping to change at page 10, line 39 skipping to change at page 10, line 43
If no context types are specified, then all contexts for the mobile If no context types are specified, then all contexts for the mobile
node are requested. When 'V' is 10, the IPv4 address MUST precede the node are requested. When 'V' is 10, the IPv4 address MUST precede the
IPv6 address both for the MN and the access router. Since Context IPv6 address both for the MN and the access router. Since Context
Types clearly define the context including the IP version, context Types clearly define the context including the IP version, context
enumeration need not be in any strict order, although it might be enumeration need not be in any strict order, although it might be
natural to outline all the IPv4 contexts followed by IPv6 contexts. natural to outline all the IPv4 contexts followed by IPv6 contexts.
The Authorization Token is calculated as: The Authorization Token is calculated as:
First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context
Types))) Types))), where Key is the shared secret between the MN and pAR,
and Context Types includes all the desired contexts for which the
where Key is the shared secret between the MN and pAR, and Context transfer is desired. In the default scenario, the MN implicitly
Types includes all the desired contexts for which the transfer is (i.e., even without the knowledge of contexts being present) or
desired. In the default scenario, the MN implicitly (i.e., even explicitly requests transfer of all contexts.
without the knowledge of contexts being present) or explicitly
requests transfer of all contexts.
2.5.2 Context Transfer Activate Acknowledge (CTAA) Message 2.5.2 Context Transfer Activate Acknowledge (CTAA) Message
This is an informative message sent by the receiver of CTAR to the MN This is an informative message sent by the receiver of CTAR to the MN
to acknowledge a CTAR message. Acknowledgement is optional, depending to acknowledge a CTAR message. Acknowledgement is optional, depending
on whether the MN requested it. This message may include a list of on whether the MN requested it. This message may include a list of
FPT (feature profile types) that were not transferred successfully. FPT (feature profile types) that were not transferred successfully.
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=CTAA | Length | Reserved | | Type=CTAA | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 octets
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 sender of CTAA Message, i.e. pAR or
nAR.
'V' flag When set to '00', indicate presence of IPv6
Previous (New) address only.
When set to '01' indicate presence of IPv4
Previous (New) Address only.
When set to '10' indicate presence of both
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 was not FPT 16 bit integer, listing the FTP that 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. A reliability message should handle predictive as well as normal CT. An
flag, R, included in this message indicates whether a reply is acknowledgement flag, A, included in this message indicates whether a
required by nAR. reply is required by pAR.
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=(P)CTD | Length | V |A| Reserved | | Type=(P)CTD | Length | V |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) | | Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 28 skipping to change at page 12, line 40
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 octets
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 pAR.
Elapsed Time The number of milliseconds since the
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 message. This is only applicable for the PCTD message.
Algorithm Algorithm for carrying out the computation Algorithm Algorithm for carrying out the computation of
of the MN Authorization Token. Currently the MN Authorization Token. Currently only 1
only 1 algorithm is defined, HMAC_SHA1 = 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 ESP. 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: data for computing the token are: the MN's Previous IP address, the
FPT objects and the Replay field. When support for transferring all
- the MN's Previous IP address, contexts is requested, a default FPT is used. The Authorization Token
- the FPT objects, is obtained by truncating the results of the HMAC_SHA1 computation to
- the Replay field. retain only the leading 32 bits.
When support for transferring all contexts is requested, a default
FPT is used. The Authorization Token is obtained by truncating the
results of the HMAC_SHA1 computation to retain only the leading 32
bits.
2.5.4 Context Transfer Data Reply (CTDR) Message 2.5.4 Context Transfer Data Reply (CTDR) Message
This message is sent by nAR to pAR depending on the value of the This message is sent by nAR to pAR depending on the value of the
reliability flag in CTD. Indicates success or failure. reliability flag in CTD. Indicates success or failure.
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=CTDR | Length | V |S| Reserved | | Type=CTDR | Length | V |S| Reserved |
skipping to change at page 13, line 40 skipping to change at page 13, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTDR = 5 (Context Transfer Data) Type CTDR = 5 (Context Transfer Data)
Length message length in octets Length message length in octets
'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
IPv6 and IPv4 Previous addresses. 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
by the MN. by the nAR.
MN's Prev IP Contains either:
Address Field IPv4 Address as defined in [RFC 791].
MN's Prev IP Address Field contains either:
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
when 'S' is not set to one. 'S' is not set to one.
FPT 16 bit integer, listing the FPT that is being FPT 16 bit integer, listing the FTP that is 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.
skipping to change at page 14, line 34 skipping to change at page 14, line 43
| 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 octets
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 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
skipping to change at page 15, line 25 skipping to change at page 15, line 35
Length message length in octets Length message length in octets
'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 MN. by the nAR.
Replay A value used to make sure that each use of the Replay A value used to make sure that each use of the
CTAR message is uniquely identifiable. CTAR message is uniquely identifiable.
Copied from CTAR. Copied from CTAR.
Authorization Token An unforgeable value calculated as discussed Authorization Token An unforgeable value calculated as discussed
above. This authorizes the receiver of CTAR above. This authorizes the receiver of CTAR
to perform context transfer. Copied from to perform context transfer. Copied from
CTAR. CTAR.
skipping to change at page 17, line 48 skipping to change at page 18, line 12
6.1. Threats. 6.1. Threats.
The Context Transfer Protocol transfers state between access routers. The Context Transfer Protocol transfers state between access routers.
If the mobile nodes are not authenticated and authorized before If the mobile nodes are not authenticated and authorized before
moving on the network, there is a potential for DoS attacks to shift moving on the network, there is a potential for DoS attacks to shift
state between ARs, causing network disruptions. state between ARs, causing network disruptions.
Additionally, DoS attacks can be launched from mobile nodes towards Additionally, DoS attacks can be launched from mobile nodes towards
the access routers by requesting multiple context transfers and then the access routers by requesting multiple context transfers and then
disappearing. Finally, a rogue access router could flood mobile disappearing. Additionally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks. nodes with packets, attempting DoS attacks.
6.2. Security Details 6.2. Security Details
CTP relies on IETF standardized security mechanisms for protecting CTP relies on IETF standardized security mechanisms for protecting
traffic between access routers, as opposed to creating application traffic between access routers, as opposed to creating application
security mechanisms. IPsec MUST be supported between access routers. security mechanisms. IPsec MUST be supported between access routers.
In order to avoid the introduction of additional latency to context In order to avoid the introduction of additional latency to context
transfer due to the need for establishment of secure channel between transfer due to the need for establishment of secure channel between
the context transfer peers (ARs), the two ARs SHOULD establish such the context transfer peers (ARs), the two ARs SHOULD establish such
secure channel in advance. If IPSec is used, for example, the two secure channel in advance. If IPSec is used, for example, the two
access routers need to engage in a key exchange mechanisms such as access routers need to engage in a key exchange mechanisms such as
IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and
IPSec protocols (such as ESP) in anticipation for any upcoming IPSec protocols (such as ESP) in anticipation for any upcoming
context transfer. This will save time during handovers that require context transfer. This will save time during handovers that require
secure transfer of mobile node's context(s). Such SAs can be secure transfer of mobile node's context(s). Such SAs can be
maintained and used for all upcoming context transfers between the maintained and used for all upcoming context transfers between the
two ARs. Security SHOULD be negotiated prior to the sending of two ARs. Security should be negotiated prior to the sending of
context. context.
Furthermore, either one or both of the pAR and nAR need to be able to Furthermore, either one or both of the pAR and nAR need to be able to
authenticate the mobile and authorize mobile's credential before authenticate the mobile and authorize mobile's credential before
authorizing the context transfer and release of context to the authorizing the context transfer and release of context to the
mobile. In case the context transfer is request by the MN, a mobile. In case the context transfer is request by the MN, a
mechanism MUST be provided so that requests are authenticated mechanism MUST be provided so that requests are authenticated
(regardless of the security of context transfer itself) to prevent (regardless of the security of context transfer itself) to prevent
the possibility of rogue MNs launching DoS attacks by sending large the possibility of rogue MNs launching DoS attacks by sending large
number of CT requests as well as cause large number of context number of CT requests as well as cause large number of context
skipping to change at page 20, line 8 skipping to change at page 20, line 15
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 Require- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
IP [RFC2434] T. Narten, H. Alvestrand, "Guidelines for [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Writing an IANA Considerations Section in RFCs", BCP 26, Considerations Section in RFCs", BCP 26, RFC 2434, October
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.
9.2 Non-Normative References 9.2 Non-Normative References
[CTHC] R. Koodli et al., "Context Relocation for Seamless Header [CTHC] R. Koodli et al., "Context Relocation for Seamless Header
skipping to change at page 21, line 36 skipping to change at page 21, line 42
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 one MLD messaging sequence 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 Soli- IP handover signaling, if any). The node must subscribe to the Soli-
cited Node Multicast Address as soon as it comes up on the link. Any cited Node Multicast Address as soon as it comes up on the link. 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 wire- just completed handover; without any MLD signaling on the new wire-
less link. The same approach could be used for transferring multicast less link. The same approach could be used for transferring 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 the IPv6 header being 40 bytes, and compression on the new link, with IPv6 header being 40 bytes, and a
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 thus 72 bytes per subscribed ding. The total MLD message size is 72 bytes per subscribed multicast
multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD address. RFC 2710 recommends that nodes send 2 to 3 MLD Report mes-
Report messages per address subscription, since the Report message is sages per address subscription, since the Report message is unack-
unacknowledged. Assuming 2 MLD messages sent for a subscribed nowledged. Assuming 2 MLD messages sent for a subscribed address, the
address, the mobile node would need to send 144 bytes per address mobile node would need to send 144 bytes per address subscription. If
subscription, and must send at least 144 bytes on every handover, for MLD messages are sent for both the All Nodes Multicast Address and
the link local Solicited Node Multicast address. The amount of time the Solicited Node Multicast address for the node's link local
required for MLD signaling will, of course, depend on the wireless address, a total of 288 bytes are required when the node hands over
link bandwidth, but some representative numbers can be obtained by to the new link. Note that some implementations of IPv6 optimize by
assuming bandwidths of 20 kbps or 100 kbps. The former is approximate not sending an MLD message for the All Nodes Multicast Address, since
for a narrowband 3G cellular link and the latter for a heavily util- the router can infer that at least one node is on the link (itself)
ized 802.11b WLAN link, both running Voice over IP (VoIP). With these when it comes up and always will be, but for purposes of this calcu-
two bit rates, the savings from not having to perform the required lation, we assume that the IPv6 implementation is conformant and that
MLD signaling are 57 msec. and 11 msec., respectively. If any the message is sent. The amount of time required for MLD signaling
application-specific multicast addresses are subscribed, the amount will, of course, depend on the wireless link bandwidth, but some
of time saved could be substantially more. Considering most ATM-based representative numbers can be obtained by assuming bandwidths of 20
3G voice cellular protocols try to keep total voice handover delay kbps or 100 kbps. The former is approximate for a narrowband 3G cel-
less than 40-80 msec., MLD signaling could have a substantial impact lular links and the latter for a heavily utilized 802.11b WLAN link,
on the performance of inter-subnet VoIP handover. both running Voice over IP (VoIP). With these two bit rates, the sav-
ings from not having to perform the pre-router discovery messages are
115 msec. and 23 msec., respectively. If any application-specific
multicast addresses are subscribed, the amount of time saved could be
substantially more. Considering most ATM-based 3G voice cellular pro-
tocols try to keep total voice handover delay less than 40-80 msec.,
MLD signaling could have a large impact on the performance of inter-
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 23, line 8 skipping to change at page 23, line 23
The Subnet Prefix on nAR Wireless Interface field contains a subnet The Subnet Prefix on nAR Wireless Interface field contains a subnet
prefix that identifies the interface on which multicast routing prefix that identifies the interface on which multicast routing
should be established. The Subscribed IPv6 Multicast Address field should be established. The Subscribed IPv6 Multicast Address field
contains the multicast address for which multicast routing should be contains the multicast address for which multicast routing should be
established. established.
The pAR sends one MLD context block per subscribed IPv6 multicast The pAR sends one MLD context block per subscribed IPv6 multicast
address. address.
The MLD state machine requires no changes to implement context No changes are required in the MLD state machine.
transfer. Upon receipt of a CTP Context Data Block for MLD, the state
machine takes the following actions: Upon receipt of a CTP Context Data Block for MLD, the state machine
takes the following actions:
- If the router is in the No Listeners present state on the wireless - If the router is in the No Listeners present state on the wireless
interface on which the Subnet Prefix field from the Context Data interface on which the Subnet Prefix field from the Context Data
Block is advertised, it transitions into the Listeners Present Block is advertised, it transitions into the Listeners Present
state for the Subscribed IPv6 Multicast Address field in the Con- state for the Subscribed IPv6 Multicast Address field in the Con-
text Data Block. This transition is exactly the same as if the text Data Block. This transition is exactly the same as if the
router had received a Report message. router had received a Report message.
- If the router is in the Listeners present state on that interface, - If the router is in the Listeners present state on that interface,
it remains in that state but restarts the timer, as if it had it remains in that state but restarts the timer, as if it had
received a Report message. received a Report message.
If more than one MLD router is on the link, a router receiving an MLD If more than one MLD router is on the link, a router receiving an MLD
Context Data Block SHOULD send the block to the other routers on the Context Data Block SHOULD send the block to the other routers on the
link. The router MAY instead send a proxy MLD Report message on the link. The router MAY instead send a proxy MLD Report message on the
wireless interface that advertises the Subnet Prefix field from the wireless interface that advertises the Subnet Prefix field from the
Context Data Block if wireless bandwidth is not an issue. Since MLD Context Data Block if wireless bandwidth is not an issue. Since MLD
routers do not keep track of which nodes are listening to which mul- routers do not keep track of which nodes are listening to munticast
ticast addresses, only whether a particular multicast address is addresses, only whether a particular multicast address is being
being listened to, proxying the subscription should cause no diffi- listened to, proxying the subscription should cause no difficulty.
culty.
Authors' Addresses Authors' Addresses
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Rajeev.koodli@nokia.com Rajeev.koodli@nokia.com
 End of changes. 

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