Internet DRAFT - draft-wood-netlmm-emp-base
draft-wood-netlmm-emp-base
J. Wood
Internet Draft DoCoMo USA Labs
K. Nishida
NTT DoCoMo Inc.
Expires: April 2006 October 17, 2005
Edge Mobility Protocol (EMP)
draft-wood-netlmm-emp-base-00.txt
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.
This document may only be posted in an Internet-Draft.
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 April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Wood, et. al. Expires April 17, 2006 [Page 1]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
Abstract
This document specifies a protocol for localized mobility management
which allows the mobile node to keep using the same IP address while
it is in the same localized mobility management domain. The protocol
enables the edge mobility anchor point to manage the routing path for
the mobile node in the domain, so that the packet form the
correspondent node can be delivered to the access router of MN
currently connecting. For routing path management, the protocol also
specifies the functionality of the access router to provide the MN's
IP address, MN identifier to edge mobility anchor point. The protocol
does not require the mobile node to involve in the mobility
management if link layer technology can provide MN related
information necessary for this protocol.
Conventions used in this document
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.
Table of Contents
1. Acronyms and Conventions.......................................3
2. Protocol Overview..............................................3
3. Protocol Specification.........................................7
3.1. Message Formats...........................................9
3.1.1. Message Header.......................................9
3.1.2. IPv6 Address Option.................................10
3.1.3. MN ID Option........................................10
3.2. Message Codes............................................11
3.3. Message Types............................................12
3.3.1. HELLO...............................................12
3.3.2. Query...............................................13
3.3.3. Update..............................................13
3.3.4. Reply...............................................14
3.4. AAR Specification........................................14
3.5. EMAP Specification.......................................16
3.6. Host Specification.......................................17
APPENDIX A: 802.11 EMP Binding...................................18
A.1. Power-On.................................................20
A.2. Inter-EMD Handover.......................................21
A.3. MN Power-Off, Crash, or Departure from Coverage Area.....22
4. References....................................................23
4.1. Informative References...................................23
Author's Addresses...............................................24
Wood, et. al. Expires April 17, 2006 [Page 2]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
Intellectual Property Statement..................................24
Disclaimer of Validity...........................................25
Copyright Statement..............................................25
1. Acronyms and Conventions
EMD: Edge Mobility Domain
EMAP: Edge Mobility Anchor Point
AAR: Advanced Access Router
CoA: Care of Address
MN: Mobile Node, also known as a Host.
MNID: Mobile Node Identifier
CN: Correspondent Node
SCTP: Stream Control Transmission Protocol (RFC 2960)
RS: Router Solicitation (RFC 2461)
RA: Router Advertisement (RFC 2461)
NS: Neighbor Solicitation (RFC 2461)
NA: Neighbor Advertisement (RFC2461)
DAD: Duplicate Address Detection
oDAD: Optimistic Duplicate Address Detection
TLV: Type-Length-Value
Sometimes messages and their contents will be abbreviated in this
document, as follows:
MSG[CODE](TLVs)
MSG refers to the message type, [CODE] is the code set in the message
header, and (TLVs) are the TLVs following the message header. For
example,
UPDATE[DUP](MNID,ADDR)
represents an UPDATE message with the code set to DUP, and containing
1 MN ID and 1 ADDR TLV.
If the code is 0, [CODE] may be omitted.
2. Protocol Overview
This section contains a high-level overview of how EMP works. A
detailed specification is given in subsequent sections.
In an EMD, AARs and an EMAP collaborate to allow a MN to move within
the EMD without acquiring new CoAs. An EMD's globally routed prefixes
are owned by the EMAP, so to a CN, it appears that the EMAP is the
Wood, et. al. Expires April 17, 2006 [Page 3]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
last hop router for a MN. The EMAP maintains this illusion by
forwarding a MN's traffic through a tunnel to the correct AAR. All
AARs in an EMD advertise the EMAP's set of prefixes, so when a MN
moves to a new AAR, it does not need to configure a new CoA
(following RFCs 2461 and 2462). The EMAP handles the move by
switching the MN's traffic to the tunnel to the new AAR.
The EMP protocol specified in the document allows AARs and an EMAP in
an EMD to communicate routing information about MNs' network
location. For further information and context about EMP, see [1] and
[2].
This document focuses on signaling between AAR and EMAP. Interactions
between the MN and AAR depend on the actual link layer used, and so
are not specified in this document. For this reason, some elements of
the EMP protocol (such as specific triggers for some signaling) are
left vague
Some link layers may provide capabilities that others do not. These
capabilities will shape the interactions between the MN and AAR. A
specific set of interactions between MN and AAR is called an EMP
binding in this document. An appendix details an EMP binding for the
802.11 link technology; reading this may provide some clarification.
EMP uses a MN identifier, referred to as a MNID in this document, to
manage tunnel information or forwarding entries at the EMAP or AAR.
The MNID must be unique and unchanging in the EMD, and is used to
associate the MN with its related information. Some examples of MNIDs
are a Network Access Identifier, a Mobile IP Home Address, and a link
dependent identifier. In the case of the 802.11 binding, the ID will
be simply the 802.11 MAC address. The AAR must be able to set the
MNID in all EMP messages it sends. If the link-layer technology is
unable to provide such functionality, the AAR must keep some state on
the MNID.
It should be noted that although MNID must be contained all EMP
signalings, how the EMAP and AAR's actually utilize a MNID to
organize state for a MN is implementation dependant.
EMP uses SCTP as its transport protocol. The EMAP binds to and
listens on a well-known port (TBD) for incoming AAR connections.
An EMAP must maintain all the state required to keep the routing up
to date for each MN in the EMD. Each message an EMAP sends to an AAR
contains all the information an AAR needs to execute the required
operation. This lessens the amount of state an AAR must keep.
Wood, et. al. Expires April 17, 2006 [Page 4]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
A MN communicates with an AAR via IPv6 protocols defined in RFCs 2461
and 2462. Either special link-layer support or some modifications
beyond RFCs 2461 and 2462 are needed on the MN for movement
detection; these are specified below, in the "Host Specification"
section.
MNs can have one or more global and link-local addresses. These IP
addresses are insufficient for identifying the complete address set
used by a MN within an EMD. Therefore the EMAP uses the MNID to
manage the address set for the MN. The MNID must not change while a
MN is in an EMD.
When an AAR starts up, it initiates a SCTP association to the EMAP.
EMAP discovery is currently undefined; multicast could be used. It
then exchanges initialization information (such as tunnel method
negotiation, EMAP prefixes, authentication and authorization tokens,
and possibly other TBD) with the EMAP, and both parties set up tunnel
endpoints.
MN AAR EMAP
| | |
| NS(link-local DAD) | UPDATE(MNID,LL addr) |
|---------------------->|---------------------->|
| |REPLY[OK](MNID,LL addr)|
| |<----------------------|
| RS | QUERY(MNID) |
|---------------------->|---------------------->|
| RA | REPLY[OK](MNID) |
|<----------------------|<----------------------|
| | |
| NS(CoA DAD) | UPDATE(MNID,CoA) |
|---------------------->|---------------------->|
| | REPLY[OK](MNID,CoA) |
| |<----------------------|
| | |
Figure 1: Power-On, 802.11 Binding Example
EMP must handle these basic scenarios:
1. A MN powers-on in the EMD (Figure 1).
2. A MN moves to a new AAR in the same EMD (intra-EMD handover,
Figure 2).
3. A MN crashes, powers-off, leaves the coverage area, or moves to
a different EMD (Figure 3)
It should be noted that EMP works when an inter-EMD handover occurs,
but the global mobility protocol should also work to register the
fact MN changed the connecting EMD on global mobility anchor point.
Wood, et. al. Expires April 17, 2006 [Page 5]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
When an AAR detects that a MN has connected to its link (i.e. by
receipt of a RS), it does not know if scenario 1 or 2 is occurring,
so it queries the EMAP for information about the MN. If scenario 1 is
occurring, the EMAP has no state for the MN, so it replies with a
message empty except for the MNID (Figure 1). Otherwise, the EMAP has
an entry for the MN, and it sends the AAR the MN's IP addresses so
the AAR can update its forwarding state (Figure 2). It also deduces
that the MN has moved to a new AAR in its EMD, so it switches the
MN's traffic to the tunnel to the new AAR, and informs the old AAR so
that it can clean up state.
A MN can configure a new address at any time, however it is most
likely to do so when it enters a new EMD. Once an AAR detects that a
MN has configured a new address (i.e. by receipt of a DAD NS for the
new CoA), it sends a routing update message to the EMAP (Figure 1).
The EMAP ensures that the new address is not duplicate, and answers
with a status message. If the address is rejected by the EMAP, the
AAR sends the MN an NA containing the new address, which will cause
the MN's DAD process to fail. Otherwise, the AAR and EMAP configure
their routing such that traffic to the new address will reach the MN,
if the address is a global address.
MN AAR1 EMAP AAR2
| | | |
| RS | QUERY(MNID) | |
|--------------->|-------------------->| |
| | REPLY[OK] | UPDATE[DEL] |
| RA | (MNID,CoA1,...) | (MNID,CoA1,...) |
|<---------------|<--------------------|--------------------->|
| | | |
Figure 2: Intra-EMD Handover, 802.11 Binding Example
The EMAP tracks both link local and global addresses for all MNs in
its EMD. It tracks link locals only to ensure that they are unique. A
MN that has been optimized for EMP could therefore reconfirm its link
locals only when it enters a new EMD. Link local addresses are only
valid and used within a single AAR's broadcast domain, and packets
with link-local destination addresses are never forwarded within an
EMD.
If the AAR determines that scenario three has happened (by periodic
probing at L2 or L3, for example), it informs the EMAP so that the
EMAP can clean up state (Figure 3). If the link layer cannot provide
this information, the AAR utilizes some other method to detect such
an event (this is handled in the EMP binding for the specific link
layer).
Wood, et. al. Expires April 17, 2006 [Page 6]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
MN AAR EMAP
| | |
| | UPDATE[DEL](MNID) |
| X--(disconnected)----|------------------------>|
| |UPDATE[DEL](MNID,CoA1,...|
| |<------------------------|
| | |
Figure 3: MN Crashes, Powers-Off, or Leaves Coverage Area
Stateless and stateful address configuration both work with the
protocol specified in this document.
EMP does not mandate any topology regarding the placement of the EMAP
and AARs. It is possible, if fact, to co-locate the EMAP with an AAR.
A well-written implementation using the Null tunnel method (described
below) should support this scenario seamlessly.
2.1. EMP and Tunnels
EMP uses tunnels to create a virtual link between the EMAP and an
AAR. These tunnels are one-way, carrying either the MNs' incoming or
outgoing traffic. The tunnel for incoming traffic is mandatory and is
always set up. The EMAP can optionally request that an AAR set up a
reverse tunnel back to the EMAP to carry outgoing traffic. EMP can
use a number of different tunnel methods. In fact, EMP is agnostic
about the tunnel method used, except for the tunnel negotiation
exchange.
An AAR and EMAP negotiate a tunnel method during the initial HELLO
exchange. In its HELLO message, the AAR sends the EMAP a tunnel
method option containing a list of tunnel methods it supports. The
EMAP selects one method from this list and in its HELLO message to
the AAR includes a tunnel method option containing the selected
method, and optionally requests that a reverse tunnel be set up. The
EMAP thus has the final say over which tunnel method is to be used.
The EMAP can choose different tunnel methods for different AARs. If
the EMAP requests a reverse tunnel, the tunnel method for the reverse
tunnel must be the same as for the forward tunnel.
To ensure interoperability, one tunnel method, GRE, is mandatory. All
EMAPs and AARs MUST support this method, and AARs MUST include it as
one of the supported methods in the initial HELLO.
How and when the EMAP and AAR create and manage the negotiated tunnel
is implementation dependent. The EMAP should arrange for packets
destined to the MN to be encapsulated according to the tunnel method
Wood, et. al. Expires April 17, 2006 [Page 7]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
chosen, and forwarded to the MN's current AAR. Likewise, the AAR
should arrange for the arriving packets to be decapsulated and
forwarded on to the MN. The mechanisms for setting up encapsulation,
decapsulation, and forwarding on the EMAP and AAR are also
implementation dependent.
A MN's outgoing traffic can be forwarded by standard IPv6 routing.
Hence, there is no requirement in EMP for an AAR to set up a reverse
tunnel back to the EMAP or some other node for the MN's outgoing
traffic. The EMAP MAY request via the R bit in the HELLO message that
the AAR set up a reverse tunnel back to the EMAP. If the EMAP does
not request a reverse tunnel, the AAR MAY do this (i.e. for traffic
engineering purposes), but if so it must use some mechanism other
than EMP to arrange for the tunnel exit point to be set up.
Currently the following tunnel methods are defined for EMP.
2.1.1. IPv6 / IPv6 [6]
IPv6 packets destined to the MN are encapsulated at the EMAP in an
IPv6 tunnel terminating at the MN's current AAR. This has the
advantage of utilizing the IPv6 routing topology that is likely to be
in place. However, due to the size of IPv6 headers, this method may
impose a larger overhead, relative to other tunnel methods.
2.1.2. GRE [7]
IPv6 packets destined to the MN are encapsulated at the EMAP in a GRE
tunnel.The GRE tunnel terminates at the MN's current AAR.
2.1.3. MPLS [8]
IPv6 packets destined to the MN are assigned to a forwarding
equivalence class (FEC) by the EMAP. The packets then traverse a
label switched path (LSP) mapped to the MN's FEC. The LSP terminates
at the AAR (i.e. the AAR is the LSP egress).
The mechanism used to create LSPs is out of the scope of this
document. Some mechanisms that could be used are static, pre-
configured LSPs, or a label distribution protocol (LDP) such as LDP
[9] or RSVP-TE [10]. When creating a MPLS tunnel for a MN, an EMAP
can use a pre-existing LSP, or it can trigger a LDP to create a new
LSP dynamically. How the EMAP interacts with MPLS infrastructure and
mechanisms is implementation dependent.
Wood, et. al. Expires April 17, 2006 [Page 8]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
Similarly, the actions taken by an AAR to become an LSP egress are
implementation dependent. Typically, the AAR will need only to
participate in an LDP, or be statically configured with an LSP. An
AAR may also route outgoing traffic along another LSP for traffic
engineering purposes.
For some networks, MPLS may have a number of benefits compared to
other tunnel methods. Its forwarding overhead can be lower and it can
utilize simpler routers, and the encapsulating header can be smaller
than that required by other tunnel methods. It also lends itself to
the application of traffic engineering within an EMD, permitting
traffic optimization techniques such as load balancing, routing
around failures, and enhanced QOS. It may also be possible to enhance
a LDP to perform route optimization for traffic between MNs in the
same EMD. However, MPLS tunnels may also entail more complexity than
other tunnel methods, since it may require significantly more effort
to set up and manage the protocols and infrastructure necessary.
2.1.4. Null Method
This is a pseudo tunnel method. When using it, the EMAP and AAR do
not set up any sort of tunnel. It can be used when tunneling is not
necessary (i.e. when the EMAP is co-located with an AAR) or some
other mechanism is in place to deliver the packets to the AAR.
3. Protocol Specification
3.1. Message Formats
An EMP message consists of a header followed by zero or more options.
EMP options follow the same format and alignment requirements as
RFC2461 neighbor discovery options: they are in TLV format, 8 byte
aligned, and the length field contains the length of the option
(including the type, length, and padding) in units of 8 bytes. All
option payloads whose length is not a unit of 8 bytes must be padded
to the correct alignment.
3.1.1. Message Header
All EMP messages start with a common header.
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 | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wood, et. al. Expires April 17, 2006 [Page 9]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Type: See "Message Types", below
Code: 0, except if the type is an UPDATE or UPDATE REPLY, see below
Options: MN ID and / or IPv6 Address Option(s). All options are 8-
byte aligned.
3.1.2. IPv6 Address Option
The IPv6 address option contains some fields for future use.
Currently only the IPv6 field is used.
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 | Code | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0
Length: 3
Code: Future use
Plen: Future use
Address: The IPv6 address
3.1.3. MN ID Option
The MN ID option contains the MN identifier used in the EMD. It is
variable length.
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
Wood, et. al. Expires April 17, 2006 [Page 10]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Binding ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Length | ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1
Length: Variable
Binding ID: Identifies the EMP binding that created this MNID. This
ensures that one EMP binding cannot create MNIDs that collide with
another EMP binding's MNIDs. Network byte order. See [3] for ID
assignments.
ID Length: length of the MN's ID in bytes, network byte order
ID: The MN's ID, represented as a sequence of bytes
3.1.4. Tunnel Method Option
The tunnel method option contains one or more supported tunnel
methods. It is variable length.
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 |R| Reserved | Method Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Method 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Method n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2
Length: Variable
Method Count: A count of the number of tunnel methods listed in the
option.
R: If set when sent by the EMAP, requests that the AAR set up a
reverse tunnel.
Tunnel Method: A value encoding of a supported tunnel method. The
following tunnel method types are defined:
Tunnel Method Value
Null 0
IPv6 / IPv6 [6] 1
Wood, et. al. Expires April 17, 2006 [Page 11]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
GRE [7] 2
MPLS [8] 3
3.2. Message Codes
EMP UPDATE and UPDATE REPLY messages can use the following codes:
1. OK
2. DELETE: delete a MN
3. DELADDR: delete an IP address
4. DUP: proposed IP address is duplicate
5. NO_RESOURCES: EMAP is out of resources
6. INVALID_MSG: protocol message is malformed
See below for code usage.
3.3. Message Types
Following are the defined types for the EMP message header.
3.3.1. HELLO
Type: 0
Code: 0, or INVALID MSG
Options: 1 EMP Tunnel Option
HELLO messages are exchanged between an AAR and the EMAP during AAR
startup.
An AAR includes a tunnel option in its HELLO message to the EMAP. The
tunnel option contains the tunnel methods supported by the AAR. At
least one method, the mandatory GRE tunnel method, MUST be in the
method list.
Upon receipt of the HELLO message, the EMAP selects one tunnel method
from the list proposed by the AAR. In its answering HELLO message,
the EMAP includes only the selected method. The AAR MUST use this
tunnel method. The EMAP also optionally sets the R bit to request
reverse tunneling. If the EMAP cannot select a suitable tunnel method
(i.e. if the mandatory method is missing), it sets the code in the
HELLO reply to INVALID MSG and aborts the association set up. If the
EMAP receives any unknown tunnel methods, it should ignore them.
Receipt and successful processing of a HELLO message on an EMAP or
AAR may be used to trigger tunnel creation.
Wood, et. al. Expires April 17, 2006 [Page 12]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
3.3.2. Query
Type: 1
Code: 0
Options: 1 MN ID
When an AAR detects that a MN has joined its link, it sends a QUERY
containing the MNs ID to the EMAP. The EMAP responds with an UPDATE
REPLY containing the MN's ID and all global addresses belonging to
the MN, if any are known.
3.3.3. Update
Type: 2
Code: 0, DELETE, or DELADDR
Options: 1 MN ID; 1 or more global or link local IPv6 Addresses
Either an AAR or the EMAP can send an UPDATE. When sent from an AAR
to the EMAP with the code set to 0, the message contains the MN ID
and a new IP Address for verification, and the AAR expects a reply.
When the EMAP sends an AAR an UPDATE[DELETE], it is informing the AAR
of a MN's movement, and no reply is expected. The MN ID and all of
the MN's IP addresses must be included.
When an AAR sends the EMAP an UPDATE[DELETE], it is informing the
EMAP of the MN's departure. Just the MN ID option is included in the
UPDATE. The EMAP must reply with an UPDATE[DELETE] as above
containing the MN ID and all the MN's global addresses so that the
AAR can clean up state.
When an AAR detects that a MN IP address is no longer active, it
sends the EMAP an UPDATE[DELADDR] containing the MN ID and the IP
address to be deleted. No reply is expected.
Following is a summary of the contents of the message for each of
these scenarios:
AAR sends EMAP new address for verification and update:
UPDATE[0](MNID, ADDR)
AAR tells EMAP to delete MN: UPDATE[DELETE](MNID)
EMAP tells AAR to delete MN: UPDATE[DELETE](MNID, ADDR1, ADDR2,
...)
AAR tells EMAP to delete a MN's IP address: UPDATE[DELADDR](MNID,
ADDR)
Wood, et. al. Expires April 17, 2006 [Page 13]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
3.3.4. Reply
Type: 3
Code: DUP, NO_RESOURCES, INVALID_MSG, or ADMIN_PROHIB
Options: MNID, 1 or more global or link local IPv6 Address
REPLY messages are sent from the EMAP to the AAR in response to an
UPDATE or a QUERY. Each REPLY message always contains a MNID. If the
REPLY is sent in response to an UPDATE, the address is the same
address that was in the UPDATE, and conveys status information to the
AAR. If the REPLY is sent in response to a QUERY, the reply contains
all known IP addresses belonging to the MN.
3.4. AAR Specification
Upon startup an AAR exchanges HELLO messages with the EMAP, and sets
up a tunnel endpoint from the EMAP. The HELLO messages may be
piggybacked on top of the SCTP handshake, if the SCTP stack supports
this functionality. The HELLO message conveys tunnel negotiations.
When sending its HELLO message to the EMAP, the AAR MUST include all
the tunnel methods it supports, including at least the mandatory
method. The AAR sets up a decapsulation endpoint for the type of
tunnel selected by the EMAP. If the EMAP has set the R bit in the
HELLO message, the AAR must also set up an encapsulation endpoint for
a tunnel to the EMPA, and route all MN traffic through this tunnel.
The reverse tunnel method must be the same as the forward tunnel.
The AAR acts as a router per RFC2461, with some modifications for
EMP:
- The AAR is RECOMMENDED to use link layer dependent signaling if
available for movement detection to trigger EMP.
- The AAR is REQUIRED to implement DNA[4] to trigger EMP if no
link layer dependent signaling is available.
- The RA beacon multicast interval should set to very long
intervals or turned off.
- The AAR will advertise only the prefixes assigned to the EMD.
- Each prefix must be advertised as off link.
- Some MNs may nonetheless configure addresses they consider to be
on link (i.e. via stateful configuration), resulting in the
addition of an on-link prefix route. If this happens, hosts may
attempt to resolve addresses formed from the local EMD prefix
with neighbor discovery. However, neighbor discovery will not
succeed if the correspondent node is on a AAR's link within the
local EMD. So to force MNs to route all packets through the AAR,
the AAR must answer all NS queries for non link-local addresses
with its own link address.
Wood, et. al. Expires April 17, 2006 [Page 14]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
When an AAR detects that a MN has joined its link (i.e. via a RS), it
must first obtain the MN's ID. The ID and method of acquisition may
vary for different link types. On 802.11 links, for example, the ID
will be the MN's MAC address, and will be in the RS. The AAR then
sends a QUERY message containing the MN's ID to the EMAP.
The EMAP will send an REPLY with the MN ID and 0 or more CoAs
belonging to the MN. If the reply contains 0 CoAs, the AAR takes no
further action. Otherwise, for each CoA in the reply the AAR adds a
forwarding entry (i.e. a host route in the routing table) for the CoA
pointing to its wireless interface. It may also add a neighbor cache
entry for the CoA, but neighbor cache management is outside the scope
of EMP.
If an AAR determines that a MN has configured a new link-local or
global address (i.e. from a DAD NS), it sends an UPDATE message
containing the MN's ID and the new address in an IPv6 address option
to the EMAP. The EMAP will send an REPLY message with a status code
and containing the MNID and the address in question. If the status
code is OK and the address is of global scope, the AAR adds a
forwarding entry for the address pointing its access network
interface. If the status code is OK and the address is a link-local,
the AAR is not required to take any further action, although the EMP-
binding may need to track link-local addresses (i.e. for neighbor
cache or inactive address management). Otherwise, the AAR must cause
the MN's DAD process to fail. The method the AAR uses is link-layer
specific, but for the 802.11 binding, it will multicast a NA with the
target address set to the proposed address (per RFC2461).
If the EMAP sends an AAR an UPDATE message with the code set to
DELETE and containing a MN's ID and one or more of the MN's IP
addresses, it should remove all forwarding entries for the MN's
addresses and clean up any other state it has for the MN.
The AAR must be able to detect if a MN has crashed, powered-off, or
left the coverage area. If the link layer does not provide this
information to the AAR, it must utilize some other mechanism to
detect this (such as periodically probing the MN with NSs). Note that
this case is different from the case where the MN completes an intra-
EMD handover, since in the latter case the EMAP will send the
previous AAR an UPDATE[DELETE] message. If an AAR sends the EMAP an
UPDATE[DELETE] message and the MN is handing over, the EMAP will lose
the MN's routing state, and no packets will be routed to the MN.
If the AAR detects that the MN has crashed, powered-off, or left the
EMD, it sends an UPDATE to the EMAP with the code set to DELETE and
Wood, et. al. Expires April 17, 2006 [Page 15]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
containing the MN's ID in a MNID option. The EMAP will respond with
an UPDATE[DELETE] containing the MNID and the MN's IP addresses. The
AAR should remove all forwarding entries for the MN's global
addresses and clean up any other state it has for the MN.
If a MN changes IP addresses often, eventually the EMAP's MN binding
entry for the MN will become full with inactive addresses. To
alleviate this problem, AARs should take measures to detect inactive
global IP addresses (by probing addresses with neighbor
solicitations, for example). This becomes especially important when
the number of MN global IP addresses approaches the maximum set by
the EMAP. When an AAR determines that a global IP address is no
longer active, it sends the EMAP an UPDATE[DELADDR] containing the
MN's ID and the inactive address and removes the forwarding entry for
that address. No reply is expected.
If a MN temporarily leaves the EMD, by the time it returns the AAR
may have deleted state for some of the MN's IP addresses or even all
state for the MN. This may pose a problem in some EMP bindings. If
the link-layer is capable enough, the EMP-binding for that link-layer
should resynchronize with the MN (although this outside the scope of
EMP).
3.5. EMAP Specification
The EMAP binds to and listens on a well-known SCTP port (TBD) for new
connections from AARs. If it receives a HELLO message from an AAR, it
must send a HELLO message in response. If it wishes to set up a
reverse tunnel with the AAR, the EMAP MUST set the R bit in the HELLO
message sent to the AAR. The EMAP selects one tunnel method from the
list provided by the AAR, and sets that method in the HELLO message
sent to the AAR. At this time, it may also set up a tunnel endpoint
to the AAR.
If the EMAP receives an UPDATE message containing a MN's ID and an
address in an IPv6 address option, it must send an REPLY message in
response. The response contains the MN's ID and the address. It must
verify that the address is unique in the EMD. If the address is not
unique, the code in the response is set to DUP. If the address passes
all checks and is of global scope, the EMAP adds a forwarding entry
for the address pointing to the tunnel going to the AAR that sent the
UPDATE.
If the EMAP receives an UPDATE message containing a MN's ID and with
the code set to DELETE, the EMAP removes all forwarding entries for
that MN's addresses, cleans up any other state associated with the
Wood, et. al. Expires April 17, 2006 [Page 16]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
MN, and replies with an UPDATE[DELETE] containing the MN's ID and the
MN's IP addresses.
If the EMAP receives a QUERY message containing a MN's ID, it must
send an REPLY message in response. If the EMAP has a binding entry
for the MN, it includes the MN's ID and all the MN's IP addresses in
the response as a sequence of IPv6 address options. Otherwise, the
response contains only the MN's ID. If the EMAP has a binding entry
for the MN, and the QUERY is from a different AAR than the AAR in the
MN's binding entry, the MN has moved to a new AAR. In this case for
each of the MN's global addresses the EMAP removes the forwarding
entry pointing to the old AAR's tunnel and creates a forwarding entry
pointing to the new AAR's tunnel. The EMAP then notifies the old AAR
of the move by sending it an UPDATE message with the code set to
DELETE and containing the MN's ID and all the MN's IP addresses as a
sequence of IPv6 addresses options.
The EMAP should limit the number of IP addresses a MN can configure
to prevent resource-draining attacks. If a MN has configured the
maximum number of allowed addresses and tries to configure a new one,
triggering an UPDATE message, the EMAP replies with an REPLY with the
code set to NO_RESOURCES. AARs are responsible for detecting inactive
global IP addresses and notifying the EMAP when this happens. If the
EMAP receives an UPDATE[DELADDR] with the MN's ID and an address, it
removes the forwarding entry for the address and removes the address
from the MN's binding entry.
3.6. Host Specification
Hosts are RECOMMENDED to use link dependent technology if such
technology provides the AAR with a link address or other unique
identifier for the host to enable EMP Update, or if such technology
provides enough IP-level information for the host:
- To give the AAR's the host's MNID when the host moves to a new
link
- To determine whether or not it has moved to a new AAR and
provides the host with enough information to configure on the
new AAR
Hosts using solution C MUST include a Source Link Layer Address
Option when sending a RS. For this reason, hosts MUST NOT use oDAD
when sending the RS, since then they cannot provide a Source Link
Layer Address Option on the RS to act as a unique identifier for the
mobile node.
Wood, et. al. Expires April 17, 2006 [Page 17]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
If not using solution A, hosts should follow the rules described
below:
- Hosts MUST NOT use beaconed RAs.
An EMP binding may use a RS to trigger the AAR to send QUERY message
and detect whether MN moves as intra-EMP handover or inter-EMD
handover. Therefore, the host should not depend on beaconed RAs for
movement detection.
- Host MUST use DAD to confirm the uniqueness of all link local and
global addresses. This is true regardless of whether stateful or
stateless configuration was used to generate the address.
An EMP binding may use a DAD NS to register an IP address at the EMAP.
To minimize chance of failure in registering the IP address, hosts
should use multiple DAD probes to increase the likelihood that a DAD
NS will not be lost.
4. Security Considerations
Ensuring that the MNID is bound to the correct MN is crucial to the
security of EMP. If an ID can be bound to a non-legitimate MN, a
number of attacks become possible:
- An attacker could trick EMP into believing a victim MN has moved
when it has not, causing denial of service.
- An attacker could associate its own IP address with a victim's
ID, potentially causing the victim's traffic to be routed to the
attacker.
- If an attacker can create arbitrary MNIDs, it could mount a
resource draining attack on the EMAP and AARs by creating a
large number of false MNIDs and registering them with EMP.
All these threats originate with how the EMP binding acquires and
manages MNIDs. Hence it is the responsibility of the EMP binding to
ensure that it is not possible to spoof a MNID.
If the EMP binding uses a MAC address as the MNID (as the example
802.11 binding does in this document's appendix), it must counter a
number of threats to satisfy EMP security requirements:
1. An attacker could falsify its MAC address in the neighbor
discovery process, thereby tricking the EMP binding into
associating the victim's MAC address with the attackers IP
address, or the victim's IP address with the attackers MAC
address.
2. An attacker could send packets with the source IP address of a
victim (i.e. in order to traffic-bomb another node).
Wood, et. al. Expires April 17, 2006 [Page 18]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
Threat 1 can be countered with a combination of appropriate link
security, such as 802.11i, and Secure Neighbor Discovery (SEND) [11].
Link security can prevent an attacker from falsifying its MAC
address. However, even if link security is in place, an attacker
could still include a false MAC address as an option in a ND message
(i.e. a source linkaddr option); this will not be prevented by link
security or SEND. An AR should therefore obtain a MN's MAC address
from the link layer rather than a ND option. SEND will prevent an
attacker from claiming a victim's IP address.
Threat 2 can be countered with a firewall on the AAR that only allows
outgoing traffic with a verified (by SEND) IP-MAC pair.
EMP bindings must take measures to prevent MNs from using source IP
addresses that are not in the EMD unless the EMP binding can ensure
the IP address used by the MN is authorized. This will hinder MNs
from participating in bombing attacks on arbitrary nodes in the
Internet.
The EMAP should limit the number of IP addresses associated with a
single MNID to prevent resource draining attacks.
EMP assumes a secure, trusted association between each AAR and EMAP.
It is recommended that IKE be used to authenticate AARs and EMAPs to
one another, and to set up IPSec SAs to protect subsequent signaling.
Internal IP addresses of individual components in an EMD
infrastructure (i.e. EMAPs, AARs, and other routers) are never
revealed via EMP signaling to any end hosts. This makes it more
difficult to mount attacks on an EMD infrastructure. To ensure that
internal IP addresses do not leak out, measures should be taken to
prevent end hosts from using traceroute mechanisms.
Wood, et. al. Expires April 17, 2006 [Page 19]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
APPENDIX A: 802.11 EMP Binding
This appendix describes the 802.11 EMP binding, which may also be
suitable for other link layers as well.
This section is broken down into a number of scenarios, each with
detailed steps taken by all parties (MN, AAR, and EMAP). Note that
the MN follows RFC2461 exactly, but additionally must perform
movement detection and routing table updates during handover.
A.1. Power-On
1.MN autoconfigures a link-local address
2.MN sends a DAD NS for the link-local per RFC2461.
3.AAR sends EMAP an UPDATE(MNID,link-local addr).
4.EMAP checks the link-local and ensures that it is not duplicate.
4.1.If the address is duplicate, the EMAP responds with
REPLY[DUP](MNID,link-local addr].
4.2.If the address is OK, the EMAP responds with
REPLY[OK](MNID,ADDR).
5.If the address was rejected by the EMAP for any reason, the AAR
multicasts a NA with the target field of the ICMPv6 NA set to the
proposed link-local address.
5.1.Upon receipt of this NA, the MN marks the link-local as
duplicate and does not use it. It then configures a new link-
local address.
6.MN sends a RS on all mobility-enabled interfaces per RFC2461.
7.AAR uses MN MAC address as MN ID, and sends QUERY(MN ID) to EMAP.
8.AAR sends MN RA per RFC2461.
9.EMAP sends AAR REPLY[OK](MNID), containing no addresses since MN
is new to the EMD.
10.MN receives RA and acquires CoAs
10.1.For each prefix with the autonomous flag set, MN
autoconfigures a global address
10.2.If the RA's managed flag is set, the MN obtains an address
Wood, et. al. Expires April 17, 2006 [Page 20]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
from DHCPv6.
11.For each new global address, MN sends a DAD NS per RFC2461.
12.For each received NS, the AAR sends the EMAP an
UPDATE(MNID,ADDR).
13.For each UPDATE, the EMAP checks the address and ensures that is
it not duplicate.
13.1.If the address is duplicate, the EMAP responds with
REPLY[DUP](MNID,ADDR].
13.2.If the address is OK, the EMAP responds with
REPLY[OK](MNID,ADDR).
14.If the address was rejected by the EMAP for any reason, the AAR
multicasts a NA with the target field of the ICMPv6 NA set to the
proposed address.
14.1.Upon receipt of this NA, the MN marks the address as
duplicate and does not use it.
15.If the address was accepted by the EMAP, the AAR adds a host
route for the new address pointing to the interface serving the
MN.
15.1.The MN completes DAD successfully, and proceeded to use the
new address.
15.2.The AAR starts a timer to periodically probe one of the MN's
addresses. See the Power-Off section, below for this timer logic
A.2. Intra-EMD Handover
1.MN detects that it has reassociated and is ready to send IP
packets.
1.1.If no 802.l1 security is in use, this is when the reassociate
exchange completes.
1.2.If 802.11 security is in use, this is when the security
exchange completes.
2.The MN sends a RS.
3.The AAR sends a QUERY(MNID) to the EMAP.
4.The AAR sends a RA to the MN.
4.1.The MN examines the AAR and using movement detection logic
Wood, et. al. Expires April 17, 2006 [Page 21]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
determines that it is now using a different AAR with the same
prefixes. It changes its default route to use the new AAR. Note
that these steps are NOT specified by RFC2461.
5.Since the MN is already known to the EMD, the EMAP has the MN's
global addresses. It sends these to the AAR: REPLY[OK](ADDR1,
ADDR2, ...).
6.The EMAP informs the AAR from which the MN just moved about the
handover by sending it an UPDATE[DELETE](MNID,ADDR1,ADDR2).
6.1.The previous AAR removes all host routes for the MN, and
cleans up any other state is has for the MN.
7.For each address in the REPLY, the AAR adds a host route for the
address pointing to the interface serving the MN.
8.The AAR starts a timer to periodically probe one of the MN's
addresses. See the Power-Off section, below for this timer logic.
A.3. MN Power-Off, Crash, or Departure from Coverage Area
This section is necessary only if an AAR is unable to obtain mobile
station status information from the 802.11 AP. This logic could also
easily be adapted to probe for inactive global IP addresses.
1.The AAR starts a probe timer.
2.When the timer expires, the AAR unicasts a NS to any one of the
MN's global unicast addresses, with the target set to the probed
address.
3.If the MN is still on-link and active, it responds with a NA, per
RFC2461.
4.If the MN is not on-link and active, it does not respond. The AAR
retransmits the NS a number of times. The number of retransmissions
and retransmit interval should be configurable. Recommended values
are 3 retransmits, spaced one second apart.
4.1.After the AAR has sent the maximum number of NS probes, it
considers the MN gone.
4.1.1.It sends an UPDATE[DELETE](MNID) to the EMAP.
4.1.2.The AAR then removes host routes for all the MN's global
addresses, and cleans up any other state it may have for the
MN.
Wood, et. al. Expires April 17, 2006 [Page 22]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
5. References
5.1. Informative References
[1] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Problem Statement for IP Local Mobility",
Internet Draft, work in progress.
[2] Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M.,
Nishida, K., "Requirements and Gap Analysis for Localized
Mobility Management", Internet Draft, work in progress.
[3] Kempf, J., "Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations", Internet Draft, work in progress.
[4] Narayanan, S., Nordmark, E., Pentland, B., "Detecting Network
Attachment in IPv6 Networks (DNAv6)", Internet Draft, work in
progress.
[5] Narayanan, S., Daley, G., Montavont, N., "Detecting Network
Attachment in IPv6 - Best Current Practices for hosts",
Internet Draft, work in progress.
[6] Conta, A., Deering, S., "Generic Packet Tunneling in IPv6
Specification", RFC 2473, September 1998
[7] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P.,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000
[8] Rosen, R., Viswanathan, A., Callon, R., "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001
[9] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas,
B., "LDP Specification", RFC 3036, January 2001
[10] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Swallow, G., "RSVE-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001
[11] Arkko, J., Kempf, J., Zill, B., Nikander, P., "SEcure Neighbor
Discovery (SEND)", RFC 3971, March 2005
Wood, et. al. Expires April 17, 2006 [Page 23]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
Author's Addresses
Jonathan Wood
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Email: jonwood@speakeasy.net
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
Intellectual Property Statement
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.
Wood, et. al. Expires April 17, 2006 [Page 24]
Internet-Draft Edge Mobility Protocol (EMP) October 2005
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Wood, et. al. Expires April 17, 2006 [Page 25]
