< draft-thubert-nemo-global-haha-00.txt   draft-thubert-nemo-global-haha-01.txt >
Network Mobility P. Thubert Network Mobility P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Expires: April 5, 2005 R. Wakikawa Expires: April 18, 2006 R. Wakikawa
Keio University Keio University
V. Devarapalli V. Devarapalli
Nokia Nokia
October 5, 2004 October 15, 2005
Global HA to HA protocol Global HA to HA protocol
draft-thubert-nemo-global-haha-00 draft-thubert-nemo-global-haha-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 5, 2005. This Internet-Draft will expire on April 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This paper extends Mobile IPv6 [9] and the NEMO Basic Support [11] to This HAHA protocol extends MIPv6 [15] and NEMO [16] to remove their
remove the Layer 2 dependencies on the Home Link and allow the global link layer dependencies on the Home Link and distribute the HAs at IP
(L3) distribution of the HAs that serve a same Home Network. layer. Global HAHA considers the distribution at the scale of the
Internet, and introduces the MIP proxy for Local Mobility Management
and Route Optimization in the Infrastructure.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Layer 3 operations . . . . . . . . . . . . . . . . . . . . 4 2.2 Layer 3 operations . . . . . . . . . . . . . . . . . . . . 4
2.3 Path improvement . . . . . . . . . . . . . . . . . . . . . 5 2.3 Path improvement . . . . . . . . . . . . . . . . . . . . . 5
2.4 Single point of failure . . . . . . . . . . . . . . . . . 7 2.4 Single point of failure . . . . . . . . . . . . . . . . . 7
3. Rationale for the proposed solution . . . . . . . . . . . . . 7 3. Rationale for the proposed solution . . . . . . . . . . . . . 7
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. A proxy for Mobile IP . . . . . . . . . . . . . . . . . . . . 8
4.1 Initial routing . . . . . . . . . . . . . . . . . . . . . 9 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 External routing . . . . . . . . . . . . . . . . . . . 9 5.1 Initial routing . . . . . . . . . . . . . . . . . . . . . 10
4.1.2 Internal routing . . . . . . . . . . . . . . . . . . . 10 5.1.1 External routing . . . . . . . . . . . . . . . . . . . 10
4.2 Binding . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.2 Internal routing . . . . . . . . . . . . . . . . . . . 11
4.2.1 Direct primary binding . . . . . . . . . . . . . . . . 11 5.2 Binding . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 local proxy binding . . . . . . . . . . . . . . . . . 12 5.2.1 Direct primary binding . . . . . . . . . . . . . . . . 12
4.2.3 Foreign proxy binding . . . . . . . . . . . . . . . . 12 5.2.2 local proxy binding . . . . . . . . . . . . . . . . . 13
4.3 Path improvements . . . . . . . . . . . . . . . . . . . . 13 5.2.3 Foreign proxy binding . . . . . . . . . . . . . . . . 13
4.3.1 Leaking MNP routes in the HAHA network . . . . . . . . 14 5.3 Path improvements . . . . . . . . . . . . . . . . . . . . 14
4.3.2 On-demand proxy routes . . . . . . . . . . . . . . . . 15 5.3.1 Leaking MNP routes in the HAHA network . . . . . . . . 15
5. Terminology and concepts . . . . . . . . . . . . . . . . . . . 16 5.3.2 On-demand proxy routes . . . . . . . . . . . . . . . . 16
6. Distributed Home Network . . . . . . . . . . . . . . . . . . . 18 6. Terminology and concepts . . . . . . . . . . . . . . . . . . . 17
7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 7. Distributed Home Network . . . . . . . . . . . . . . . . . . . 19
8. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Locating Home . . . . . . . . . . . . . . . . . . . . . . 19 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 20
8.2 Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 19 9.1 Locating Home . . . . . . . . . . . . . . . . . . . . . . 20
9. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 9.2 Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 20
9.1 Locating the other HAs that serve the same Home . . . . . 19 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 20
9.2 Locating the HA that owns the binding for a HoA . . . . . 19 10.1 Locating the other HAs that serve the same Home . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10.2 Locating the HA that owns the binding for a HoA . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 12. IANA considerations . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . 21
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1 informative reference . . . . . . . . . . . . . . . . . . 21
15.2 normative reference . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
The reader of this document is expected to be familiar with both the The reader of this document is expected to be familiar with both the
Mobile IPv6 [9] and NEMO Basic Support [11] documents. As such, the Mobile IPv6 [15] and NEMO Basic Support [16] documents. As such, the
reader is expected to understand the concept of a Home Link and the reader is expected to understand the concept of a Home Link and the
Neighbor Discovery related operations that take place over that link. Neighbor Discovery related operations that take place over that link.
Home Agent global distribution is useful when a Mobile Router moves Home Agent global distribution is useful when a Mobile Router moves
geographically large area such as airplane, vehicle, etc... The geographically large area such as airplane, vehicle, etc... The
overhead of the basic NEMO protocol is redundant route caused by the overhead of the basic NEMO protocol is redundant route caused by the
bi-directional tunnel between a Home Agent and a Mobile Router. If a bi-directional tunnel between a Home Agent and a Mobile Router. If a
Mobile Router moves far away from a Home Agent, the overhead can not Mobile Router moves far away from a Home Agent, the overhead can not
be ignored. be ignored.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
expected to serve thousands of Mobile Routers on its Home Link and expected to serve thousands of Mobile Routers on its Home Link and
tunnels all packets for the Mobile Routers by itself. tunnels all packets for the Mobile Routers by itself.
But with NEMO basic support and MIPv6, Home is locally anchored to But with NEMO basic support and MIPv6, Home is locally anchored to
the Home Link at Layer 2, so Home can not be distributed the Home Link at Layer 2, so Home can not be distributed
geographically. In particular for NEMO, what's needed is a route to geographically. In particular for NEMO, what's needed is a route to
a mobile prefix via a tunnel end point that is the CareOf address of a mobile prefix via a tunnel end point that is the CareOf address of
the Mobile Router. The Home Address is but a practical artifact that the Mobile Router. The Home Address is but a practical artifact that
is mostly needed as a correlator for the registration. is mostly needed as a correlator for the registration.
This draft proposes extensions that enable the HA to HA communication This draft proposes a model that enables the HA to HA communication
at Layer 3, allowing to get rid of the Home Link in configurations at Layer 3, allowing to get rid of the Home Link in configurations
where it's not needed. where it's not needed.
2. Motivations 2. Motivations
2.1 Requirements 2.1 Requirements
This draft addresses two generic requirements expressed in the Nemo This draft addresses two generic requirements expressed in the Nemo
requirements [14]: requirements [5]:
Local Mobility and Global Mobility: Multihoming is mentioned as Local Mobility and Global Mobility: Multihoming is mentioned as
desirable. The global mobility type is not expected to be limited desirable. The global mobility type is not expected to be limited
for any consideration other than administrative and security for any consideration other than administrative and security
policies. policies.
Scalability: NEMO support signaling and processing is expected to Scalability: NEMO support signaling and processing is expected to
scale to a potentially large number of mobile networks. Thus scale to a potentially large number of mobile networks. Thus
draft extends the scalality of the NEMO basic protocol. draft extends the scalality of the NEMO basic protocol.
There is a requirement from airplane companies which want to be at There is a requirement from airplane companies which want to be at
Home in the various airports that their planes visit. In fact, this Home in the various airports that their planes visit. In fact, this
is expressed in an abstract fashion by the case (1,n,1) of the NEMO is expressed in an abstract fashion by the case (1,n,1) of the NEMO
multihoming issues [15] draft: "Single MR, Multiple HAs, Single multihoming issues [6] draft: "Single MR, Multiple HAs, Single NEMO-
NEMO-Prefix". Prefix".
There is also a general direction that indicates that NEMO could be There is also a general direction that indicates that NEMO could be
extended as a solution for VPN. To get there, we must ensure that extended as a solution for VPN. To get there, we must ensure that
NEMO is upscaled to the classical capabilities of VPN, including the NEMO is upscaled to the classical capabilities of VPN, including the
global distribution of Points Of Presence. It is a classical feature global distribution of Points Of Presence. It is a classical feature
for VPNs to allow the roaming users to connect to the closest point for VPNs to allow the roaming users to connect to the closest point
of presence into their company VPN. The same feature can not be of presence into their company VPN. The same feature can not be
provided with MIPv6 or NEMO, because the Home depends on a link that provided with MIPv6 or NEMO, because the Home depends on a link that
has a unique physical location. has a unique physical location.
2.2 Layer 3 operations 2.2 Layer 3 operations
Mobile IPv6 [9] standarizes an interface between a Mobile Node and Mobile IPv6 [15] standarizes an interface between a Mobile Node and
its Home Agent and its correspondents, as well as an interface its Home Agent and its correspondents, as well as an interface
between Home Agents. One angle of the MIPv6 operation is that the between Home Agents. One angle of the MIPv6 operation is that the
protocols hides the MN mobility by making as if the Mobile Node was protocols hides the MN mobility by making as if the Mobile Node was
always connected to a Home Link. The connectivity is maintained by always connected to a Home Link. The connectivity is maintained by
Home Agents that are permanently and physically attached to that Home Home Agents that are permanently and physically attached to that Home
Link. Link.
So the model for MIPv6 is Home Link centric and it is no surprise So the model for MIPv6 is Home Link centric and it is no surprise
that it extends IPv6 Neighbor Discovery [3] for its operations, in that it extends IPv6 Neighbor Discovery [9] for its operations, in
particular for HAs to discover each others, and to discover when one particular for HAs to discover each others, and to discover when one
of them has a binding for a Mobile Node, and which one. An immediate of them has a binding for a Mobile Node, and which one. An immediate
consequence of being Link centric is that Home can not be distributed consequence of being Link centric is that Home can not be distributed
at Layer 3, locally within a site or over the Internet. at Layer 3, locally within a site or over the Internet.
the NEMO Basic Support [11] inherits the concept of Home Link and the NEMO Basic Support [16] inherits the concept of Home Link and
MIPv6 operations on that link, making NEMO partially a link layer MIPv6 operations on that link, making NEMO partially a link layer
operation. On the other hand, the NEMO Basic Support also operates operation. On the other hand, the NEMO Basic Support also operates
as a routing protocol at L3, for example when it injects routes in as a routing protocol at L3, for example when it injects routes in
the explicit prefix mode. So NEMO operations are somewhat half L2 the explicit prefix mode. So NEMO operations are somewhat half L2
and half L3. and half L3.
What we are getting at with the HAHA protocol is placing NEMO fully What we are getting at with the HAHA protocol is placing NEMO fully
at L3. This mostly means the replacement of all ND based exchanges at L3. This mostly means the replacement of all ND based exchanges
by some equivalent, but at Layer 3, over the Internet Protocol. This by some equivalent, but at Layer 3, over the Internet Protocol. This
also means the abstraction of the concept of Home Address into a also means the abstraction of the concept of Home Address into a
skipping to change at page 5, line 33 skipping to change at page 5, line 33
MRHA tunnel | | MRHA tunnel | |
===================== == == ================ ===================== == == ================
MR <--------------------- -- -- ----------------- HA (BRITTANY) MR <--------------------- -- -- ----------------- HA (BRITTANY)
(NJ) ===================== == == ================ (NJ) ===================== == == ================
| |
| |
----- -----
///// /////
Home Link Home Link
Current model with a Home Link Figure 1: Current model with a Home Link
The routing overhead becomes costly when: The routing overhead becomes costly when:
The distance ||MR, CN|| is much smaller then the sum of the The distance ||MR, CN|| is much smaller then the sum of the
distances ||MR, HA|| + ||HA, CN||. distances ||MR, HA|| + ||HA, CN||.
AND AND
||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close,
the overhead is relatively important, but small in absolute terms. the overhead is relatively important, but small in absolute terms.
In the picture above, say that a European phone (MR) is roaming in In the picture above, say that a European phone (MR) is roaming in
skipping to change at page 6, line 41 skipping to change at page 6, line 39
HA' ------------ -- -- ------------------ HA (BRITTANY) HA' ------------ -- -- ------------------ HA (BRITTANY)
(DC) =========== == == ================= (DC) =========== == == =================
|| | || (under the Atlantic :) || | || (under the Atlantic :)
|| | || || | ||
|| | || short distance || | || short distance
|| | || MRHA Tunnel || | || MRHA Tunnel
|| | || || | ||
v v
MR (NJ) MR (NJ)
Globally Distributed HA for World Wide service Figure 2: Globally Distributed HA for World Wide service
In our previous example, we see that a HA' deployed in the East Coast In our previous example, we see that a HA' deployed in the East Coast
saves the round trip over the Atlantic. There is a new overhead for saves the round trip over the Atlantic. There is a new overhead for
the call to Europe, though, since an additional path is involved the call to Europe, though, since an additional path is involved
between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA|| between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA||
are relatively small compared to ||HA, HA'|| then the overhead is are relatively small compared to ||HA, HA'|| then the overhead is
acceptable; unless all 3 points are located closeby, in which case, acceptable; unless all 3 points are located closeby, in which case,
again, the additional cost is acceptable. again, the additional cost is acceptable.
CN2 (NICE) CN2 (NICE)
skipping to change at page 7, line 19 skipping to change at page 7, line 19
| (BRITTANY) | (BRITTANY)
v v
MR (NJ) MR (NJ)
<-------------------------------------------------------------> <------------------------------------------------------------->
Diagonal (direct path) cost Diagonal (direct path) cost
<---------------------------------------------------------------> <--------------------------------------------------------------->
Via HAs Via HAs
Illustrating that the overhead can be relatively small Figure 3: Illustrating that the overhead can be relatively small
2.4 Single point of failure 2.4 Single point of failure
The Home Link is a single point of failure for MIPv6/NEMO operations. The Home Link is a single point of failure for MIPv6/NEMO operations.
Should the Home Link fail, the whole set of MNs / MRs is disconnected Should the Home Link fail, the whole set of MNs / MRs is disconnected
from the rest of the world. One could decide to use a virtual link from the rest of the world. One could decide to use a virtual link
for Home, but then: for Home, but then:
MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. MIPv6 provides a support for multiple HAs, with the DHAAD mechanism.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
For the time being, the precise flows are not elaborated. One idea For the time being, the precise flows are not elaborated. One idea
is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly
in the registration phase. Another is that HAs should be proactively in the registration phase. Another is that HAs should be proactively
preassigned to receive a given set of registration, in order to allow preassigned to receive a given set of registration, in order to allow
a certain degree of aggregation within sites and in between site. a certain degree of aggregation within sites and in between site.
Finally, the concept of proxy is introduced to limit the number of Finally, the concept of proxy is introduced to limit the number of
primary sites (to 1?) and as a key element for an upcoming NEMO route primary sites (to 1?) and as a key element for an upcoming NEMO route
optimization scheme, where routes can be echanged in a trusted optimization scheme, where routes can be echanged in a trusted
fashion between proxies. fashion between proxies.
4. Overview 4. A proxy for Mobile IP
The draft references extensively a MIP proxy function. The word
proxy, here, is taken in a classical sense, like, for instance, a web
proxy: a MIP proxy acts as a HA for the MN and as a MN for the HA,
the CN, and other proxies. In particular, the MIP proxy terminates
the MR-HA tunnel and the associated encryption, extracts the packets,
and reencapsulates them to the destination.
This differs from a proxy-MIP function, which performs the Mobile
Node operation on behalf of a non MIP-enabled node, in order to
manage its mobility transparently.
+-------+ +-------+
| | | |
| HA 1 | | HA 2 |
| | | |
+-------+ +-------+
primary ^ primary ^
binding | binding |
+-------+ +-------+ +-------+
| | --------->| |---------->| |
| MN/MR | proxy |proxy 1| secondary |proxy 2|
| 1 | binding | | binding | |
+-------+ +-------+ +-------+
RO | proxy ^
binding v binding |
+-------+ +-------+
| | | |
| CN | | MN/MR |
| | | 2 |
+-------+ +-------+
Figure 4: MIP proxy
Distributing widely the MIP proxies presents a number of advantages:
Route Optimization: a proxy-to-proxy path between to MNs/MRs could be
much shorter then the path vias the HAs.
Local Mobility Management: when the MN moves around a given proxy,
but keeps binding to that same proxy, the proxy does not need to
inform the primary HA.
Nested NEMO: when Mobile Routers attach to one another and form a
nested NEMO, the corresponding MRHA tunnel are nested as well. If
they all bind to a same proxy, the proxy will decapsulate all the
levels of tunneling, and retunnel only once towards the Internet
5. Overview
This description covers the specific case of a Partitioned Home This description covers the specific case of a Partitioned Home
Network. Home is subnetted and the subnets are attributed to the Network. Home is subnetted and the subnets are attributed to the
distributed sites. As a result, in a given location, HAs will be distributed sites. As a result, in a given location, HAs will be
operating both as primary HA taking the registrations for the local operating both as primary HA taking the registrations for the local
partition and proxy HA for registrations that belong to other sites. partition and proxy HA for registrations that belong to other sites.
Additional satellite sites might be deployed around some of the main Additional satellite sites might be deployed around some of the main
sites. sites.
## ## ## ##
## ## ## ## ## ##
##\ || || proxy/parent ##\ || ||proxy/parent
\\ || || tunnel \\ || || tunnel
\\ ---||---- ...... ... ----||--- \\ ---||---- ...... ... ----||---
\\| | .... .... ... | | \\| | .... .... ... | |
\ ñ---ñ | .... ..... | ñ---ñ | \ @---@ | .... ..... | @---@ |
## ----- | X | --------------------------------- \ / ------## ## ----- | X | --------------------------------- \ / ------##
## ----- ñ---ñ .... HAHA tunnel .... ñ ------## ## ----- @---@ .... HAHA tunnel .... @ ------##
| --------------------------------- | | --------------------------------- |
------\ \ ... .... / /-||--- ------\ \ ... .... / /-||---
\ \... .../ / || \ \... .../ / ||
\.\. /./ || \.\. /./ ||
.\.\ internet /./. || .\.\ internet /./. ||
.\.\ ........... / /... ## .\.\ ........... / /... ##
...\ \ / / .. ## ...\ \ / / .. ##
.. \ \ / / ... .. \ \ / / ...
...\ \ / / ... ...\ \ / / ...
..\ \ ...... / /... ..\ \ ...... / /...
\.\ . ...... .././ \.\ . ...... .././
ñ primary HA \ \ .. / / @ primary HA \ \ .. / /
\ \ --------- / / \ \ --------- / /
## proxy HA or \ \ ñ ñ / / ## proxy HA or \ \ @ @ / /
## satellite site \ \ / / ## satellite site \ \ / /
\ ñ /-----## \ @ /-----##
-- | / \ ------## -- | / \ ------##
| | primary site | ñ ñ | | | primary site | @ @ |
-- --------- -- ---------
Figure 5: Overview
It is out of the scope of this document to discuss how the subnetting It is out of the scope of this document to discuss how the subnetting
was decided and configured. It is also out of the scope of this was decided and configured. It is also out of the scope of this
document to describe the operations within a site where more than one document to describe the operations within a site where more than one
HA is deployed. It is expected that in each primary site, HAs HA is deployed. It is expected that in each primary site, HAs
discover each other, mesh using tunnels, and form an area that owns discover each other, mesh using tunnels, and form an area that owns
the partition of Home that was assigned to that site. the partition of Home that was assigned to that site.
4.1 Initial routing 5.1 Initial routing
4.1.1 External routing 5.1.1 External routing
Sites are expected to be connected locally to the internet, via the Sites are expected to be connected locally to the internet, via the
network of one or more service provider. Each site has a default network of one or more service provider. Each site has a default
route to the internet via that connection. route to the internet via that connection.
. .. / . .. /
--------- ........ ..;. --------- --------- ........ ..;. ---------
| | .. / ..... | | | | .. / ..... | |
| ::/0 -> .... ; ... <- ::/0 | | ::/0 -> .... ; ... <- ::/0 |
| ============HAHA=TUNNEL=========== | | ============HAHA=TUNNEL=========== |
skipping to change at page 9, line 46 skipping to change at page 10, line 46
| \ ==MRHA== / ... | ^ | | \ ==MRHA== / ... | ^ |
| HA >---------- MR ; .. | ^ | | HA >---------- MR ; .. | ^ |
| / =tunnel= / .| ^ | | / =tunnel= / .| ^ |
| v | ; | ^ | | v | ; | ^ |
| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA |
| | . ; ... | | | | . ; ... | |
--------- . / ... --------- --------- . / ... ---------
... ;.... ...... ... ;.... ......
/ .......... / ..........
Thus, a site attracts the DHAAD requests from any MR that happens to Thus, a site attracts the DHAAD requests from any MR that happens to
be roaming close to the site, regardless of the MR primary site. So be roaming close to the site, regardless of the MR primary site. So
MRs bind to the closest site from their physical location. In a same MRs bind to the closest site from their physical location. In a same
fashion, CNs send all packets to LFNs via the closest Home site. But fashion, CNs send all packets to LFNs via the closest Home site. But
packets back flow directly from the site where the MR is bound. packets back flow directly from the site where the MR is bound.
4.1.2 Internal routing 5.1.2 Internal routing
In each area, border HAs are elected to mesh with peers in other In each area, border HAs are elected to mesh with peers in other
sites. Again, they discover each other, mesh using tunnels, and form sites. Again, they discover each other, mesh using tunnels, and form
a backbone. It might be preferrable to form a fully meshed backbone, a backbone. It might be preferrable to form a fully meshed backbone,
in order to limit the cost of routing between sites. Also, making in order to limit the cost of routing between sites. Also, making
the backbone a transit area enables the use of a specific HA for the the backbone a transit area enables the use of a specific HA for the
HAHA protocol that acts as an OSPF Designated Router or a BGP Route HAHA protocol that acts as an OSPF Designated Router or a BGP Route
Reflector. Reflector.
...... ......
--------- ....... .../ --------- --------- ....... .../ ---------
| site1 | ..... ; .... | Site2| | site1 | ..... ; .... | Site2|
| ---------------------------------- | | ---------------------------------- |
| Home:Site2::/48 -> <- Home:Site1::/48 | | Home:Site2::/48 -> <- Home:Site1::/48 |
| ------------HAHA-tunnel----------- | | ------------HAHA-tunnel----------- |
| ñ ñ ñ | / .| ñ ñ | | @ @ @ | / .| @ @ |
| ñ ñ | <- Home::/32 ; Home::/32 -> | ñ ñ ñ | | @ @ | <- Home::/32 ; Home::/32 -> | @ @ @ |
--------- . / ... --------- --------- . / ... ---------
... ....; ...... ... ....; ......
/.......... /..........
If a link state protocol such as OSPFv3 is deployed between the If a link state protocol such as OSPFv3 is deployed between the
primary HAs, then it uses the meshed backbone as its area zero, and primary HAs, then it uses the meshed backbone as its area zero, and
each site as an area. Sites exchange their partitions of Home in the each site as an area. Sites exchange their partitions of Home in the
form of summarized routes. form of summarized routes.
It can be expected that, in order to scale, satellite sites would be It can be expected that, in order to scale, satellite sites would be
deployed to take the proxy bindings but would not participate to the deployed to take the proxy bindings but would not participate to the
HAHA protocol that happens between the primary sites - at least when HAHA protocol that happens between the primary sites - at least when
a proactive version of HAHA is being used. a proactive version of HAHA is being used.
...... ......
--------- ....... .../. --------- --------- ....... .../. ---------
| Sat1 | ..... ; .... | Site1 | | Sat1 | ..... ; .... | Site1 |
| ---------------------------------- | | ---------------------------------- |
| Home::/32 -> <- Home:Site1:Sat1:/64 | | Home::/32 -> <- Home:Site1:Sat1:/64 |
| ----proxyHAHA-tunnel-------------- | | ----proxyHAHA-tunnel-------------- |
| #### | / .| ñ ñ ñ | | #### | / .| @ @ @ |
| #### | <- Home::/32 ; Home::/32 -> | ñ ñ | | #### | <- Home::/32 ; Home::/32 -> | @ @ |
--------- . / ... --------- --------- . / ... ---------
... ....; ...... ... ....; ......
/.......... /..........
In a satellite site, HAs are only proxy, never primary. Each proxy In a satellite site, HAs are only proxy, never primary. Each proxy
HA has at least one assigned parent HA, which belongs to a primary HA has at least one assigned parent HA, which belongs to a primary
site. A tunnel is established between the proxy HA and the parent site. A tunnel is established between the proxy HA and the parent
HA. The parent advertises the Home Aggregation to the proxy over HA. The parent advertises the Home Aggregation to the proxy over
that tunnel, as it does over the internet. In return, the proxy that tunnel, as it does over the internet. In return, the proxy
advertises its own prefixes, and redistributes the Home Aggregation advertises its own prefixes, and redistributes the Home Aggregation
over the internet. Finally, the parent redistributes the route to over the internet. Finally, the parent redistributes the route to
the proxy's network into its area, via itself, as an external route. the proxy's network into its area, via itself, as an external route.
4.2 Binding 5.2 Binding
At that point, the primary sites are ready to accept bindings, either At that point, the primary sites are ready to accept bindings, either
directly from Mobile Routers or via proxy HAs. This is the runtime directly from Mobile Routers or via proxy HAs. This is the runtime
phase for HAHA. phase for HAHA.
A MR that is located close to its primary site will register there A MR that is located close to its primary site will register there
for its primary binding. In that case, the binding is direct. for its primary binding. In that case, the binding is direct.
Otherwise, the MR will use a proxy in order to bind locally, and the Otherwise, the MR will use a proxy in order to bind locally, and the
proxy will perform the primary binding on behalf of the MR. If the proxy will perform the primary binding on behalf of the MR. If the
proxy is parented at the primary site, the binding is local; proxy is parented at the primary site, the binding is local;
otherwise, it is called a foreign binding. otherwise, it is called a foreign binding.
4.2.1 Direct primary binding 5.2.1 Direct primary binding
When the primary HA accepts a direct binding from a MR, then it must When the primary HA accepts a direct binding from a MR, then it must
let the other primaries know that it owns the binding for that Home let the other primaries know that it owns the binding for that Home
Address, in a fashion that is discussed in Section 9.2. Address, in a fashion that is discussed in Section 10.2.
...... ......
......../. ... --------------------------- ......../. ... ---------------------------
... ; .. | Site1 | ... ; .. | Site1 |
.. / Home::/32 ->.| ñ--ñ--ñ | .. / Home::/32 ->.| @--@--@ |
... ; .. | / | ... ; .. | / |
.... / MR ==MRHA==== ñ <- Home:site1:MNP::/64 | .... / MR ==MRHA==== @ <- Home:site1:MNP::/64 |
.... ; | .. | \ | .... ; | .. | \ |
... / ------ ... | ñ--ñ | ... / ------ ... | @--@ |
... ; MNP | | ... ; MNP | |
... / .. ... --------------------------- ... / .. ... ---------------------------
........... ...........
Primary HA injects necessary MR routes in area Primary HA injects necessary MR routes in area
The primary HA installs all (implicit and explicit) routes to the MR The primary HA installs all (implicit and explicit) routes to the MR
MNPs over the MRHA tunnel. It must also inject any required route, MNPs over the MRHA tunnel. It must also inject any required route,
such as explicit prefix routes, into the primary area, as external such as explicit prefix routes, into the primary area, as external
routes via itself. All these routes are summarized at the area routes via itself. All these routes are summarized at the area
border and the other areas are not affected by the routing change. border and the other areas are not affected by the routing change.
4.2.2 local proxy binding 5.2.2 local proxy binding
When a MR binds to a satellite site, a HA acts as a proxy and binds When a MR binds to a satellite site, a HA acts as a proxy and binds
in turn with a primary site, on behalf of that MR, to create the in turn with a primary site, on behalf of that MR, to create the
primary binding. The proxy binding can only succeed if the primary primary binding. The proxy binding can only succeed if the primary
binding does. If the primary accepts the binding, then it returns a binding does. If the primary accepts the binding, then it returns a
positive Binding Ack, with the list of the prefixes that are routed positive Binding Ack, with the list of the prefixes that are routed
via the Mobile Router. via the Mobile Router.
.. ........ .. ........
--------- .. . ... ------------------ --------- .. . ... ------------------
| Sat1 | .. /. | Site1 | | Sat1 | .. /. | Site1 |
| | <- Home::/32 ; . | | | | <- Home::/32 ; . | |
| | .. / .. | | | | .. / .. | |
| ---> =========================== ñ <- Home:site1 | | ---> =========================== @ <- Home:site1 |
| | |. / .. | :MNP::/64 | | | |. / .. | :MNP::/64 |
| -- # ======= MR ; ... | | | -- # ======= MR ; ... | |
| | . | / | | | | . | / | |
--------- . ----- ; ... ------------------ --------- . ----- ; ... ------------------
MNP.../.. MNP.../..
Then the proxy HA installs the routes that it got from the the Then the proxy HA installs the routes that it got from the the
positive Binding Acknowledgement over the proxy MRHA tunnel, and positive Binding Acknowledgement over the proxy MRHA tunnel, and
Acknowledges the proxy BU. Once a primary binding has succeeded, the Acknowledges the proxy BU. Once a primary binding has succeeded, the
proxy might establish secondary bindings with other sites. proxy might establish secondary bindings with other sites.
4.2.3 Foreign proxy binding 5.2.3 Foreign proxy binding
When a MR binds to a foreign site, whether the site is primary or When a MR binds to a foreign site, whether the site is primary or
satellite, a HA from the site acts as a proxy as if the site was a satellite, a HA from the site acts as a proxy as if the site was a
satellite from the primary. satellite from the primary.
----------------- .. .. ... ----------------- ----------------- .. .. ... -----------------
| Foreign site | .. .. | . | MR primary Site | | Foreign site | .. .. | . | MR primary Site |
| ------------------------ | | ------------------------ |
| +-------------------------------------- primary | | +-------------------------------------- primary |
| | +----------proxyHAHA----------------- | | | +----------proxyHAHA----------------- |
skipping to change at page 13, line 5 skipping to change at page 14, line 5
-------|| ||----- .. | .. ----------------- -------|| ||----- .. | .. -----------------
|| || - . - . - . - . - . || || - . - . - . - . - .
-------|| ||----- | . -------|| ||----- | .
| | | |. |MNP . .. | | | |. |MNP . ..
| proxy --MRHA--- MR-| | ... | proxy --MRHA--- MR-| | ...
| HA --------- | | ... | HA --------- | | ...
| | .. . . | | .. . .
|Foreign satellite|<- Home::/32 | . |Foreign satellite|<- Home::/32 | .
----------------- ... .. ... ----------------- ... .. ...
4.3 Path improvements 5.3 Path improvements
When the MR binds in a foreign location, the transport between an When the MR binds in a foreign location, the transport between an
arbitrary correspondent and the MR within the HAHA network might be arbitrary correspondent and the MR within the HAHA network might be
far from optimized. far from optimized.
As a result of the primary binding, a proxyHAHA tunnel is established As a result of the primary binding, a proxyHAHA tunnel is established
between the proxy and the primary HA. That tunnel is itself between the proxy and the primary HA. That tunnel is itself
encapsulated in the HAHA tunnels when packets flow over the internet. encapsulated in the HAHA tunnels when packets flow over the internet.
.. .. |... .. .. |...
skipping to change at page 14, line 7 skipping to change at page 15, line 7
Also, packets from an arbitrary correspondent reach the site that is Also, packets from an arbitrary correspondent reach the site that is
closest to the correspondent, then forwarded to the primary site for closest to the correspondent, then forwarded to the primary site for
the destination. Within the primary site, they are encapsulated the destination. Within the primary site, they are encapsulated
towards the proxy and sent across the HAHA network again. Finally towards the proxy and sent across the HAHA network again. Finally
they reach the proxy that decapsulates the packets and encapsulates they reach the proxy that decapsulates the packets and encapsulates
them back. them back.
In order to improve this, various possibilities are offered: In order to improve this, various possibilities are offered:
4.3.1 Leaking MNP routes in the HAHA network 5.3.1 Leaking MNP routes in the HAHA network
The proxy can establish a secondary binding with its parent. In The proxy can establish a secondary binding with its parent. In
return, the parent redistributes an external route to the MNP via return, the parent redistributes an external route to the MNP via
itself, and leaks that route inside the whole HAHA network. itself, and leaks that route inside the whole HAHA network.
.. .. |... .. .. |...
----------------- .. . .. ----------------- .. . ..
| Foreign site | .. | . | Foreign site | .. | .
| ----------------------------------+ | ----------------------------------+
| parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< |
skipping to change at page 15, line 5 skipping to change at page 16, line 5
This bypasses the primary home agent for packet forwarding. Note This bypasses the primary home agent for packet forwarding. Note
that the packets still flow within the HAHA network between the that the packets still flow within the HAHA network between the
ingress site close to the correspondent and the egress (satellite) ingress site close to the correspondent and the egress (satellite)
site. site.
Note also that when the proxy HA binds to either its parent or the Note also that when the proxy HA binds to either its parent or the
primary HA, it uses an address from within the HAHA network (its HAHA primary HA, it uses an address from within the HAHA network (its HAHA
Address), as CareOf. Address), as CareOf.
4.3.2 On-demand proxy routes 5.3.2 On-demand proxy routes
The proxy can establish a secondary binding with the correspondent's The proxy can establish a secondary binding with the correspondent's
proxy provided there's such a node. It might be envisioned to adapt proxy provided there's such a node. It might be envisioned to adapt
NHRP [5] for IPv6 in order to discover the remote tunnel end point. NHRP [11] for IPv6 in order to discover the remote tunnel end point.
----------------- .... ----------------- ....
| | .... .. | | .... ..
| egress satellite|<- Home::/32 | . .. | egress satellite|<- Home::/32 | . ..
| | .. . | | .. .
| --MRHA--- |MNP1 .. | --MRHA--- |MNP1 ..
| proxyHA >>>>>>>>>> MR1-| .. | proxyHA >>>>>>>>>> MR1-| ..
| --------- | ... | --------- | ...
| ^ | .. | ^ | ..
------| ^ |------ .. ------| ^ |------ ..
skipping to change at page 16, line 5 skipping to change at page 17, line 5
proxy passes all the MNPs for the MR as explicit prefix routes. It proxy passes all the MNPs for the MR as explicit prefix routes. It
is expected that the proxies belong to a chain of trust that links is expected that the proxies belong to a chain of trust that links
the primary and the satellite sites together. This, the ingress the primary and the satellite sites together. This, the ingress
proxy trusts the egress proxy both for the binding and for the proxy trusts the egress proxy both for the binding and for the
explicit prefixes. explicit prefixes.
Note that in that case, the binding uses the proxy's external address Note that in that case, the binding uses the proxy's external address
as careof. The packets are thus routed straight between the proxies, as careof. The packets are thus routed straight between the proxies,
outside of the HAHA network. outside of the HAHA network.
5. Terminology and concepts 6. Terminology and concepts
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC2119 [1]. interpreted as described in RFC2119 [7].
Most of the mobility related terms used in this document are defined Most of the mobility related terms used in this document are defined
in the Mobility Related Terminology document [8] and in the Mobile in the Mobility Related Terminology document [14] and in the Mobile
IPv6 specification [9]. IPv6 specification [15].
Additionally, some terms were created or extended for NEMO. These Additionally, some terms were created or extended for NEMO. These
specific terms are defined in the NEMO Terminology document [13]. specific terms are defined in the NEMO Terminology document [4].
This draft introduces the following definitions: This draft introduces the following definitions:
Distributed Home Network: In distributed home network, a global Home Distributed Home Network: In distributed home network, a global Home
is advertised by several sites that are geographically distributed is advertised by several sites that are geographically distributed
and meshed using tunnels in a VPN fashion. Mobile Nodes locate and meshed using tunnels in a VPN fashion. Mobile Nodes locate
the closest site using DHAAD and bind there. More in Section 6... the closest site using DHAAD and bind there. More in Section 7...
Partitioned Home Network: A Partitioned Home is a specific deployment Partitioned Home Network: A Partitioned Home is a specific deployment
of a Distributed Home Network where each location owns a subnet of of a Distributed Home Network where each location owns a subnet of
Home. The local Home Agents accept registration for the local Home. The local Home Agents accept registration for the local
partition. The local HAs also act as NEMO proxy HAs for the rest partition. The local HAs also act as NEMO proxy HAs for the rest
of Home. of Home.
Primary Home Agent: A Home Agent that can serve a Binding Update from Primary Home Agent: A Home Agent that can serve a Binding Update from
a Mobile Router. The Mobile Router is always associated with a a Mobile Router. The Mobile Router is always associated with a
(set of) primary Home Agent (s) to register its binding. (set of) primary Home Agent (s) to register its binding.
skipping to change at page 16, line 46 skipping to change at page 17, line 46
proxy HA acts as a HA for MRs to register, but needs to register proxy HA acts as a HA for MRs to register, but needs to register
to a primary HA in order to accept the binding. to a primary HA in order to accept the binding.
Primary site: A site is primary for a MR if at least one local HA on Primary site: A site is primary for a MR if at least one local HA on
that site can accept a registration for that MR. When Home is not that site can accept a registration for that MR. When Home is not
partitioned and sites overlap, primary HAs for a same subnet have partitioned and sites overlap, primary HAs for a same subnet have
to be aware of each other in order to find if a binding already to be aware of each other in order to find if a binding already
exists in one of the sites and in which Home Agent. exists in one of the sites and in which Home Agent.
satellite site: A site that is not primary for any binding. It is satellite site: A site that is not primary for any binding. It is
dependent on a parent primary site for HAHA operations. satellite dependent on a parent primary site for HAHA operations. satellite
sites are deployed around central primary sites, and one final sites are deployed around central primary sites, and one final
goal for HAHA is to dynamically draw routes between satellite goal for HAHA is to dynamically draw routes between satellite
sites in order to shortcut the backbone of primary HAs. sites in order to shortcut the backbone of primary HAs.
Secondary site: A site is secondary for a MR if it is primary for Secondary site: A site is secondary for a MR if it is primary for
other MRs but not that one. HAs in a secondary site can act as other MRs but not that one. HAs in a secondary site can act as
proxies for that MR, and the site is its own parent. proxies for that MR, and the site is its own parent.
Primary Binding: A Binding is primary if it happens with a primary Primary Binding: A Binding is primary if it happens with a primary
Home Agent, whether the client is a MR or a proxy HA. Home Agent, whether the client is a MR or a proxy HA.
skipping to change at page 18, line 5 skipping to change at page 19, line 5
Proxy Binding: A Binding is proxy if it happens between a MR and a Proxy Binding: A Binding is proxy if it happens between a MR and a
proxy HA, whether the proxy is a pure proxy HA or a secondary HA proxy HA, whether the proxy is a pure proxy HA or a secondary HA
acting as proxy for that MR. The proxy HA relays the proxy acting as proxy for that MR. The proxy HA relays the proxy
binding to a primary HA in a primary binding. It may maintain a binding to a primary HA in a primary binding. It may maintain a
set of secondary bindings, depending on the deployment. set of secondary bindings, depending on the deployment.
Direct Binding: A Binding that does not pass via a proxy, straight Direct Binding: A Binding that does not pass via a proxy, straight
between the MR and its Home Agent. between the MR and its Home Agent.
6. Distributed Home Network 7. Distributed Home Network
This section describes a detailed example how multiple Home Agents This section describes a detailed example how multiple Home Agents
are configured in different routing domains. You are encouraged to are configured in different routing domains. You are encouraged to
read the nemo basic Home Network Models [12] draft before going read the nemo basic Home Network Models [3] draft before going
through this section. through this section.
HA HA HA HA
| ______ | | ______ |
--+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+--
| | | | ______ | | | | | | | | ______ | | | |
MR1 MR2 MRi MRN MR1 MR2 MRi MRN MR1 MR2 MRi MRN MR1 MR2 MRi MRN
------ ------ ------ ------ ------ ------ ---- - ---- ------ ------ ------ ------ ------ ------ ---- - ----
/64 A:B:1:i::/64 /64 A:B:n:i::/64 /64 A:B:1:i::/64 /64 A:B:n:i::/64
skipping to change at page 18, line 32 skipping to change at page 19, line 32
extended HN Aggregated HN Virtual HN extended HN Aggregated HN Virtual HN
<----------------------><---------------------->...<---------------> <----------------------><---------------------->...<--------------->
Home Mob Mob Mob Mob Mob Mob Mob Home Mob Mob Mob Mob Mob Mob Mob
<-----><----->...<-----><-----><----->...<----->...<----->...<-----> <-----><----->...<-----><-----><----->...<----->...<----->...<----->
In distributed home network, a global Home is advertised by several In distributed home network, a global Home is advertised by several
sites that are geographically distributed and meshed using tunnels in sites that are geographically distributed and meshed using tunnels in
a VPN fashion. Mobile Nodes locate the closest site using DHAAD a VPN fashion. Mobile Nodes locate the closest site using DHAAD
against the global Home Network and bind there. Some form of against the global Home Network and bind there. Some form of inter-
inter-site synchronization (e.g. a routing protocol), which Mobile site synchronization (e.g. a routing protocol), which Mobile IPv6 and
IPv6 and Nemo Basic Support do not provide, must take place in order Nemo Basic Support do not provide, must take place in order to allow
to allow packets to be routed between the incoming site to the Mobile packets to be routed between the incoming site to the Mobile Node.
Node. The HAHA (Home Agent to Home Agent) protocol is being designed The HAHA (Home Agent to Home Agent) protocol is being designed for
for that purpose. that purpose.
In one model, called the Partitioned Home Network each site is In one model, called the Partitioned Home Network each site is
responsible for a subnet of Home. When a Mobile Node roams far from responsible for a subnet of Home. When a Mobile Node roams far from
its natural (primary) site, it registers to a Home Agent on a remote its natural (primary) site, it registers to a Home Agent on a remote
site, that takes the registration and notifies at least the natural site, that takes the registration and notifies at least the natural
site of the foreign registration. site of the foreign registration.
One specific advantage of not relying on a Home Link for HAHA One specific advantage of not relying on a Home Link for HAHA
communication is that for a large configuration, the Home Agents can communication is that for a large configuration, the Home Agents can
be organized hierarchically and distributed geographically, as a set be organized hierarchically and distributed geographically, as a set
of local clusters linked together to form a global Home Network. of local clusters linked together to form a global Home Network.
7. Message Formats 8. Message Formats
8. Mobile Router Operation A traditional IGP coul be used over the HAHA tunnel. But in order to
integrate HAHA smoothly with the rest of the MIP operation, this
drafts suggest to use the messages and formats detailed in the HAHA
specification [17].
8.1 Locating Home 9. Mobile Router Operation
8.2 Proxy MIP client 9.1 Locating Home
9. Home Agent Operation 9.2 Proxy MIP client
9.1 Locating the other HAs that serve the same Home 10. Home Agent Operation
9.2 Locating the HA that owns the binding for a HoA 10.1 Locating the other HAs that serve the same Home
10.2 Locating the HA that owns the binding for a HoA
At the time of processing a binding update, a Home Agent (be it At the time of processing a binding update, a Home Agent (be it
primary or simply proxy for the binding Home Address) needs to primary or simply proxy for the binding Home Address) needs to
discover if the binding already exists with a primary Home Agent. discover if the binding already exists with a primary Home Agent.
There are at least 3 approaches that might be deployed for that There are at least 3 approaches that might be deployed for that
purpose: purpose:
Reactive: This method is also referred to as 'on-demand'. In case of Reactive: This method is also referred to as 'on-demand'. In case of
a binding cache miss, a primary Home Agent floods a Binding a binding cache miss, a primary Home Agent floods a Binding
Information Request message to all the other primary Home Agents Information Request message to all the other primary Home Agents
skipping to change at page 19, line 45 skipping to change at page 21, line 5
which primary Home Agent. This approach is preferred for stable which primary Home Agent. This approach is preferred for stable
configurations, for instance if NEMO is used as a tool to simplify configurations, for instance if NEMO is used as a tool to simplify
the configuration and reconfiguration of mostly stable networks. the configuration and reconfiguration of mostly stable networks.
Predictive: Ranges of Home Addresses and prefixes are preassigned to Predictive: Ranges of Home Addresses and prefixes are preassigned to
the Home Agents, following a rule that is shared or commonly the Home Agents, following a rule that is shared or commonly
computed by all HAs. A partitioned Home Network is an example of computed by all HAs. A partitioned Home Network is an example of
that, but this is mostly useful within a site between local Home that, but this is mostly useful within a site between local Home
Agents. Agents.
10. Acknowledgements 11. Acknowledgements
The authors wish to thank: The authors wish to thank:
11 References 12. IANA considerations
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement This document does not require any IANA action.
13. Security Considerations
This document explores how t use the haha protocol but does not
standardize any new operation that would be harmful.
14. Changes
14.1 Changes from version 00 to 01
Added a proxy section to introduce the concept
15. References
15.1 informative reference
[1] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-00 (work in progress),
July 2005.
[2] Patel, A., "Problem Statement for bootstrapping Mobile IPv6",
draft-ietf-mip6-bootstrap-ps-03 (work in progress), July 2005.
[3] Thubert, P., "NEMO Home Network models",
draft-ietf-nemo-home-network-models-04 (work in progress),
June 2005.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress),
February 2005.
[5] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-04 (work in progress),
February 2005.
[6] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-03 (work in progress),
July 2005.
15.2 normative reference
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address [10] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[5] Fox, B. and B. Petri, "NHRP Support for Virtual Private [11] Fox, B. and B. Petri, "NHRP Support for Virtual Private
Networks", RFC 2735, December 1999. Networks", RFC 2735, December 1999.
[6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[7] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December Configuration Protocol (DHCP) version 6", RFC 3633,
2003. December 2003.
[8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC [14] Manner, J. and M. Kojo, "Mobility Related Terminology",
3753, June 2004. RFC 3753, June 2004.
[9] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [15] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[10] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", [16] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[11] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[12] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home
Network models", draft-ietf-nemo-home-network-models-00 (work
in progress), April 2004.
[13] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-01 (work in progress), February
2004.
[14] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-02 (work in progress), February
2004.
[15] Ernst, T., "Analysis of Multihoming in Network Mobility [17] Wakikawa, R., "Inter Home Agents Protocol Specification",
Support", draft-ietf-nemo-multihoming-issues-00 (work in draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress),
progress), July 2004. October 2004.
Authors' Addresses Authors' Addresses
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
Phone: +33 4 97 23 26 34 Phone: +33 4 97 23 26 34
EMail: pthubert@cisco.com Email: pthubert@cisco.com
Ryuji Wakikawa Ryuji Wakikawa
Keio University and WIDE Keio University and WIDE
5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa
252-8520 252-8520
JAPAN JAPAN
EMail: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
Vijay Devarapalli Vijay Devarapalli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
EMail: vijay.devarapalli@nokia.com Email: vijay.devarapalli@nokia.com
Intellectual Property Statement Intellectual Property Statement
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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 22, line 41 skipping to change at page 24, line 41
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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 81 change blocks. 
140 lines changed or deleted 232 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/