Internet DRAFT - draft-makela-mip4-nemo-haaro
draft-makela-mip4-nemo-haaro
Network Working Group A. Makela
Internet-Draft J. Korhonen
Intended status: Experimental TeliaSonera
Expires: May 4, 2009 Oct 31, 2008
Home Agent assisted Route Optimization between Mobile IPv4 Networks
draft-makela-mip4-nemo-haaro-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 4, 2009.
Abstract
This document describes a Home Agent assisted route optimization
extension to IPv4 Network Mobility Protocol.
Makela & Korhonen Expires May 4, 2009 [Page 1]
Internet-Draft HAaRO Oct 2008
Table of Contents
1. Introduction and motivations . . . . . . . . . . . . . . . . . 4
2. Terms and definitions . . . . . . . . . . . . . . . . . . . . 6
3. Mobile IPv4 route optimization between mobile networks . . . . 7
3.1. Maintaining route optimization information . . . . . . . . 8
3.1.1. Advertising route-optimizable prefixes . . . . . . . . 8
3.1.2. Route Optimization cache . . . . . . . . . . . . . . . 9
3.1.3. Correspondent Router Mobility Bindings . . . . . . . . 10
3.2. Return routability procedure . . . . . . . . . . . . . . . 10
3.2.1. Router keys . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Mobile-Correspondent Router operations . . . . . . . . . . 12
3.3.1. Triggering Route Optimization . . . . . . . . . . . . 12
3.3.2. Mobile Router routing tables . . . . . . . . . . . . . 13
3.3.3. Inter-Mobile Router registration . . . . . . . . . . . 13
3.3.4. Inter-Mobile Router tunnels . . . . . . . . . . . . . 14
3.3.5. Constructing route-optimized packets . . . . . . . . . 15
3.3.6. Handovers and Mobile Routers leaving network . . . . . 15
3.4. Convergence and synchronization issues . . . . . . . . . . 16
4. Data compression schemes . . . . . . . . . . . . . . . . . . . 17
4.1. Prefix compression . . . . . . . . . . . . . . . . . . . . 17
4.2. Realm compression . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Encoding of compressed realms . . . . . . . . . . . . 19
4.2.2. Searching algorithm . . . . . . . . . . . . . . . . . 20
4.2.3. Encoding example . . . . . . . . . . . . . . . . . . . 21
5. New Mobile IPv4 messages and extensions . . . . . . . . . . . 23
5.1. Route optimization prefix advertisement . . . . . . . . . 23
5.2. Mobile router Route optimization capability . . . . . . . 24
5.3. Home-Test Init message . . . . . . . . . . . . . . . . . . 25
5.4. Care-of-Test Init message . . . . . . . . . . . . . . . . 25
5.5. Home Test message . . . . . . . . . . . . . . . . . . . . 26
5.6. Care-of test message . . . . . . . . . . . . . . . . . . . 26
5.7. Mobile-Correspondent authentication extension . . . . . . 27
5.8. Care-of address Extension . . . . . . . . . . . . . . . . 28
6. Special Considerations . . . . . . . . . . . . . . . . . . . . 28
6.1. NATs and stateful firewalls . . . . . . . . . . . . . . . 28
6.2. Foreign Agents . . . . . . . . . . . . . . . . . . . . . . 28
6.3. Multiple Home Agents . . . . . . . . . . . . . . . . . . . 29
6.4. Mutualness of Route Optimization . . . . . . . . . . . . . 29
6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 30
7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Example signaling scenarios . . . . . . . . . . . . . . . . . 31
8.1. Registration request . . . . . . . . . . . . . . . . . . . 31
8.2. Route optimization with return routability . . . . . . . . 32
8.3. Handovers . . . . . . . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
Makela & Korhonen Expires May 4, 2009 [Page 2]
Internet-Draft HAaRO Oct 2008
10.1. Trust relationships . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
Makela & Korhonen Expires May 4, 2009 [Page 3]
Internet-Draft HAaRO Oct 2008
1. Introduction and motivations
Traditionally, there has been no method for route optimization in
Mobile IPv4 [RFC3344] apart from an early attempt
[I-D.ietf-mobileip-optim]. Unlike Mobile IPv6 [RFC3775], where route
optimization has been included from the start, Mobile IPv4 route
optimization hasn't been addressed in a generalized scope.
Even though general route optimization may not be of interest in IPv4
world, there are still specific applications for route optimization
in Mobile IPv4. This draft proposes method to optimize routes
between mobile networks behind mobile routers, as defined by NEMO
[RFC5177].
From service provider perspective a common topology for enterprise
customer network consists of one to several sites (typically
headquarters and various branch offices). These sites are typically
connected via various Layer 2 technologies (ATM or Frame relay PVCs),
MPLS VPNs or Layer 3 site-to-site VPNs.
Recently, a trend has emerged where customers prefer to maintain
connectivity via multiple service providers. Reasons include
redundancy, reliability and availability issues. These kinds of
multi-homing scenarios have traditionally been solved by using such
technologies as multihoming BGP. However, a more lightweight
solution is desirable.
Mobile IP, especially mobile routers, can accommodate for this. The
customer becomes a client of a virtual service provider, which does
not take part in the actual access technology. The service provider
has a backend system and an IP pool that it distributes to customers.
The drawback of this solution is that it creates a star topology; All
Mobile IP tunnels end up at the service provider hosted home agent,
causing heavy load at the backend. Route optimization between mobile
networks addresses this issue, by taking network load off the home
agent and the backend.
An example network is pictured below:
Makela & Korhonen Expires May 4, 2009 [Page 4]
Internet-Draft HAaRO Oct 2008
+----------------------------+
| Virtual Operator Backend |
+------------+ +-----+
| Home Agent | | AAA |
+------------+---------+-----+
|
.--.
_(. `)
_( ISP `)_
( Peering `)
( ` . Point ) )
`--(_______)--'
____ / | \
/ | \
.--. .--. .--.
_( `. _( `. _( `.
( ISP A ) ( ISP B ) ( ISP C )
( ` . ) ) ( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-' `--(___.-'
| ______/ \ /
| / \ /
| / \ /
+----+ +----+
|MR A| |MR B|
+----+ +----+
| |
.--. .--.
_( `. _( `.
( Site A ) ( Site B )
( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-'
Virtual service provider architecture using NEMOv4
In this case, organization network consists of two sites, that are
connected via 2 ISPs for redundancy reasons. Mobile IP allows fast
handovers without problematics of multi-homing and BGP peering
between each individual ISP and the organization. The traffic
however takes a non-optimal route through the virtual operator
backend.
Route optimization would address this issue, allowing traffic between
Sites A and B to flow through ISP B's network, or in case of a link
failure, via the ISP peering point (such as MAE-WEST). The backend
will not suffer from heavy loads.
The primary design goal is to limit the load to the backend to
minimum. Additional design goals include extensibility to a more
Makela & Korhonen Expires May 4, 2009 [Page 5]
Internet-Draft HAaRO Oct 2008
generalized scope, beyond the need of a single, coordinating Home
Agent.
2. Terms and definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Home Agent (HA)
Mobile IPv4 Home Agent
Mobile Router (MR)
Nemov4 Mobile Router
Home Address (HoA)
Mobile Router's home address
Care-of Address (CoA)
Mobile Router's Care-of Address. Address serving as the current
attachment point.
Correspondent Router (CR)
Nemov4 Mobile Router which is destination for a Mobile network-
initiated flow.
Mobile Network
Network managed by a Mobile Router
Route Optimization Cache
Data structure held by Mobile Routers on Route Optimizable
destinations.
Route Optimization activation
Procedure consisting of Return Routability check, registration,
setting up tunnels (if necessary) and starting to route traffic
along the tunnel.
Makela & Korhonen Expires May 4, 2009 [Page 6]
Internet-Draft HAaRO Oct 2008
Host Prefix
Prefix with the mask of /32. eg. 192.0.2.254/32.
Return Routability, RR
Procedure to bind a Mobile Router's Home Address to a Care-of
address on a Correspondent Router
Mobility Binding
The association of Home Address with a Care-of address, along
with the lifetime remaining for that association, maintained by
Home Agents and Correspondent Routers.
Mobility Session
Active connection to Home Agent and Correspondent Routers,
maintained by Mobile Routers.
3. Mobile IPv4 route optimization between mobile networks
This section describes the changed functionality of Home Agent and
Mobile Router compared to the base NEMOv4 operation defined in NEMO-
base [RFC5177]. The basic premise is still the same; Mobile Routers,
when registering, inform the Home Agent of the mobile networks they
are managing; However, instead of only remaining on the Home Agent
this information will now be distributed to the Mobile Routers as
well.
The Home Agent-assisted route optimization is primarily intended for
helping to optimize traffic patterns between multiple sites in an
single organization or administrative domain; However, extranets can
also be reached with optimized routes, as long as all Mobile Routers
connect to the same Home Agent. The procedure aim to maintain
backwards compatibility; With legacy nodes or routers full
connectivity is always preserved even though optimal routing cannot
be guaranteed.
The schema requires a Mobile Router to be able to receive messages
from Home Agent and other Mobile Routers unsolicited - that is,
without first initiating a request. This behavior is similar to the
registration revocation procedure [RFC3543]. Many of the mechanisms
are same - including the fact that advertising route optimization
support upon registration implies capability to receive registration
requests and return routability messages from other Mobile Routers.
Makela & Korhonen Expires May 4, 2009 [Page 7]
Internet-Draft HAaRO Oct 2008
Compared to IPv6, where Mobile Node <-> Correspondent node bindings
are maintained via Mobility Routing header and Home Address options,
Mobile IPv4 always requires the use of tunnels. Therefore, inter-
mobile-router tunnel establishment has to be conducted.
3.1. Maintaining route optimization information
During registration, a joining Mobile Router MAY request information
on route-optimizable networks and let the Home Agent allow re-
distribution of information of its own networks. This is indicated
with Mobile Router route optimization capability extension, see
Section 5.2.
Note that the redistribution of networks from the Home Agent happens
only during the registration phase. There are no "routing updates"
from Home Agent except in the form of re-registration. Besides
timeouts, the re-registration may occur if a Correspondent Router
receives a registration request from a unknown Mobile Router (see
Section 3.3.3).
3.1.1. Advertising route-optimizable prefixes
A NEMO-supporting Home Agent already maintains information on which
network(s) are reachable behind certain Mobile Routers. Only change
to this functionality is that this information can now be distributed
to other nodes upon request. This request is defined in Section 5.2.
When a Home Agent receives a registration request, it conducts the
normal authentication and authorization procedures.
If registration is successful and the route optimization request was
present in the registration request, the reply message MAY include
one route optimization prefix advertisement extensions which inform
the Mobile Router of all existing mobile networks and the Mobile
Routers that manage them. The networks SHOULD be included in order
of priority, with the networks most desired to conduct optimization
listed first. The extension is constructed as shown in Section 5.1.
The extension consists of a list where each Mobile Router is listed
with according prefix(es) and their respective realm(s).
Each network prefix can be associated to a realm, usually of form
'@organization.example.com'. Besides the routers in customer's own
organization, the prefix list may also include other Mobile Routers,
e.g. default prefix (0.0.0.0/0) pointing towards Internet gateway for
Internet connectivity, and possible extranets. The realm information
can be used to make policy decisions on the Mobile Router, such as
preferring optimization within specific realm only.
Makela & Korhonen Expires May 4, 2009 [Page 8]
Internet-Draft HAaRO Oct 2008
In common scenarios, where prefixes are allocated to Mobile Routers
connecting to a single Home Agent, the prefixes are usually either
continuous or at least very close to each other. Due to these
qualities, a prefix compression mechanism is provided. A similar
schema is in use for realm information, where realms often share same
higher-level domains. These compression mechanisms are further
examined in Section 4.
Upon receiving registration reply with the route optimization prefix
advertisement extension, the Mobile Router SHALL insert the Mobile
Router HoA as a host-prefix to the local Route Optimization Cache if
it does not already exist. If they are included, any additional
prefixes information SHALL also be inserted to the Route Optimization
Cache.
The Mobile Router MAY discard entries from a desired starting point
onwards, due to memory or other policy related constraints. The
intention of listing the prefixes in order of priority is to provide
implicit guidance for this decision. If the capacity of the device
allows, the Mobile Router SHOULD use information on all advertised
prefixes.
3.1.2. Route Optimization cache
Mobile routers supporting route optimization will maintain a Route
Optimization Cache.
The Route Optimization Cache contains mappings between Correspondent
Router HoA's, network(s) associated with each HoA and return
routability procedure status.
The Route Optimization Cache contains the following information for
all Correspondent Routers:
CR-HoA Correspondent Router's Home Address.
Prefixes A list of destination prefixes reachable via this
Correspondent Router. Includes network and prefix length,
e.g. 192.0.2.0/25. Always contains at least a single
entry, the CR-HoA host prefix in the form of 192.0.2.1/32.
Realm Destination realm. May be empty, if realm is not provided
by advertisement or configuration.
NAT The Correspondent Router is behind NAT/Firewall as seen
from HA. Set if 'O' bit is set in the received
advertisement. Affects tunnel establishment, see
Section 3.3.4. Also mandates use of UDP encapsulation.
Makela & Korhonen Expires May 4, 2009 [Page 9]
Internet-Draft HAaRO Oct 2008
RRSTATE Return routability state. States are INACTIVE, IN PROGRESS
and ACTIVE. If state is INACTIVE, return routability
procedure must be completed before forwarding route-
optimized traffic. If state is IN PROGRESS or ACTIVE, this
entry MUST NOT be removed from Route Optimization Cache as
long as tunnel to the Correspondent Router is established .
KRm Registration management key. Either established via return
routability procedure or configured statically. If
configured statically, RRSTATE is permanently set to
ACTIVE.
HA HA bit is set if this entry is learned from HA. This
implies that the entry can be trusted. If not set, the
entry has been learned from another Mobile Router and not
yet verified from HA. The entry may still be maintained
while awaiting verification.
3.1.3. Correspondent Router Mobility Bindings
Each Correspondent Router will maintain Mobility Bindings, in a
similar way to the Home Agent.
The Mobility Binding for each Mobile Router contains
HoA Mobile Router's Home Address
CoA Mobile Router's Care-of Address
Prefixes A list of destination prefixes bound to this Mobile Router.
Includes the Mobile Router itself as a host prefix, e.g.
192.0.2.1/32.
Realm Destination realm. May be empty, if realm not provided by
advertisement or configuration.
Tunnel Tunnel interface associated with the Mobile Router. The
tunnel interface itself handles all the necessary
operations to keep the tunnel operational, e.g. sends UDP
keepalives.
3.2. Return routability procedure
The return routability procedure for Mobile IPv6 is described in
[RFC3775]. Same principles apply to the Mobile IPv4 version: Two
messages are sent to Correspondent Router's Home Address, one via
Home Agent and the other directly from the Mobile Router CoA, with
two responses coming through same routes. Registration management
Makela & Korhonen Expires May 4, 2009 [Page 10]
Internet-Draft HAaRO Oct 2008
key is derived from token information carried on these messages.
This registration management key (KRm) can then be used to
authenticate registration requests (comparable to Binding Updates in
Mobile IPv6).
The Return Routability procedure is a method provided by Mobile IP
protocol to establish the KRm in a relatively lightweight fashion.
If desired, the KRm's can be configured to Mobile Routers statically,
or using an appropriate secure key provisioning mechanism. If KRm's
are known to the Mobile Routers via some other mechanism, Return
Routability procedure can be skipped. Such provisioning mechanisms
are out of scope for this document.
Assumption on traffic patterns is that the Mobile Router that
initiates the RR procedure can always send outbound messages, even
when behind NAT or firewall. This basic assumption made for NAT
Traversal in [RFC3519] is also applicable here. In case the
Correspondent Router is behind such obstacles, it receives these
messages via the reverse tunnel to CR's Home Address, thus any
problem regarding the CR's connectivity is addressed during the
registration phase.
3.2.1. Router keys
Each Correspondent Router maintains a router key, Kcr, which is not
shared with anyone else. This is analogous to node key, Kcn, in
Mobile IPv6. Correspondent Router uses router key to verify that the
keygen tokens sent by Mobile Router in registration request are its
own. The router key MUST be a random number, 96 bits in length.
3.2.2. Nonces
Each Correspondent Router also maintains one or more indexed nonces.
Nonces should be generated periodically with a good random number
generator. The Correspondent Router may use same nonces with all
Mobile Routers.
Correspondent Routers keep both the current nonce and small set of
valid previous nonces whose lifetime have not expired yet.
Return Routability procedure may be initiated only when the Route
Optimization Cache's RRSTATE field for the Correspondent Router is
INACTIVE. When Return Routability procedure is initiated, the state
MUST be set to IN PROGRESS.
The Return Routability procedure consists of four new Mobile IP
messages: Home Test Init, Care-of Test Init, Home Test and Care-of
Test. They are constructed as shown in Section 5.3 through
Makela & Korhonen Expires May 4, 2009 [Page 11]
Internet-Draft HAaRO Oct 2008
Section 5.6. If the Mobile Router has included the Mobile Router
optimization capability extension in its Registration Request, it
MUST be able to accept Return Routability messages. The messages are
delivered as standard Mobile IP packets. The addresses are set to
Correspondent Router's HoA and Mobile Router's CoA.
The return routability procedure begins with the Mobile Router
sending HoTI and CoTI messages, each containing a cookie.
Upon receiving the HoTI or CoTI message the Correspondent Router MUST
have a secret Kcr. If the Kcr does not exist, it must be produced
before continuing with the return routability procedure.
Correspondent Router responds to HoTI and CoTI messages by
constructing HoT and CoT messages, respectively, as replies. HoT
message contains current home nonce index and CoT message contains
current care-of nonce index.
Upon completion of Return Routability procedure, the Routing
Optimization Cache's RRSTATE field is set to ACTIVE. The Mobile
Router will establish a registration management key KRm:
KRm = SHA1 (home keygen token | care-of keygen token)
Like in Mobile IPv6, the Correspondent Router does not maintain any
state for the Mobile Router until after receiving a registration
request.
3.3. Mobile-Correspondent Router operations
This section deals with the operation of Mobile and Correspondent
Routers performing route optimization. Note that in a typical case
all routers work as both Mobile Router and Correspondent Router.
Especially compared to Mobile IPv6 route optimization there are two
issues that are different regarding IPv4. First of all, since Mobile
IPv4 always uses tunnels, there must be a tunnel established between
MR and CR's Care-of addresses. This is accomplished with a new
extension, "Care-of Address", in registration reply. Second issue is
rising from security standpoint: In a registration request, the
Mobile Router claims to represent an arbitrary IPv4 network. If the
CR has not yet received this information (HoA <-> Network prefix), it
SHOULD perform a re-registration to Home Agent to verify the claim.
3.3.1. Triggering Route Optimization
Since each Mobile Router knows all the route-optimizable networks,
the route optimization between all Correspondent Routers can be
Makela & Korhonen Expires May 4, 2009 [Page 12]
Internet-Draft HAaRO Oct 2008
established at any time; However a better general practice is to
conduct Route Optimization activation on-demand only. Route
optimization SHOULD only be started when receiving a packet where
destination address is local (and the subnet is registered as route
optimizable) and source address exists in the Route Optimization
Cache.
3.3.2. Mobile Router routing tables
Each Mobile Router maintains a routing table. In a typical
situation, it contains interface(s) to the local networks, interface
to wide-area network (such as ISP), and a tunnel interface to the
Home Agent. Additional entries consist of route-optimized tunnel
interfaces and networks associated with each tunnel.
3.3.3. Inter-Mobile Router registration
If route optimization between Mobile Router and Correspondent Router
is desired, either Return Routability procedure must have been
performed ( See Section 3.2), or key KRm must be pre-shared between
the Mobile and Correspondent Router. If a known KRm exists, a Mobile
Router MAY send a registration request to the Correspondent Router's
HoA.
The registration request's source address and Care-of address field
are set to the Mobile Router's Care-of address. The registration
request MUST include Mobile-Correspondent Authentication extension
defined in Section 5.7 and Mobile Network Request Extension defined
in [RFC5177]. If timestamps are used, the Correspondent Router MUST
check the identification field for validity. The registration
request MUST include Home Address. The Authenticator field is hashed
with the key KRm.
The encapsulation can be set as desired, except in the case where the
Correspondent Router's Route Optimization Cache Entry has NAT set or
the Mobile Router itself is behind NAT or firewall. If either of the
conditions apply, registration request MUST specify UDP
encapsulation.
The Correspondent Router first checks the registration request's
authentication against Kcr and nonce indexes negotiated during Return
Routability procedure. This ensures that the registration request is
coming from a correct Mobile Router. If the check passes, the
Correspondent Router MUST check whether the Mobile Router already
exists in it's Route Optimization Cache and is linked with the
prefixes included in the request.
If the prefixes don't match, the Correspondent Router SHOULD send a
Makela & Korhonen Expires May 4, 2009 [Page 13]
Internet-Draft HAaRO Oct 2008
re-registration request to Home Agent with the 'S' (solicitation) bit
set, thus obtaining the latest information on mobile prefixes managed
by incoming Mobile Router. If, even after this update, the prefixes
still don't match, the Correspondent Router MUST reject the
registration request. This verification is done to protect against
Mobile Router claiming to represent arbitrary networks; However,
since Home Agent provides trusted information, it can authorize
Mobile Router's claim. If the network is considered trusted, the
Correspondent Router can, as a policy, accept registrations from
without this check; however, this is NOT RECOMMENDED as a general
practice.
If the prefixes match, the Correspondent Router MAY accept the
registration. Upon receiving the registration reply, the Mobile
Router MUST check if a tunnel to the Mobile Router already exists.
Otherwise a tunnel MUST be established and Mobility Binding updated.
This is covered in Section 3.3.4.
The Correspondent Router's routing table MUST be updated to include
the Mobile Router's networks are reachable via the tunnel to the
Mobile Router.
After the tunnel is established, the Mobile Router MAY update it's
routing tables to reach all Correspondent Router's Prefixes via the
tunnel. This is primarily a policy decision depending on the network
environment. See section Section 6.4.
3.3.4. Inter-Mobile Router tunnels
Inter-Mobile Router tunnel establishment follows establishing
standard reverse tunnels to the Home Agent. The registration request
to Correspondent Router includes information on the desired
encapsulation. In the case of GRE, IP over IP or minimal
encapsulation no special considerations regarding the reachability
are necessary; The tunnel has no stateful information; The packets
are simply encapsulated within the GRE, IP, or minimal header.
The tunnel origination point for the Correspondent Router is its
Care-of Address, not the address where the registration requests were
sent. This is different from creation of the Reverse Tunnel to Home
Agent.
Special considerations rise from using UDP encapsulation, especially
in cases where one of the Mobile Routers is located behind NAT or
firewall. If the Route Optimization Cache has NAT bit set for a
specific network, the UDP tunnel establishment MUST be initiated from
the Correspondent Router. However, the procedure otherwise follows
[RFC3519]. Once the first UDP keepalive is sent, the tunnel can be
Makela & Korhonen Expires May 4, 2009 [Page 14]
Internet-Draft HAaRO Oct 2008
considered active.
If both the Mobile Router and the Correspondent Router are behind
NAT, route optimization cannot be performed between them.
Possibilities to set up mutual tunneling when both routers are behind
NAT, are outside the scope of this draft. However, some of these
issues are addressed in Section 6.1.
Due to the fact that the route optimization procedures may occur
concurrently at two Mobile Routers, each working as each other's
Correspondent Router, there may be a situation where two routers are
attempting to establish separate tunnels between them at the same
time. If a router with a smaller Home Address receives a
registration request (in CR role) while its own registration request
(sent in MR role) has not been answered yet, the reply must be held
until the tunnel initiated by its registration request is up. This
avoids the problem of maintaining two separate tunnels forming
concurrently between two Mobile Routers.
Since typical routers act as both MR's and CR's, tunnels can be only
torn down if there is no Mobility Bindings on the tunnel (in
Correspondent Router role) AND no Mobility Sessions are bound to the
tunnel (Mobile Router role). Both Mobility Sessions and Mobility
Bindings will go down when their lifetime expires.
3.3.5. Constructing route-optimized packets
All packets received by the Mobile Router are forwarded using normal
routing rules according to the routing table. There are no special
considerations when constructing the packets, the interface procedure
will encapsulate any packet automatically.
If prefixes overlap each other, e.g. 192.0.2.128/25 and
192.0.2.128/29, the standard longest match rule for routing is in
effect. However, overlapping private address SHOULD be considered an
error situation. Any aggregation for routes in private address space
SHOULD be conducted only at HA.
3.3.6. Handovers and Mobile Routers leaving network
Handovers and connection breakdowns can be categorized as either
ungraceful or graceful, or break-before-make and make-before-break
situations.
In a typical situation, router act as both Mobile Router and
Correspondent Router for other routers' prefixes.
When a Mobile Router wishes to leave network, it SHOULD send a re-
Makela & Korhonen Expires May 4, 2009 [Page 15]
Internet-Draft HAaRO Oct 2008
registration request to all Correspondent Routers with the lifetime
set to zero. If the Correspondent Router is also acting as a Mobile
Router with active Route Optimization with the leaving router, it
SHOULD send a similar re-registration request with the lifetime set
to zero. This causes both the Mobility Bindings and active Mobility
Sessions to go down, allowing for teardown of the tunnel.
If the Mobile Router was unable to send the re-registration request
before handover, it MUST send it immediately after handover is
completed and binding with the Home Agent is up. In a similar
fashion, Correspondent Router acting as a Mobile Router MUST realize
that the old Mobility Session is no longer valid and establish a new
one. Thus, route optimization can resume.
3.4. Convergence and synchronization issues
Home Agent state and Mobile Routers' Route Optimization Caches do not
need to be explicitly synchronized. The assumption is that at least
some of the traffic between mobile networks is always bidirectional.
This will cause Mobile Routers to perform re-registrations and thus
they will receive updates on-demand only.
Consider a situation with three mobile networks, A, B, C handled by
three Mobile Routers, MR A, MR B and MR C. If they register to a Home
Agent in this order, the situation goes as follows:
MR A registers; Receives no information on other networks from HA, as
no other MR has registered yet.
MR B registers; Receives information on mobile network A being
reachable via MR A.
MR C registers; Receives information on both of the other mobile
networks.
If a node in mobile network C receives traffic from mobile network A,
the route optimization is straightforward; MR C already has network A
in its Route Optimization Cache. When it registers to MR A (after
Return Routability procedure is completed), MR A does not have
information on mobile network C; Thus it will perform a re-
registration to the Home Agent on-demand. This allows MR A to verify
that MR C is indeed managing network C.
If a node in mobile network B receives to traffic from mobile network
C, MR B has no information on network C. No route optimization is
triggered. However, when network B's reply reaches MR C, route
optimization happens as above. Further examples of signaling are in
Section 8.
Makela & Korhonen Expires May 4, 2009 [Page 16]
Internet-Draft HAaRO Oct 2008
Even in the very rare case of completely unidirectional traffic from
an entire network, the re-registrations caused by timeouts will
eventually cause convergence. However, this should be treated as a
special case.
Note that all Mobile Routers are connected to same Home Agent. For
possibilities concerning multiple Home Agents, see Section 6.3
4. Data compression schemes
This section defines the two compression formats used in Route
Optimization Prefix Advertisement extensions.
4.1. Prefix compression
The prefix-compression is based on the idea that prefixes usually
share common properties. The scheme is simple delta-compression. In
the prefix information advertisement, Section 5.1, the D bit
indicates whether receiving a "master" or a "delta" prefix. This,
combined with the Prefix Length information, allows for compression
and decompression of prefix information.
If D=0, what follows in the "Prefix" field are bits 1..n of the a new
master prefix, where n is PLen. This is rounded up to nearest full
octet. Thus, prefix lengths of /4 and /8 take 1 octet, /12 and /16
take 2 octets, /20 and /24 three, and larger than that full 4 octets.
If D=1, what follows in the "Prefix" field are bits m..PLen of the
prefix, where m is the first changed bit of previous master prefix,
with padding from master prefix filling the field to full octet.
Maximum value of Plen-m is 8 (that is, delta MUST fit into one
octet). If this is not possible, a new master prefix has to be
declared.
Determining the order of prefix transmission should be based on
saving maximum space during transmission.
Example of compression and transmitted data, where network prefixes
192.0.2.0/28, 192.0.2.64/26 and 192.0.2.128/25 are transmitted are
illustrated. Because of the padding to full octets, redundant
information is also sent. The bit-patterns being transmitted are:
Makela & Korhonen Expires May 4, 2009 [Page 17]
Internet-Draft HAaRO Oct 2008
=+= shows the prefix mask
--- shows the master prefix for delta coded prefixes
192.0.2.0/28, D=0
0 1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+
^ ^
+---------------------------- encoded ------------------------------+
^ ^
+-pad-+
192.0.2.64/26, D=1
0 1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|1|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+-- padding --+
192.0.2.128/25, D=1
0 1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+- padding -+
First prefix, 192.0.2.0/28, is considered a master prefix and is
transmitted in full. The PLen of 28 bits determines that all four
octets must be transmitted. If the prefix would have been eg.
192.0.2.0/24, three octets would have sufficed since 24 bits fit into
3 octets.
For the following prefixes, the D=1. Thus, they are deltas of the
previous prefix where D was zero.
192.0.2.64/26 includes bits 19-26 (full octet). Bits 19-25 are
copied from master prefix, but bit 26 is changed to 1. The final
Makela & Korhonen Expires May 4, 2009 [Page 18]
Internet-Draft HAaRO Oct 2008
notation in binary is "1001", or 0x09.
192.0.2.128/25 includes bits 18-25 (full octet). Bits 18-24 are
copied from master prefix, but bit 25 is changed to 1. The final
notation in binary is "101", or 0x05.
The final encoding thus becomes:
+----------------+--------+-+---------------------+
| Prefix | Plen |D| Transmitted Prefix |
+----------------+--------+-+---------------------+
| 192.0.2.0/28 | 28 |0| 0xc0 0x00 0x02 0x00 |
| 192.0.2.64/26 | 26 |1| 0x09 |
| 192.0.2.128/25 | 25 |1| 0x05 |
+----------------+--------+-+---------------------+
It should be noted that in this case the order of prefix transmission
would not affect compression efficiency. If prefix 192.0.2.128/25
would have been considered the master prefix and the others as deltas
instead, the resulting encoding still fits into one octet for the
subsequent prefixes. There would be no need to declare a new master
prefix.
4.2. Realm compression
4.2.1. Encoding of compressed realms
In order to reduce the size of messages, the system introduces a
realm compression scheme, which reduces the size of realms in a
message. The compression scheme is a simple dynamically updated
dictionary based algorithm, which is designed to compress arbitrary
length text strings. In this scheme, an entire realm, a single label
or a list of labels may be replaced with an index to a previous
occurance of the same string stored in the dictionary. The realm
compression defined in this specification was inspired by the RFC
1035 [RFC1035] DNS domain name label compression. Our algorithm is,
however, improved to gain more compression.
When compressing realms, the dictionary is first resetted and does
not contain a single string. The realms are processed one by one so
the algorithm does not expect to see them all or the whole message at
once. The state of the compressor is the current content of the
dictionary. The realms are compressed label by label or as a list of
labels. The dictionary can hold maximum 128 strings. Thus, when
adding the 129th string into the dictionary, the dictionary MUST
first be resetted to the initial state (i.e. emptied) and the index
of the string will become 0.
Makela & Korhonen Expires May 4, 2009 [Page 19]
Internet-Draft HAaRO Oct 2008
The encoding of an index to the dictionary or an uncompressed run of
octets representing a single label has purposely been made simple and
the whole encoding works on an octet granularity. The encoding of an
uncompressed label takes the form of a one octet:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
|0| LENGTH | 'length' octets long string.. |
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
This encoding allows label lengths from 1 to 127 octets. A label
length of zero (0) is not allowed. The "label length" tag octet is
then followed by up to 127 octets of the actual encoded label string.
The index to the dictionary (the "label index" tag octet) takes the
form of a one octet:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| INDEX |
+-+-+-+-+-+-+-+-+
The above encodings do not allow generating an output octet value of
zero (0). The encapsulating Mobile IPv4 extension makes use of this
property and uses the value of zero (0) to mark the end of compressed
realm or to indicate an empty realm. It is also possible to encode
the complete realm using only "label length" tags. In this case no
compression takes place. This allows the sender to skip compression,
for example to reduce computation requirements when generating
messages. However, the receiver MUST always be prepared to receive
compressed realms.
4.2.2. Searching algorithm
When compressing the input realm, the dictionary is searched for a
matching string. If no match could be found, the last label is
removed from the right-hand side of the used input realm. The search
is repeated until the whole input realm has been processed. If no
match was found at all, then the first label of the original input
realm is encoded using the "label length" tag and the label is
inserted into the dictionary. The previously described search is
repeated with the remaining part of the input realm, if any. If
nothing remains, the realm encoding is complete
When a matching string is found in the dictionary the matching part
of the input realm is encoded using the "label index" tag. The
Makela & Korhonen Expires May 4, 2009 [Page 20]
Internet-Draft HAaRO Oct 2008
matching part of the input realm is removed and the search is
repeated with the remaining part of the input realm, if any. If
nothing remains, the octet value of zero (0) is inserted to mark the
end of encoded realm.
The search algorithm also maintains the "longest non-matching string"
for each input realm. Each time the search in dictionary fails and a
new label gets encoded using the "label length" tag and inserted into
the dictionary, the "longest non-matching string" is concatenated by
this label. When a match is found in the dictionary the "longest
non-matching string" is resetted (i.e. emptied). Once the whole
input realm has been processed and encoded, all possible suffixes
longer than one label are taken from the string and inserted into the
dictionary.
4.2.3. Encoding example
This section shows an example how to encode a set of realms using the
specified realm compression algorithm. For example, a message might
need to compress the realms "foo.example.com", "bar.foo.example.com",
"buz.foo.example.org", "example.com" and "bar.example.com.org". The
following example shows the processing of input realms on the left
side and the contents of the dictionary on the right hand side. The
example uses hexadecimal representation of numbers.
COMPRESSOR: DICTIONARY:
1) Input "foo.example.com"
Search("foo.example.com")
Search("foo.example")
Search("foo")
Encode(0x03,'f','o','o') 0x00 "foo"
+-> "longest non-matching string" = "foo"
Search("example.com")
Search("example")
Encode(0x07,'e','x','a','m','p','l','e') 0x01 "example"
+-> "longest non-matching string" = "foo.example"
Search("com")
Encode(0x03,'c','o','m') 0x02 "com"
+-> "longest non-matching string" = "foo.example.com"
0x03 "foo.example.com"
0x04 "example.com"
Encode(0x00)
2) Input "bar.foo.example.com"
Search("bar.foo.example.com")
Search("bar.foo.example")
Search("bar.foo"
Search("bar")
Encode(0x03,'b','a','r') 0x05 "bar"
Makela & Korhonen Expires May 4, 2009 [Page 21]
Internet-Draft HAaRO Oct 2008
+-> "longest non-matching string" = "bar"
Search("foo.example.com") -> match to 0x03
Encode(0x83)
+-> "longest non-matching string" = NUL
Encode(0x00)
3) Input "buz.foo.example.org"
Search("buz.foo.example.org")
Search("buz.foo.example")
Search("buz.foo")
Search("buz")
Encode(0x03,'b','u','z') 0x06 "buz"
+-> "longest non-matching string" = "buz"
Search("foo.example.org")
Search("foo.example")
Search("foo") -> match to 0x00
Encode(0x80)
+-> "longest non-matching string" = NUL
Search("example.org")
Search("example") -> match to 0x01
Encode(0x81)
+-> "longest non-matching string" = NUL
Search("org")
Encode(0x03,'o','r','g') 0x07 "org"
+-> "longest non-matching string" = "org"
Encode(0x00)
4) Input "example.com"
Search("example.com") -> match to 0x04
Encode(0x84)
Encode(0x00)
5) Input "bar.example.com.org"
Search("bar.example.com.org")
Search("bar.example.com")
Search("bar.example")
Search("bar") -> match to 0x05
Encode(0x85)
Search("example.com.org")
Search("example.com") -> match to 0x04
Encode(0x84)
Search("org") -> match to 0x07
Encode(0x87)
Encode(0x00)
As can be seen from the example, due the greedy approach of encoding
matches, the search algorithm and the dictionary update function is
not the most optimal one. However, we do not claim the algorithm
would be the most efficient. It functions efficiently enough for
most inputs. In this example, the original input realm data was 79
octets and the compressed output excluding the end mark is 35 octets.
Makela & Korhonen Expires May 4, 2009 [Page 22]
Internet-Draft HAaRO Oct 2008
5. New Mobile IPv4 messages and extensions
This section describes the construction of all new information
elements.
5.1. Route optimization prefix advertisement
This non-skippable extension MAY be sent by a Home Agent to a Mobile
Router in the registration reply message. The extension is only
included when explicitly requested by the Mobile Router in the
registration request message. Implicit prioritization of prefixes is
caused by the order of extensions.
Route optimization prefix advertisement extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1-n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|D|M| Plen | Optional Mobile Router HoA, 4 octets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Optional Prefix, 1,2,3 or 4 octets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Realm (1-n characters) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA, Non-skippable (since it's explicitly requested)
D Delta. If D=1, the prefix is a delta from last Prefix
where D=0. MUST be zero on first information structure,
MAY be zero or one on subsequent information structures.
If D=1, the Prefix field is one octet in length. See
Section 4.1 for details.
O Outbound connections only. This bit indicates that the
target Mobile Router can only initiate, not receive,
connections from it's CoA for this prefix. This is set if
Home Agent has determined that the Mobile Router is behind
NAT, or the Mobile Router has explicitly requested it using
the UDP Tunnel Request extension defined in RFC 3519
[RFC3519] with the Force flag set.
M Mobile Router HoA bit. If M=1, the next field is Mobile
Router HoA, and Prefix is omitted. If M=0, the next field
is Prefix, and Mobile Router HoA is omitted. For the first
information structure, M MUST be set to 1. If M=1, the D
Makela & Korhonen Expires May 4, 2009 [Page 23]
Internet-Draft HAaRO Oct 2008
and O bits are set to zero and ignored upon reception.
PLen Length of the prefix advertised. 5 bits, allows for values
from 0 to 31. If M=1, MUST be set to zero and ignored upon
reception.
Mobile router HoA Mobile Router's Home address. All prefixes in the
following information structures where M=0 are maintained
by this Mobile Router.
Prefix The IPv4 prefix advertised. If D=0, the field length is
Plen bits, rounded up to nearest full octet. Least-
significant bits starting off Plen (and are zeroes) are
omitted. If D=1, field length is one octet.
Realm The Realm that is associated with the advertised Mobile
Router CoA and prefix. If empty, MUST be set to '\0'. For
realm encoding and optional compression scheme, refer to
Section 4.2.
5.2. Mobile router Route optimization capability
This skippable extension MAY be sent by a Mobile Router to a Home
Agent in the registration request message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type |A|R|S| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional Mobile Router HoA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA. Skippable; If Home Agent does not support route
optimization advertisements, it can ignore this request and
simply not include any information in the reply.
A Advertise my networks. If 'A' bit is set, the Home Agent
is allowed to advertise the networks managed by this Mobile
Router to other Mobile Routers.This also indicates that the
Mobile Router is capable of receiving route optimization
binding updates. In effect, this allows the Mobile Router
to work in Correspondent Router role.
R Request mobile network information. If 'R' bit is set, the
Home Agent MAY respond with information about mobile
networks in the same domain.
Makela & Korhonen Expires May 4, 2009 [Page 24]
Internet-Draft HAaRO Oct 2008
S Solicitating prefixes managed by specific Mobile Router.
The Mobile Router is specified in the Optional Mobile
Router HoA field.
Reserved Set to zero, MUST be ignored on reception.
Optional Mobile Router HoA Other Mobile Router's Home Address.
5.3. Home-Test Init message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA.
Reserved Set to zero, MUST be ignored on reception.
Home Init Cookie 64-bit field which contains a random value, the
Home Init Cookie.
5.4. Care-of-Test Init message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA
Reserved Set to zero, MUST be ignored on reception.
Care-of Init Cookie 64-bit field which contains a random value, the
Care-of Init Cookie.
Makela & Korhonen Expires May 4, 2009 [Page 25]
Internet-Draft HAaRO Oct 2008
5.5. Home Test message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA
Home Nonce Index This field will be echoed back by the Mobile Router
to the Correspondent Router in a subsequent registration
request.
Home Init Cookie 64-bit field which contains a random value, the
Home Init Cookie.
Home Keygen Token This field contains the 64 bit home keygen token
used in the Return Routability procedure. Generated from
cookie + nonce.
5.6. Care-of test message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Makela & Korhonen Expires May 4, 2009 [Page 26]
Internet-Draft HAaRO Oct 2008
Type TBA
Care-of Nonce Index This field will be echoed back by the Mobile
Router to the Correspondent Router in a subsequent
registration request.
Care-of Init Cookie 64-bit field which contains a random value, the
Home Init Cookie.
Care-of Keygen Token This field contains the 64 bit home keygen
token used in the Return Routability procedure.
5.7. Mobile-Correspondent authentication extension
Nonce indices extension is used in registration requests sent from
Mobile Router to Correspondent Router
Mobile-Correspondent authentication extension is included in
registration requests sent from Mobile Router to Correspondent
Router. It may also be used with Foreign Agents. The format is
similar to the other Authentication Extensions defined in [RFC3344],
with SPI's replaced by Nonce Indexes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index | Authenticator...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Home Nonce Index field tells the Correspondent Router which nonce
value to use when producing the home keygen token. The Care-of Nonce
Index field is ignored in requests to remove a binding. Otherwise,
it tells the Correspondent Router which nonce value to use when
producing the Care-of Keygen Token.
Type TBA
Home Nonce Index Home Nonce Index in use.
Care-of Nonce Index Care-of Index in use.
Authenticator Authenticator field, constructed by issuing HMAC_SHA1
(KRm, Protected Data)
The protected data, just like on other cases where Authenticator is
used, consists of
Makela & Korhonen Expires May 4, 2009 [Page 27]
Internet-Draft HAaRO Oct 2008
o the UDP payload (i.e., the Registration Request or Registration
Reply data),
o all prior Extensions in their entirety, and
o the Type, Length, and Nonce Indexes of this Extension.
5.8. Care-of address Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Care-of Address extension is added to a registration reply sent
by the Correspondent Router to inform the Mobile Router of the
upcoming tunnel endpoint.
6. Special Considerations
6.1. NATs and stateful firewalls
Mechanisms described in MIP NAT traversal [RFC3519] allow the Home
Agent to be aware of mobile networks managed by a Mobile Router
behind NAT. This information is passed on to the other Mobile
Routers with the 'O' flag. In the case of one of the routers behing
behind NAT or similarly impaired, the tunnel establishment procedure
takes this into account.
If Mobile Router and Correspondent Router are behind same NAT from
HA's point of view, it is possible to establish tunnel between them.
This may also be the situation in the case of nested NATs. This
calls for development of some sort of "Route optimization discovery"
protocol (see Section 6.5) , or more information in the Route
Optimization capability advertisements.
If both the Mobile Router and the Correspondent Router are behind two
separate NATs, some sort of proxy or hole-punching technique may be
needed. This is out of scope of this draft.
6.2. Foreign Agents
Foreign Agents have to specifically support route optimization, ie.
Return Routability procedure and establishment and maintenance of
Makela & Korhonen Expires May 4, 2009 [Page 28]
Internet-Draft HAaRO Oct 2008
tunnel interfaces. Optionally, Mobile Router and Foreign Agent can
have a trust relationship to ensure that security is not affected.
In RFC 3344 [RFC3344], there are separate type codes for
Authenticator extensions depending on the message being sent between
Mobile Node and Home Agent, Mobile Node and Foreign Agent, or Foreign
Agent and Home Agent. In this draft, all possible combinations
(Mobile-Correspondent, Mobile-Foreign, Foreign-Correspondent) use
same authenticator extension type code.
6.3. Multiple Home Agents
In fact, Mobile Routers can negotiate and perform route optimization
without the assistance of Home Agent - if they can discover each
others existence. This draft only addresses a single Home Agent that
distributes network prefix information to the Mobile Routers.
Problems arise from possible trust relationships; In this draft the
Home Agent serves as a way to provide verification that a specific
network is managed by a specific router. For host-routes (route
optimization between single nodes), the requirements may not be so
strict.
Several possibilities exist for achieving Route Optimization between
Mobile Routers attached to separate Home Agents, such as a discovery/
probing protocol, routing protocol between Home Agents or DNS SRV
records, or a common AAA architecture. There already is a framework
for HA to retrieve information from AAA so it can be considered as
the most viable possibility. See Section 6.5 for information on
possibility to generalize the method.
Any discovery/probing protocols are out of scope for this draft.
6.4. Mutualness of Route Optimization
The procedure as specified is asymmetric; That is, if bidirectional
route optimization is desired while maintaining consistency, the
route optimization (RR check and registration) has to be performed in
both directions, but this is not strictly necessary. This is
primarily a policy decision depending on how often the mobile
prefixes are reconfigured.
Consider the case where two networks, A and B, are handled by Mobile
Routers A and B respectively. If the route optimization is triggered
by receiving packet from a network in Route Optimization Cache, the
following occurs if a node in network A starts pinging a node in
network B.
MR B sees the incoming message. It sees that the destination is in
Makela & Korhonen Expires May 4, 2009 [Page 29]
Internet-Draft HAaRO Oct 2008
network B, and furthermore, source is in network A.
MR B completes RR procedure and registration with MR A, which is now
acting as Correspondent Router. A tunnel is created between the
routers. MR A updates its routing table so that network B is
reachable via MR A <-> MR B tunnel.
The traffic pattern is now that packets from network B to network A
are sent over the direct tunnel, but the packets from A to B are
transmitted via the Home Agent and reverse tunnels. MR A now
performs its own route optimization towards MR B. Upon completion, MR
A notices that a tunnel to MR B already exists, but updates its
routing table so that network B is now reachable via the MR A <-> MR
B tunnel. From this point onward, traffic is bidirectional.
In this scenario, if MR A does NOT perform a separate route
optimization (RR check and registration), but instead simply updates
its routing table to reach network B via the tunnel, problems may
arise if MR B has started to manage another network B' before the
information has propagated to MR A. The end result is that MR B
starts to receive packets for network B' via the Home Agent and for
network B via direct tunnel. If RPF checking or similar mechanism is
in use on MR B, packets from network A could be blackholed.
6.5. Extensibility
The design considerations include several mechanisms which might not
be strictly necessary if Route Optimization would only be desired
between individual customer sites in a managed network. The
registration procedure (with the optional Return Routability part),
which allows for Correspondent Routers to learn Mobile Router's
Care-of Addresses is not strictly necessary; The CoA's could have
been provided by HA directly.
However, this approach allows the method to be extended to a more
generic route optimization. The primary driver for having Home Agent
to work as a centralized information distributer is to provide Mobile
Routers with the knowledge of not only the other routers, but to
provide information on which networks are managed by which routers.
The Home Agent provides the information on all feasible nodes with
which it is possible to establish Route Optimization. If
representing a whole Mobile Network is not necessary, in effect the
typical Mobile Node <-> Correspondent Node situation, the mechanisms
in this draft work just as well - only problem is discovering if the
target Correspondent Node can provide Route Optimization capability.
This can be performed by not including any prefixes in the
information extension, just the HoA address of Mobile Router.
Makela & Korhonen Expires May 4, 2009 [Page 30]
Internet-Draft HAaRO Oct 2008
Correspondent node/router discovery protocols (whether they are based
on probing or a centralized directory beyond the single Home Agent)
are outside the scope of this draft.
7. Scalability
Home Agent assisted Route Optimization scalability issues stem from
the general Mobile IPv4 architecture which is based on tunnels.
Creating, maintaining and destroying tunnel interfaces can cause load
on the Mobile Routers. However, the MRs can always fall back to
normal, reverse tunnelled routing if resource constraints are
apparent.
If there is a large number of optimization-capable prefixes,
maintaining state for all of these may be an issue also, due to
limits on routing table sizes.
Registration responses from Home Agent to Mobile Router may provide
information on large number of network prefixes. If thousands of
networks are involved, the registration reply messages are bound to
grow very large. The prefix- and realm compression mechanisms
defined in Section 4 mitigates this problem to an extent. There
will, however, be some practical upper limit after which point some
other delivery mechanism for the prefix information will be needed.
8. Example signaling scenarios
8.1. Registration request
The following example signaling assumes that there are three Mobile
Routers, MR A, B, C, each managing network prefixes A, B, and C. At
the beginning, no networks are registered to the Home Agent. Any AAA
processing at the Home Agent is omitted from the diagram.
Makela & Korhonen Expires May 4, 2009 [Page 31]
Internet-Draft HAaRO Oct 2008
+--------+ +--------+ +--------+ +--------------+
| [MR A] | | [MR B] | | [MR C] | | [Home Agent] |
+--------+ +--------+ +--------+ +--------------+
| | | |
x------------------------------->| Registration request,
| | | | includes Mobile Router
| | | | route optimization
| | | | capability extension
| | | |
|<-------------------------------x Registration response,
| | | | no known networks from HA
| | | | in response
| | | |
| x-------------------->| Registration request, similar
| | | | to the one sent by MR A
| | | |
| |<--------------------x Registration reply, includes
| | | | network A in route optimization
| | | | prefix advertisement extension
| | | |
| | x--------->| Registration request, similar
| | | | the one sent by MR A
| | | |
| | |<---------x Registration reply, includes
| | | | networks A and B in route
| | | | optimization prefix
| | | | advertisement extension.
| | | | Network B is sent in
| | | | compressed form.
| | | |
8.2. Route optimization with return routability
The following example signaling has same network setup as in
Section 8.1 - Three mobile routers, each corresponding to their
respective network. Node A is in network A and Node C is in network
C.
At the beginning, no mobile routers know KRm's of each other. If the
KRm's would be pre-shared or provisioned with some other method, the
Return Routability messages can be omitted. Signaling in Section 8.1
has occured, thus MR A is not aware of the other networks, and MR C
is aware of networks A and B.
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
Makela & Korhonen Expires May 4, 2009 [Page 32]
Internet-Draft HAaRO Oct 2008
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
|<-----------O==========O=========O-------x Mobile Router A is
| | | | | unaware of network C,
| | | | | thus, nothing happens
| | | | |
x------------O==========O=========O------>| Mobile Router C
| | | | | notices packet from
| | | | | Net A - inits RO
| | | | |
| | | | | Return Routability
| | | | | (If no preshared KRms)
| | | | |
| |<=========O---------x | CoTI
| |<=========O=========x | HoTI
| | | | |
| x==========O-------->| | CoT
| x==========O========>| | HoT
| | | | |
| | | | | KRm between MR A <-> C
| | | | | established
| | | | |
| |<=========O---------x | Registration request
| | | | |
| x--------->| | | Registration request
| | | | | to HA due to MR A
| | | | | being unaware of
| | | | | network C.
| | | | | Solicit bit set.
| | | | |
| |<---------x | | Registration reply,
| | | | | contains info on Net A
| | | | |
| x==========O-------->| | Registration reply,
| | | | | includes MR A's CoA in
| | | | | Care-of-Address
| | | | | extension
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Packet from Node C -> A
| | | | | routed to direct tunnel
| | | | | at MR C, based on
| | | | | MR C now knowing MR A's
| | | | | CoA and tunnel being up
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Packet from Node A -> C
| | | | | routed to direct tunnel
Makela & Korhonen Expires May 4, 2009 [Page 33]
Internet-Draft HAaRO Oct 2008
| | | | | at MR A, based on MR A
| | | | | now knowing MR C's CoA
| | | | | and tunnel being up
8.3. Handovers
In these example signalings, MR C changes care-of-address while Route
Optimization between MR A is operating and data is being transferred.
Both cases where the handover is graceful ("make before break") and
ungraceful ("break before make") occur in similar fashion, except in
the graceful version no packets get lost.
Makela & Korhonen Expires May 4, 2009 [Page 34]
Internet-Draft HAaRO Oct 2008
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Nodes A and C
|<-----------O=-=-=-==-=-=-=-==-=-O-------x exchanging traffic
| | | | |
| | xxxxxxxxxxx | Break occurs: MR C
| | | | | loses connectivity to
| | | | | current attachment point
| | | | |
x------------O=-=-=-==-=-=-=-> | | Traffic from A -> C
| | | | | lost and
| | | x<=-=-O-------x vice versa
| | | | |
| | |<--------x | MR C finds a new
| | | | | point of attachment,
| | | | | registers to HA, clears
| | | | | routing tables
| | | | |
| | x-------->| | Registration reply
| | | | |
x------------O=-=-=-==-=-=-=-> | | Traffic from A -> C
| | | | | lost
|<-----------O==========O=========O-------| Traffic from C -> A
| | | | | sent via HA
| | | | |
| |<=========O---------x | Registration request,
| | | | | reusing still active KRm
| | | | |
| x==========O-------->| | Registration reply
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Traffic from A -> C
| | | | | forwarded again
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Traffic from C -> A
| | | | | switches back to direct
| | | | | tunnel
| | | | |
9. IANA Considerations
New Mobile IP header extension and message type values are needed for
the messages and extensions listed in Section 5.
Makela & Korhonen Expires May 4, 2009 [Page 35]
Internet-Draft HAaRO Oct 2008
Note to RFC Editor: this section may be removed on publication as an
RFC.
10. Security Considerations
The Return Routability check has been established in the IPv6 world.
10.1. Trust relationships
The network of trust relationships in Home Agent assisted Route
Optimization solve the issues where arbitrary Correspondent Router
can trust an arbitrary Mobile Router that it is indeed the proper
route to reach an arbitrary mobile network.
It is assumed that all Mobile Routers have a trust relationship with
the Home Agent. Thus, they trust information provided by Home Agent.
The Home Agent provides information matching Home Addresses and
network prefixes. Each Mobile Router trusts this information.
Mobile Routers may perform Return Routability procedure between each
other. This creates a trusted association between Mobile Router Home
Address and Care-of Address. The Mobile Router also claims to
represent a specific network. This information is not trustworthy as
such.
The claim can be verified by checking the Home Address <-> network
prefix information received, either earlier, or due to on-demand
request, from the Home Agent. If they match, the Mobile Router's
claim is authentic. If the network is considered trusted, a policy
decision can be made to skip this check. Exact definitions on
situations where such decision can be made are out of scope of this
draft. The RECOMMENDED general practice is to perform the check.
11. Acknowledgements
Thanks to Jyrki Soini and Kari Laihonen for initial reviews.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Makela & Korhonen Expires May 4, 2009 [Page 36]
Internet-Draft HAaRO Oct 2008
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
"Network Mobility (NEMO) Extensions for Mobile IPv4",
RFC 5177, April 2008.
12.2. Informative References
[I-D.ietf-mobileip-optim]
Perkins, C. and D. Johnson, "Route Optimization in Mobile
IP", September 2001.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Authors' Addresses
Antti Makela
TeliaSonera Corporation.
P.O.Box 777
FIN-33101 Tampere
FINLAND
Phone: +358 40 824 4170
Email: antti.makela@teliasonera.com
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
Makela & Korhonen Expires May 4, 2009 [Page 37]
Internet-Draft HAaRO Oct 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Makela & Korhonen Expires May 4, 2009 [Page 38]
