< draft-ietf-mipshop-hmipv6-03.txt   draft-ietf-mipshop-hmipv6-04.txt >
Network Working Group Hesham Soliman, Flarion Network Working Group Hesham Soliman, Flarion
INTERNET-DRAFT Claude Catelluccia, INRIA INTERNET-DRAFT Claude Catelluccia, INRIA
Expires: April 2005 Karim El Malki, Ericsson Expires: June 2005 Karim El Malki, Ericsson
Ludovic Bellier, INRIA Ludovic Bellier, INRIA
October, 2004 December, 2004
Hierarchical Mobile IPv6 mobility management (HMIPv6) Hierarchical Mobile IPv6 mobility management (HMIPv6)
<draft-ietf-mipshop-hmipv6-03.txt> <draft-ietf-mipshop-hmipv6-04.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am (we are) aware have been patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which we become aware will be disclosed, in disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, we accept the provisions of By submitting this Internet-Draft, we accept the provisions of
Section 4 of RFC 3667 (BCP 78). Section 4 of RFC 3667 (BCP 78).
skipping to change at page 2, line 26 skipping to change at page 2, line 26
6.1.1. Sending packets to correspondent nodes................11 6.1.1. Sending packets to correspondent nodes................11
6.2. MAP Operations.............................................11 6.2. MAP Operations.............................................11
6.3. Home Agent Operations......................................12 6.3. Home Agent Operations......................................12
6.4. Correspondent node Operations..............................12 6.4. Correspondent node Operations..............................12
6.5. Local Mobility Management optimisation within a MAP domain.12 6.5. Local Mobility Management optimisation within a MAP domain.12
6.6. Location Privacy...........................................13 6.6. Location Privacy...........................................13
7. MAP discovery...................................................13 7. MAP discovery...................................................13
7.1. Dynamic MAP Discovery......................................13 7.1. Dynamic MAP Discovery......................................13
7.1.1. Router Operation for Dynamic MAP Discovery............14 7.1.1. Router Operation for Dynamic MAP Discovery............14
7.1.2. MAP Operation for Dynamic MAP Discovery...............14 7.1.2. MAP Operation for Dynamic MAP Discovery...............14
7.2. Mobile node Operation......................................14 7.2. Mobile node Operation......................................15
8. Updating previous MAPs..........................................15 8. Updating previous MAPs..........................................15
9. Notes on MAP selection by the mobile node.......................16 9. Notes on MAP selection by the mobile node.......................16
9.1. MAP selection in a distributed-MAP environment.............16 9.1. MAP selection in a distributed-MAP environment.............16
9.2. MAP selection in a flat mobility management architecture...17 9.2. MAP selection in a flat mobility management architecture...17
10. Detection and recovery from MAP failures.......................18 10. Detection and recovery from MAP failures.......................18
11. IANA Considerations............................................18 11. IANA Considerations............................................18
12. Security considerations........................................19 12. Security considerations........................................19
12.1. Mobile node-MAP security..................................19 12.1. Mobile node-MAP security..................................19
12.2. Mobile node-correspondent node security...................20 12.2. Mobile node-correspondent node security...................20
12.3. Mobile node-Home Agent security...........................20 12.3. Mobile node-Home Agent security...........................21
13. Acknowledgments................................................20 13. Acknowledgments................................................21
14. Authors' Addresses.............................................21 14. Authors' Addresses.............................................21
15. References.....................................................21 15. References.....................................................22
15.1. Normative references......................................21 15.1. Normative references......................................22
15.2. Informative References....................................22 15.2. Informative References....................................23
Appendix A - Fast Mobile IPv6 Handovers and HMIPv6.................24 Appendix A - Fast Mobile IPv6 Handovers and HMIPv6.................24
1. Introduction 1. Introduction
This memo introduces the concept of a Hierarchical Mobile IPv6 This memo introduces the concept of a Hierarchical Mobile IPv6
network, utilising a new node called the Mobility Anchor Point (MAP). network, utilising a new node called the Mobility Anchor Point (MAP).
Mobile IPv6 [1] allows nodes to move within the Internet topology Mobile IPv6 [1] allows nodes to move within the Internet topology
while maintaining reachability and on-going connections between while maintaining reachability and on-going connections between
mobile and correspondent nodes. To do this a mobile node sends mobile and correspondent nodes. To do this a mobile node sends
skipping to change at page 5, line 48 skipping to change at page 5, line 48
of the MN (e.g. same site) is outside the scope of this document. of the MN (e.g. same site) is outside the scope of this document.
3.1. HMIPv6 Operation 3.1. HMIPv6 Operation
The network architecture shown in Figure 1 illustrates an example of The network architecture shown in Figure 1 illustrates an example of
the use of the MAP in a visited network. the use of the MAP in a visited network.
In Figure 1, the MAP can help in providing seamless mobility for the In Figure 1, the MAP can help in providing seamless mobility for the
mobile node as it moves from Access Router 1 (AR1) to Access Router 2 mobile node as it moves from Access Router 1 (AR1) to Access Router 2
(AR2), while communicating with the correspondent node. A multi-level (AR2), while communicating with the correspondent node. A multi-level
hierarchy is not required for a higher handover performance, hence it hierarchy is not required for a higher handover performance. Hence,
is sufficient to locate one or more MAPs (possibly covering the same it is sufficient to locate one or more MAPs (possibly covering the
domain) at any position in the operator's network. same domain) at any position in the operator's network.
+-------+ +-------+
| HA | | HA |
+-------+ +----+ +-------+ +----+
| | CN | | | CN |
| +----+ | +----+
| | | |
+-------+-----+ +-------+-----+
| |
|RCoA |RCoA
skipping to change at page 19, line 28 skipping to change at page 19, line 31
Three different relationships (related to securing binding updates) Three different relationships (related to securing binding updates)
need to be considered: need to be considered:
1) The mobile node - MAP 1) The mobile node - MAP
2) The mobile node - Home Agent 2) The mobile node - Home Agent
3) The mobile node - correspondent node 3) The mobile node - correspondent node
12.1. Mobile node-MAP security 12.1. Mobile node-MAP security
In order to allow a mobile node to use the MAP's forwarding service,
initial authorization (specifically for the service, not for the
RCoA) MAY be needed. Authorising a mobile node to use the MAP service
can be done based on the identity of the mobile node exchanged during
the SA negotiation process. The authorization may be granted based on
the mobile node's identity, or based on the identity of a Certificate
Authority (CA) that the MAP trusts. For instance, if the mobile node
presents a certificate signed by a trusted entity (e.g. a CA that
belongs to the same administrative domain, or another trusted roaming
partner), it would be sufficient for the MAP to authorise the use of
its service. Note that this level of authorisation is independent of
authorising the use of a particular RCoA. Similarly, the mobile node
would trust the MAP, if it presents a certificate signed by the same
CA, or by another CA that the mobile node is configured to trust
(e.g. a roaming partner).
HMIPv6 uses an additional registration between the mobile node and HMIPv6 uses an additional registration between the mobile node and
its current MAP. As explained in this document, when a mobile node its current MAP. As explained in this document, when a mobile node
moves into a new domain (i.e. served by a new MAP), it obtains an moves into a new domain (i.e. served by a new MAP), it obtains an
RCoA, a LCoA and registers the binding between these two addresses RCoA, a LCoA and registers the binding between these two addresses
with the new MAP. The MAP then verifies whether the RCoA has not been with the new MAP. The MAP then verifies whether the RCoA has not been
registered yet and if so it creates a binding cache entry with the registered yet and if so it creates a binding cache entry with the
RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to
send a new BU that specifies the binding between RCoA and its new send a new BU that specifies the binding between RCoA and its new
LCoA. This BU needs to be authenticated otherwise any host could send LCoA. This BU needs to be authenticated otherwise any host could send
a BU for the mobile node's RCoA and hijack the mobile node's packets. a BU for the mobile node's RCoA and hijack the mobile node's packets.
However since the RCoA is temporary and is not bound to a particular However since the RCoA is temporary and is not bound to a particular
node, a mobile node does not have to prove that it owns its RCoA node, a mobile node does not have to initially (before the first
(unlike the requirement on home addresses in Mobile IPv6) when it binding update) prove that it owns its RCoA (unlike the requirement
establishes a Security Association with its MAP. A MAP only needs to on home addresses in Mobile IPv6) when it establishes a Security
ensure that a BU for a particular RCoA was issued by the same mobile Association with its MAP. A MAP only needs to ensure that a BU for a
node that established the Security Association for that RCoA. particular RCoA was issued by the same mobile node that established
the Security Association for that RCoA.
The MAP does not need to know the identity of the mobile node nor its The MAP does not need to have prior knowledge of the identity of the
Home Address. As a result the SA between the mobile node and the MAP mobile node nor its Home Address. As a result the SA between the
can be established using any key establishment protocols such as IKE. mobile node and the MAP can be established using any key
A return routability test is not necessary. establishment protocols such as IKE. A return routability test is not
necessary.
The MAP needs to set the SA for the RCoA (not the LCoA). This can be The MAP needs to set the SA for the RCoA (not the LCoA). This can be
performed with IKE [6]. The mobile node uses its LCoA as source performed with IKE [6]. The mobile node uses its LCoA as source
address but specifies that the RCoA should be used in the SA. This is address but specifies that the RCoA should be used in the SA. This is
achieved by using the RCoA as the identity in IKE Phase 2 achieved by using the RCoA as the identity in IKE Phase 2
negotiation. This step is identical to the use of the home address in negotiation. This step is identical to the use of the home address in
IKE phase 2. IKE phase 2.
If a binding cache entry exists for a given RCoA, the MAP's IKE If a binding cache entry exists for a given RCoA, the MAP's IKE
policy check MUST point to the SA used to install the entry. If the policy check MUST point to the SA used to install the entry. If the
skipping to change at page 21, line 9 skipping to change at page 21, line 29
The authors would like to thank Conny Larsson (Ericsson) and Mattias The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft. Pettersson (Ericsson) for their valuable input to this draft.
The authors would also like to thank the members of the French RNRT The authors would also like to thank the members of the French RNRT
MobiSecV6 project (BULL, France Telecom and INRIA) for testing the MobiSecV6 project (BULL, France Telecom and INRIA) for testing the
first implementation and for their valuable feedback. The INRIA first implementation and for their valuable feedback. The INRIA
HMIPv6 project is partially funded by the French Government. HMIPv6 project is partially funded by the French Government.
In addition, the authors would like to thank the following members of In addition, the authors would like to thank the following members of
the working group in alphabetical order: Samita Chakrabarti (Sun), the working group in alphabetical order: Samita Chakrabarti (Sun),
Gregory Daley (Monash University), Francis Dupont (Ernst-Bretagne), Gregory Daley (Monash University), Francis Dupont (GET/Enst
Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave
University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf
Martti Kuparinen (Ericsson) Fergal Ladley, Nick "Sharkey" Moore (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel
(Monash University) Erik Nordmark (Sun), Basavaraj Patil (Nokia), Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik
Brett Pentland (Monash University), and Alper Yegin (Samsung) for Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash
their comments on the draft. University), and Alper Yegin (Samsung) for their comments on the
draft.
14. Authors' Addresses 14. Authors' Addresses
Hesham Soliman Hesham Soliman
Flarion Technologies Flarion Technologies
email: h.soliman@flarion.com email: h.soliman@flarion.com
Claude Castelluccia Claude Castelluccia
INRIA Rhone-Alpes INRIA Rhone-Alpes
655 avenue de l'Europe 655 avenue de l'Europe
skipping to change at page 28, line 45 skipping to change at page 28, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires April, 2005. This Internet-Draft expires June, 2005.
 End of changes. 12 change blocks. 
28 lines changed or deleted 47 lines changed or added

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