draft-ietf-mip6-ha-switch-01.txt   draft-ietf-mip6-ha-switch-02.txt 
Mobile IPv6 B. Haley Mobile IPv6 B. Haley
Internet Draft Hewlett-Packard Internet Draft Hewlett-Packard
Document: draft-ietf-mip6-ha-switch-01.txt V. Devarapalli Document: draft-ietf-mip6-ha-switch-02.txt V. Devarapalli
Expires: April, 2006 Azaire Networks Expires: June, 2006 Azaire Networks
H. Deng H. Deng
Hitachi Hitachi
J. Kempf J. Kempf
DoCoMo USA Labs DoCoMo USA Labs
October 2006 December 2006
Mobility Header Home Agent Switch Message Mobility Header Home Agent Switch Message
draft-ietf-mip6-ha-switch-01.txt draft-ietf-mip6-ha-switch-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 22 skipping to change at page 2, line 22
2.1 Overloaded.................................................3 2.1 Overloaded.................................................3
2.2 Load Balancing.............................................3 2.2 Load Balancing.............................................3
2.3 Maintenance................................................3 2.3 Maintenance................................................3
2.4 Functional Load Balancing..................................3 2.4 Functional Load Balancing..................................3
2.5 Home Agent Renumbering.....................................3 2.5 Home Agent Renumbering.....................................3
3. Home Agent Switch Message......................................4 3. Home Agent Switch Message......................................4
4. Home Agent Operation...........................................6 4. Home Agent Operation...........................................6
4.1 Sending Home Agent Switch Messages.........................6 4.1 Sending Home Agent Switch Messages.........................6
4.2 Retransmissions............................................7 4.2 Retransmissions............................................7
4.3 Mobile Node Errors.........................................7 4.3 Mobile Node Errors.........................................7
5. Mobile Node Operation..........................................7 5. Mobile Node Operation..........................................8
5.1 Receiving Home Agent Switch Messages.......................7 5.1 Receiving Home Agent Switch Messages.......................8
5.2 Selecting a Home Agent.....................................8 5.2 Selecting a Home Agent.....................................8
6. Operational Considerations.....................................8 6. Operational Considerations.....................................9
7. Procotol Constants.............................................9 7. Procotol Constants.............................................9
8. IANA Considerations............................................9 8. IANA Considerations............................................9
9. Security Considerations........................................9 9. Security Considerations........................................9
10. References....................................................9 10. References...................................................10
10.1 Normative References......................................9 10.1 Normative References.....................................10
10.2 Informative references...................................10 10.2 Informative references...................................10
Acknowledgments..................................................10 Acknowledgments..................................................10
Author's Addresses...............................................10 Author's Addresses...............................................11
1. Introduction 1. Introduction
RFC 3775 [2] contains no provision to allow a home agent to inform a RFC 3775 [2] contains no provision to allow a home agent to inform a
mobile node that it needs to stop acting as the home agent for the mobile node that it needs to stop acting as the home agent for the
mobile node. For example, a home agent may wish to handoff some of mobile node. For example, a home agent may wish to handoff some of
its mobile nodes to another home agent because it has become its mobile nodes to another home agent because it has become
overloaded or it is going offline. overloaded or it is going offline.
This protocol describes a signaling message type that can be used to This protocol describes a signaling message type that can be used to
skipping to change at page 6, line 11 skipping to change at page 6, line 11
Addresses" field in the Home Agent Switch message. Addresses" field in the Home Agent Switch message.
Mobility options Mobility options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero of more TLV-encoded mobility options. The encoding contains zero of more TLV-encoded mobility options. The encoding
and format of defined options MUST follow the format specified in and format of defined options MUST follow the format specified in
Section 6.2 of [2]. The receiver MUST ignore and skip any options Section 6.2 of [2]. The receiver MUST ignore and skip any options
with it does not understand. with it does not understand.
This specification does not define any options valid for the Home The Binding Refresh Advice mobility option defined in Section 6.2.4
Agent Switch message. of [2] is valid for the Home Agent Switch message.
If no home agent addresses and no options are present in this If no home agent addresses and no options are present in this
message, no padding is necessary and the Header Len field in the message, no padding is necessary and the Header Len field in the
Mobility Header will be set to 0. Mobility Header will be set to 0.
4. Home Agent Operation 4. Home Agent Operation
4.1 Sending Home Agent Switch Messages 4.1 Sending Home Agent Switch Messages
When sending a Home Agent Switch message, the sending node constructs When sending a Home Agent Switch message, the sending node constructs
skipping to change at page 6, line 39 skipping to change at page 6, line 39
home agents. The home agent addresses field should be home agents. The home agent addresses field should be
constructed as described in Section 10.5.1 of [2], which will constructed as described in Section 10.5.1 of [2], which will
randomize addresses of the same preference in the list. randomize addresses of the same preference in the list.
o The "# of addresses" field MUST be filled-in corresponding to o The "# of addresses" field MUST be filled-in corresponding to
the number of home agent addresses included in the message. If the number of home agent addresses included in the message. If
no addresses are present, the field MUST be set to zero, forcing no addresses are present, the field MUST be set to zero, forcing
the mobile node to perform home agent discovery by some other the mobile node to perform home agent discovery by some other
means. means.
The Home Agent Switch message MUST use the home agent to mobile node o If the home agent is able to continue offering services to the
IPsec ESP authentication SA for integrity protection. mobile node for some period of time, it MAY include a Binding
Refresh Advice mobility option indicating the time (in units of
4 seconds) until the binding will be deleted.
The Home Agent Switch message MUST be authenticated in one of the
following ways:
o The home agent to mobile node IPsec ESP authentication SA for
integrity protection.
o A home agent to mobile node authentication option, such as [3].
A home agent SHOULD send a Home Agent Switch message when a known A home agent SHOULD send a Home Agent Switch message when a known
period of unavailability is pending so the mobile node has sufficient period of unavailability is pending so the mobile node has sufficient
time to find another suitable home agent. time to find another suitable home agent.
The sending node does not need to be the current home agent for the The sending node does not need to be the current home agent for the
mobile node, for example as described in [3], but it MUST have a mobile node, for example as described in [4], but it MUST have a
security association with the mobile node so the message is not security association with the mobile node so the message is not
rejected. In this case, the Home Agent Switch message SHOULD only rejected. In this case, the Home Agent Switch message SHOULD only
contain the address of the home agent sending the message in the Home contain the address of the home agent sending the message in the Home
Agent Addresses field, which implies the mobile node should switch to Agent Addresses field, which implies the mobile node should switch to
using the sender as its new home agent. using the sender as its new home agent.
4.2 Retransmissions 4.2 Retransmissions
If the home agent does not receive a response from the mobile node - If the home agent does not receive a response from the mobile node -
either a Binding Update message to delete its home binding if it is either a Binding Update message to delete its home binding if it is
skipping to change at page 7, line 22 skipping to change at page 7, line 32
binding if it is not the current home agent, then it SHOULD binding if it is not the current home agent, then it SHOULD
retransmit the message, until a response is received. The initial retransmit the message, until a response is received. The initial
value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT. value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT.
The retransmissions by the home agent MUST use an exponential back- The retransmissions by the home agent MUST use an exponential back-
off mechanism, in which the timeout period is doubled upon each off mechanism, in which the timeout period is doubled upon each
retransmission, until either the home agent gets a response from the retransmission, until either the home agent gets a response from the
mobile node to delete its binding, or the timeout period reaches the mobile node to delete its binding, or the timeout period reaches the
value MAX-HA-SWITCH-TIMEOUT. value MAX-HA-SWITCH-TIMEOUT.
If the home agent included a Binding Refresh Advice mobility option,
then it SHOULD delay any retransmissions until at least one half of
the time period has expired, or INITIAL-HA-SWITCH-TIMEOUT, whichever
value is less.
4.3 Mobile Node Errors 4.3 Mobile Node Errors
If a mobile node does not understand how to process a Home Agent If a mobile node does not understand how to process a Home Agent
Switch Message, it will send a Binding Error message as described in Switch Message, it will send a Binding Error message as described in
Section 5.1. Section 5.1.
If a mobile node is unreachable, in other words, it still has a home If a mobile node is unreachable, in other words, it still has a home
binding with the home agent after reaching the timeout period of MAX- binding with the home agent after reaching the timeout period of MAX-
HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions
about its status. about its status.
skipping to change at page 8, line 5 skipping to change at page 8, line 17
5. Mobile Node Operation 5. Mobile Node Operation
5.1 Receiving Home Agent Switch Messages 5.1 Receiving Home Agent Switch Messages
Upon receiving a Home Agent Switch message, the Mobility Header MUST Upon receiving a Home Agent Switch message, the Mobility Header MUST
be verified as specified in [2], specifically: be verified as specified in [2], specifically:
o The Checksum, MH type, Payload Proto and Header Len fields o The Checksum, MH type, Payload Proto and Header Len fields
MUST meet the requirements of Section 9.2 of [2]. MUST meet the requirements of Section 9.2 of [2].
o The packet MUST be covered by the home agent to mobile node o The packet MUST be authenticated, either by the home agent to
IPsec ESP authentication SA for integrity protection. mobile node IPsec ESP authentication SA for integrity
protection, or a home agent to mobile node authentication
option.
If the packet is dropped due to the above tests, the receiving node If the packet is dropped due to the above tests, the receiving node
MUST follow the processing rules as Section 9.2 of [2] defines. For MUST follow the processing rules as Section 9.2 of [2] defines. For
example, it MUST send a Binding Error message with the Status field example, it MUST send a Binding Error message with the Status field
set to 2 (unrecognized MH Type value) if it does not support the set to 2 (unrecognized MH Type value) if it does not support the
message type. message type.
Upon receipt of a Home Agent Switch message, the mobile node MUST Upon receipt of a Home Agent Switch message, the mobile node MUST
stop using its current home agent for services and MUST delete its stop using its current home agent for services and MUST delete its
home binding by sending a Binding Update message as described in [2]. home binding by sending a Binding Update message as described in [2].
This acts as an acknowledgement of the Home Agent Switch message. This acts as an acknowledgement of the Home Agent Switch message.
Alternately, if the sender of the message is not the current home Alternately, if the sender of the message is not the current home
agent, sending a Binding Update message to create a home binding will agent, sending a Binding Update message to create a home binding will
act as an acknowledgement of the Home Agent Switch message. act as an acknowledgement of the Home Agent Switch message.
If a Binding Refresh Advice mobility option is present, the mobile
node MAY delay the deletion of its home binding and continue to use
its current home agent until the calculated time period has expired.
If the Home Agent Switch message contains a list of alternate home If the Home Agent Switch message contains a list of alternate home
agent addresses, the mobile node SHOULD select a new home agent as agent addresses, the mobile node SHOULD select a new home agent as
described in Section 5.2, and establish the necessary IPsec security described in Section 5.2, and establish the necessary IPsec security
associations with the new home agent by whatever means required as associations with the new home agent by whatever means required as
part of the mobile node/home agent bootstrapping protocol for the part of the mobile node/home agent bootstrapping protocol for the
home agent's mobility service provider. If no alternate home agent home agent's mobility service provider. If no alternate home agent
addresses are included in the list, the mobile node MUST first addresses are included in the list, the mobile node MUST first
perform home agent discovery. perform home agent discovery.
5.2 Selecting a Home Agent 5.2 Selecting a Home Agent
skipping to change at page 9, line 22 skipping to change at page 9, line 43
8. IANA Considerations 8. IANA Considerations
A new Mobility Header type is required for the following new message A new Mobility Header type is required for the following new message
described in Section 3: described in Section 3:
(TBD) Home Agent Switch message (TBD) Home Agent Switch message
9. Security Considerations 9. Security Considerations
As with other messages in [2], the Home Agent Switch message MUST use The Home Agent Switch message MUST be authenticated by one of the
the home agent to mobile node IPsec ESP authentication SA for following methods:
integrity protection.
o The home agent to mobile node IPsec ESP authentication SA for
integrity protection as described in [2].
o A home agent to mobile node authentication option, such as
[3].
The Home Agent Switch message MAY use the IPsec ESP SA in place for The Home Agent Switch message MAY use the IPsec ESP SA in place for
Binding Updates and Acknowledgements as specified in Section 5.1 of Binding Updates and Acknowledgements as specified in Section 5.1 of
[2], in order to reduce the number of configured security [2], in order to reduce the number of configured security
associations. This also gives the message authenticity protection. associations. This also gives the message authenticity protection.
Some operators may not want to reveal the list of home agents to on- Some operators may not want to reveal the list of home agents to on-
path listeners. In such a case, the Home Agent Switch message should path listeners. In such a case, the Home Agent Switch message should
use the home agent to mobile node IPsec ESP encryption SA for use the home agent to mobile node IPsec ESP encryption SA for
confidentiality protection. confidentiality protection.
10. References 10. References
10.1 Normative References 10.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
[2] Johnson, D. Perkins, C., and Arkko, J., "Mobility Support in [2] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6", RFC 3775, June, 2004. IPv6", RFC 3775, June, 2004.
[3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and Chowdhury, K.,
"Authentication Protocol for Mobile IPv6", RFC 4285, January,
2006.
10.2 Informative references 10.2 Informative references
[3] Wakikawa, R. (Editor), "Home Agent Reliability Protocol", draft- [4] Wakikawa, R. (Editor), "Home Agent Reliability Protocol", draft-
ietf-mip6-hareliability-01.txt, October, 2006. ietf-mip6-hareliability-01.txt, October, 2006.
Acknowledgments Acknowledgments
We would like to thank the authors of a number of previous drafts We would like to thank the authors of a number of previous drafts
that contributed content to this document: that contributed content to this document:
o draft-wakikawa-mip6-nemo-haha-spec-00.txt o draft-wakikawa-mip6-nemo-haha-spec-00.txt
o draft-deng-mip6-ha-loadbalance-02.txt o draft-deng-mip6-ha-loadbalance-02.txt
o draft-kempf-mip6-ha-alert-00.txt o draft-kempf-mip6-ha-alert-00.txt
o draft-haley-mip6-mh-signaling-00.txt o draft-haley-mip6-mh-signaling-00.txt
Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni
Korhonen, and Wolfgang Fritsche for their review and feedback.
Author's Addresses Author's Addresses
Brian Haley Brian Haley
Hewlett-Packard Company Hewlett-Packard Company
110 Spitbrook Road 110 Spitbrook Road
Nashua, NH 03062, USA Nashua, NH 03062, USA
Email: brian.haley@hp.com Email: brian.haley@hp.com
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Azaire Networks
 End of changes. 18 change blocks. 
22 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/