Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs
Expires: October 12, 2006 S. Narayanan
Panasonic
April 10, 2006
Network-based Localized Mobility Management Interface between Mobile
Node and Access Router
draft-ietf-netlmm-mn-ar-if-00
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 not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
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 October 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specify an IP layer interface between mobile nodes (MN)
and access routers (AR) of a network-based localized mobility
management (NetLMM) domain. Such an interface is subject to a
Laganier & Narayanan Expires October 12, 2006 [Page 1]
Internet-Draft NetLMM MN-AR Interface April 2006
certain number of threats, amongst which are attacks on the mapping
between the MN Identifier and IPv6 address set. A binding
enforcement mechanism between those two is hence required to prevent
malicious nodes to carry on various attacks like service theft or
denial-of-service attacks. In the absence of link-layer specific
mechanisms enforcing this binding, it is required to implement such
mechanism at the IP layer MN-AR interface. Moreover, it is required
that no NetLMM specific software support is present on MNs. The IP
layer MN-AR interface described in this document fulfills these two
requirements by using the SEND public key as the MN identifier, while
being solely based on standard track IPv6 protocols (DNA and SEND)
implemented by non-NetLMM MNs.
Laganier & Narayanan Expires October 12, 2006 [Page 2]
Internet-Draft NetLMM MN-AR Interface April 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Operating Environment . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
2.1. MN powers on in a NetLMM domain . . . . . . . . . . . . . 9
2.2. First attachment of MN moving into a NetLMM domain . . . . 10
2.3. MN handovers in a NetLMM-domain . . . . . . . . . . . . . 11
2.4. MN configuring additional CGAs . . . . . . . . . . . . . . 13
2.5. MN configuring CGA that is in use by another MN in the
NETLMM domain . . . . . . . . . . . . . . . . . . . . . . 13
2.6. MN unconfigures CGAs, powers off, crash or leave the
domain . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Mobile Node Specification . . . . . . . . . . . . . . . . . . 16
4. Access Router Specification . . . . . . . . . . . . . . . . . 18
4.1. Promiscuous and all-multicast modes . . . . . . . . . . . 18
4.2. Receiving Neighbor Discovery Messages from MN . . . . . . 18
4.2.1. Receiving DAD Neighbor Solicitations . . . . . . . . . 19
4.2.2. Receiving Solicited Neighbor Advertisements . . . . . 19
4.2.3. Receiving All Others Neighbor Discovery Messages . . . 19
4.3. Sending Neighbor Discovery Messages to MN . . . . . . . . 19
4.3.1. Sending Neighbor Solicitations . . . . . . . . . . . . 19
4.3.2. Sending Proxy Neighbor Advertisements . . . . . . . . 20
4.3.3. Sending Router Advertisements . . . . . . . . . . . . 20
4.3.4. Sending Redirects . . . . . . . . . . . . . . . . . . 20
4.4. Receiving All Others IPv6 Packets from MN . . . . . . . . 20
4.4.1. Authenticated Packets . . . . . . . . . . . . . . . . 20
4.4.2. Unauthenticated Packets . . . . . . . . . . . . . . . 21
4.5. Mobile Node Identifier used by AR . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative references . . . . . . . . . . . . . . . . . . . 24
7.2. Informative references . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Laganier & Narayanan Expires October 12, 2006 [Page 3]
Internet-Draft NetLMM MN-AR Interface April 2006
1. Introduction
It is suggested in [I-D.kempf-netlmm-nohost-ps] that it would be
desirable to have a localized mobility management protocol in which
the host is not involved. The requirements for such a protocol have
been analyzed in [I-D.kempf-netlmm-nohost-req]. Accordingly, a
protocol for network-based localized mobility management (NetLMM) of
IPv6 nodes will be specified by the NetLMM working group; until this
occurs, this document assumes [I-D.wood-netlmm-emp-base] as a
strawman NetLMM protocol in use in a NetLMM domain. Further
revisions of this document will be adapted to the NetLMM protocol
proposal chosen by the working group. Because the NetLMM protocol is
network based, the mobile node is not required to implement new
mechanism in its IP stack, nor to change its IP address when it
attaches to a new access router.
Because the IPv6 mobile node will use a vanilla IPv6 stack, the
interface between a mobile node and its access router has to be
preserved. This means that standard IPv6 should work seamlessly with
the network-based localized mobility support. More specifically, we
require the proposed solution to be compatible with the mechanisms
specified in:
o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis]
o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis]
o Privacy Extensions for Stateless Address Autoconfiguration in IPv6
[I-D.ietf-ipv6-privacy-addrs-v2]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Hosts [I-D.ietf-dna-hosts]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Routers [I-D.ietf-dna-routers]
o Detecting Network Attachment with Unmodified Routers: A Prefix
List based approach [I-D.ietf-dna-cpl]
o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna-
protocol]
o SEcure Neighbor Discovery [RFC3971]
o Cryptographically Generated Addresses [RFC3972]
This document specify an IP layer interface between mobile nodes (MN)
and access routers (AR) of a network-based localized mobility
Laganier & Narayanan Expires October 12, 2006 [Page 4]
Internet-Draft NetLMM MN-AR Interface April 2006
management (NetLMM) domain. Such an interface is subject to a
certain number of threats, amongst which are attacks on the mapping
between the MN Identifier and IPv6 address set. A binding
enforcement mechanism between those two is hence required to prevent
malicious nodes to carry on various attacks like service theft or
denial-of-service attacks. In the absence of link-layer specific
mechanisms enforcing this binding, it is required to implement such
mechanism at the IP layer MN-AR interface. Moreover, it is required
that no NetLMM specific software support is present on MNs. The IP
layer MN-AR interface described in this document fulfills these two
requirements by by using the SEND public key as the MN identifier,
while being solely based on standard track IPv6 protocols (DNA and
SEND) implemented by non-NetLMM MNs.
1.1. Terminology
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 [RFC2119].
In addition, new terms are defined below:
Network-based Localized Mobility Management Domain (NETLMM domain) :
An administrative domain spanning geographically contiguous link
layer networks served by access routers.
Mobile Node (MN): The MN is an IPv6 node moving in the domain.
Access Router (AR): The AR is the Mobile Node's default router.
External interface : A network interface of an AR attached to the
link used by MN.
Mobility Anchor Point (MAP): A Mobility Anchor Point is a router
located in the network-based localized mobility domain handling
exchanged between that domain and the Internet.
1.2. Abbreviations
Throughout this document, figures make use of the following
abbreviations:
ND: Neighbor Discovery.
NDP: Neighbor Discovery Protocol.
SEND: SEcure Neighbor Discovery.
Laganier & Narayanan Expires October 12, 2006 [Page 5]
Internet-Draft NetLMM MN-AR Interface April 2006
DNA: Detecting Network Attachment.
LNMP: NetLMM Protocol used in the backhaul of the NetLMM domain
(between ARs and MAP.)
CGA: Cryptographically Generated Address.
CGA_LL: The link-local unicast CGA generated by the MN with its
public key (It is assumed that the MN is using a single public key to
configure all of its link-local unicast and global unicast CGAs.)
CGA_1: One of the Global Unicast CGA generated by the MN with its
public key.
CGA_2: Another one of the Global Unicast CGA generated by the MN with
its public key (e.g. with a different subnet prefix.)
CGA_*: Any Unicast CGA generated by the MN with its public key (i.e.
link-local or global.)
MNID: Mobile node identifier set to the public key used by the MN for
generating its CGAs.
1.3. Operating Environment
The MN-AR NetLMM interface is used between a mobile node and an
access router of a NetLMM domain. In the absence of link-layer
specific mechanism, it allows the AR to detect the network attachment
of a MN and update routing at the MAP so that the MN stays reachable
when it roams across the NetLMM domain.
Laganier & Narayanan Expires October 12, 2006 [Page 6]
Internet-Draft NetLMM MN-AR Interface April 2006
/-----------\
/ Internet \
\ /
\-----+-----/
|
+-------+
| MAP |
+---+---+
|
/------------+------------\
/ NetLMM \
\ domain /
/ \-------------------------/ \
| | |
+--+--+ +--+--+ +--+--+
| AR1 | | AR2 | | AR3 |
+-----+ +-----+ +-----+
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \ MN-AR
- -/- - - -\- - - -/- - - -\- - -/- - - -\- - - - - -
/ \ / \ / \ Interface
/ +-----+ \ / \
/ | MN | -------> X \
/ +-----+ movement / \ \
The deployment scenario is shown in the figure above: Several ARs are
attached to an IP routing domain connected to the outside Internet
via a MAP. The ARs, MAP, and in-between routing fabric constitute
the NetLMM domain. Each AR announce on its external interface a
common set of prefix(es) which are routed to the MAP from the outside
Internet. Packets incoming at the MAP and directed at the MN are
tunneled to the appropriate AR based on the information provided by
ARs.
In the absence of a link-layer specific MN-AR interface, it is
required to have a common interface defined at the IP layer. Because
no NetLMM specific software support is assumed to be present on MNs,
this interface has to rely only on standard tracks IPv6 protocols
such as Neighbor Discovery (ND), SEND (Secure ND) and Detecting
Network Attachment (DNA). Interactions of these three components
with NetLMM are represented below (note that hints received by DNA
from other layers are omitted for clarity):
Laganier & Narayanan Expires October 12, 2006 [Page 7]
Internet-Draft NetLMM MN-AR Interface April 2006
MN|AR
Interface
|
| +------------+ +----------+
| | | |
| | +--------+ | NLMP | +------+ |
| | NetLMM |<-------->|NetLMM| |
| | +--------+ | | +------+ |
| ^ ^ | | ^ |
+----------+ | | | | | | | |
| | | v | | | | |
| +------+ | | | +-----+ | | | | |
| | DNA | | NDP | | DNA | | | | | |
| | SEND |<------|------>|SEND | | | | | |
| | ND | | | | ND | | | | | |
| +------+ | | | +-----+ | | | | |
| ^ | | ^ | | | | |
| | | | | | | | | | |
| v | | v | | | v |
| +------+ | | | +----+ | | | +------+ |
| | | | | | |<-+ | | | | |
| | | | IPv6 | | | | IPv6 | | | |
| | IPv6 |<------|------>|IPv6|<------------>| IPv6 | |
| +------+ | | +----+ | | +------+ |
| | | | | | |
| MN | | AR | | MAP |
+----------+ | +------------+ +----------+
|
Laganier & Narayanan Expires October 12, 2006 [Page 8]
Internet-Draft NetLMM MN-AR Interface April 2006
2. Protocol Overview
The following subsections present the different situations in which
the MN-AR interface is used to trigger the NetLMM protocol.
2.1. MN powers on in a NetLMM domain
+-------------------------------------------------------------------+
|Caption :In following figures it is assumed that the MN and AR |
| clocks are synchronized enough to allow verification of ND|
| messages via SEND timestamps. If that would not be the |
| case, in order to verify freshness of ND signaling sent |
| by the MN, the AR would be required to solicit the MN by |
| sending to it a NS with a fresh nonce, to which the MN |
| would reply with a NA containing the same fresh nonce. |
+-------------------------------------------------------------------+
MN AR1 MAP
| | |
| NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) |
|----------------------->|---------------------->| bind(CGA_LL,MNID)
| |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR1)
| |<----------------------|
| RS | |
|----------------------->| |
| RA | |
|<-----------------------| |
| NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) |
|----------------------->|---------------------->| bind(CGA_1,MNID)
| | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR1)
| |<----------------------|
| | |
| NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) |
|----------------------->|---------------------->| bind(CGA_2,MNID)
| | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR1)
| |<----------------------|
| | |
Figure 1: MN powers on and configures a Link-Local and two Global
Unicast CGAs
When a MN powers on for the first time, it will generate a link local
address based on its public key (CGA_LL) as per [RFC3972], and
perform DAD on the address as per [RFC2462]. The DAD-NS message
generated will contain the public key in the CGA option as defined by
SEND [RFC3971]. Upon reception of this NS message, the access router
(AR1) SHOULD generate a UPDATE to the MAP with the public key as the
Laganier & Narayanan Expires October 12, 2006 [Page 9]
Internet-Draft NetLMM MN-AR Interface April 2006
MNID along with CGA_LL. The MAP SHOULD bind the CGA_LL to the MNID
and establish a route binding for the CGA_LL to the access router
AR1. The MAP acknowledges the receipt of the UPDATE message.
While waiting for the completion of DAD, the MN may generate RS
message as per [RFC2461] with the unspecified address as the source
address. Such an RS message will not contain a CGA option. The
access router will respond with a multicast RA as per [RFC2461].
With the prefix information received in the RA message, the MN will
cryptographically generate one or more global addresses (CGA_*). For
each of these addresses, the MN will perform DAD as the IID is likely
to be different for each of these cryptographically generated
addresses. For every DAD-NS received from the MN,the access router
AR1 will generate a UPDATE message to the MAP establishing binding in
the MAP.
2.2. First attachment of MN moving into a NetLMM domain
MN AR2 MAP
| | |
| RS | |
|---------------------->| |
| RA | |
|<----------------------| |
| NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) |
|---------------------->|---------------------->| bind(CGA_LL,MNID)
| |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2)
| |<----------------------|
| NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) |
|---------------------->|---------------------->| bind(CGA_1,MNID)
| | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR2)
| |<----------------------|
| | |
| NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) |
|---------------------->|---------------------->| bind(CGA_2,MNID)
| | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR2)
| |<----------------------|
| | |
Figure 2: MN moves into a NetLMM domain and configures a Link-Local
and two Global Unicast CGAs
When a MN moves into a NETLMM domain for the first time, it will
initiate link change detection as specified in [I-D.pentland-dna-
protocol] by multicast transmission of a RS message. When the MN
receives a RA message in response, it will figure out that it has
Laganier & Narayanan Expires October 12, 2006 [Page 10]
Internet-Draft NetLMM MN-AR Interface April 2006
changed link as defined by the DNA specification [I-D.pentland-dna-
protocol]. Once the MN realizes it has changed link, it will discard
its current IP addresses and will execute DAD for its link-local
address and new global addresses based on the prefix information in
the received RA messages.
The behavior of the access router AR2 in response to the DAD messages
is similar to that of AR1 specific in Section 2.1.
2.3. MN handovers in a NetLMM-domain
MN AR3 MAP
| | |
|RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR3)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR3)
| RA(AR->CGA_LL) | CGA_1,CGA_2) | route(CGA_2->AR3)
|<-----------------------|<----------------------|
| | |
Figure 3: MN getting handover hint and receives a unicast RA
When the MN moves within the NETLMM domain, it will send a RS message
with the source address as its link-local address as specified by
[I-D.pentland-dna-protocol]. The access router again can use the
public key in CGA option to infer the MNID and send updates to the
MAP. If the access router chooses to respond with a unicast RA, all
required steps are done.
MN AR4 MAP
| | |
|RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR4)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR4)
| RA(AR->All_nodes) | CGA_1,CGA_2) | route(CGA_2->AR4)
|<-----------------------|<----------------------|
| NS | |
|----------------------->| |
| NA | |
|<-----------------------| |
| | |
Figure 4: MN getting handover hint and receives a multicast RA
Laganier & Narayanan Expires October 12, 2006 [Page 11]
Internet-Draft NetLMM MN-AR Interface April 2006
In a similar scenario, if the access router chooses to respond with a
multicast RA, the MN will send a NS to learn about the access router
and confirm reachability.
MN AR5 MAP
| | |
| NS(AR->CGA_*) | |
|<-----------------------| |
| NA(CGA_*->AR) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR5)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR5)
| | CGA_1,CGA_2) | route(CGA_2->AR5)
| |<----------------------|
| | |
Figure 5: AR getting handover hint of MN whose IP address is known
Instead of the MN receiving the hint, in scenarios were the access
router receives the hint with the IP address of the handing over MN,
the AR can send a NS to that IP address. The NA message received in
response will contain the public key of the MN with which the AR can
send update message to the MAP.
MN AR6 MAP
| | |
| RA(AR->All_nodes) | |
|<-----------------------| |
| NS(CGA_*->AR) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR6)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR6)
| NA(AR->CGA_*) | CGA_1,CGA_2) | route(CGA_2->AR6)
|<-----------------------|<----------------------|
| | |
Figure 6: AR getting handover hint of MN whose IP address is unknown
If the access router does not receive the IP address information of
the handing over MN along with the hint, the AR can schedule a
multicast RA. The MN will try to fill its neighbor cache information
with the new router and confirm its reachability by initiating a NS
message to the AR. The AR can then send update message to the MAP
based on the public key in the NS message.
Laganier & Narayanan Expires October 12, 2006 [Page 12]
Internet-Draft NetLMM MN-AR Interface April 2006
2.4. MN configuring additional CGAs
If the MN choose to configure new global addresses at any point in
time, it will contact DAD on the new address by sending a DAD-NS
message. The access router can learn the new address from the NS
message and map to the corresponding public key in the CGA option.
MN AR MAP
| | |
| NS(DAD:CGA_3) | UPDATE(MNID,CGA_3) |
|----------------------->|---------------------->| bind(CGA_3,MNID)
| | REPLY[OK](MNID,CGA_3) | route(CGA_3->AR)
| |<----------------------|
| | |
Figure 7: MN configuring later on additional CGAs
2.5. MN configuring CGA that is in use by another MN in the NETLMM
domain
The access router learns about new global addresses configured by the
MN from the NS-DAD message sent by MN. When the AR sends an UPDATE
to the MAP based on this DAD-NS, it waits for a positive
acknowledgment from the MAP. If the MAP has an entry for the save
CGA with a different MNID, it will respond back with a message
indicating collision and the AR must proxy for the other MN by
responding to the DAD-NS.
MN AR MAP
| | |
| NS(DAD:CGA_3) | UPDATE(MNID,CGA_3) |
|----------------------->|---------------------->| collision(MNID)
| NA(CGA_3->MN) |REPLY[COLLISION](CGA_3)|
|<-----------------------|<----------------------|
| | |
Figure 8: MN configuring later on a colliding CGA
2.6. MN unconfigures CGAs, powers off, crash or leave the domain
It is recommended that the access router do periodic reachability
testing with MN, Neighbor Unreachability Detection (NUD), to learn
about addresses being unconfigured or the MN being powered off or
crashing. The trigger for this test could be neighbor cache entry
timeout or a MLDv2 [RFC3810] unsubscribe for the solicited-node
multicast address matching the MN's CGA. [XXX figure TBD.]
In the Figure 9, the MN stops using the address CGA_1 and when the
Laganier & Narayanan Expires October 12, 2006 [Page 13]
Internet-Draft NetLMM MN-AR Interface April 2006
access router tries NUD for each of these addresses, it doesn't
receive a response for CGA_1, resulting in a UPDATE message to the
MAP to remove the mapping between MNID and CGA_1.
MN AR MAP
| | |
| NS(AR->CGA_LL) | |
|<-----------------------| |
| NA(CGA_LL->AR) | |
|----------------------->| |
| NS(AR->CGA_1) | |
| X <------------------| |
| NS(AR->CGA_2) | |
|<-----------------------| |
| NA(CGA_2->AR) | |
|----------------------->| |
| NS(AR->CGA_3) | |
|<-----------------------| |
| NA(CGA_3->AR) | |
|----------------------->| |
| |UPDATE[DEL](MNID,CGA_1)|
| |---------------------->| del_route(CGA_1)
| | REPLY[OK](MNID) |
| |<----------------------|
| | |
Figure 9: MN unconfigures a CGA
MN AR MAP
| | |
| NS(AR->CGA_LL) | |
| X <------------------| |
| NS(AR->CGA_1) | |
| X <------------------| |
| NS(AR->CGA_2) | |
| X <------------------| |
| NS(AR->CGA_3) | |
| X <------------------| |
| | UPDATE[DEL](MNID) |
| |---------------------->| del_route(CGA_LL)
| | REPLY[OK](MNID) | del_route(CGA_1)
| |<----------------------| del_route(CGA_2)
| | | del_route(CGA_3)
| | | del_bind(MNID)
Laganier & Narayanan Expires October 12, 2006 [Page 14]
Internet-Draft NetLMM MN-AR Interface April 2006
Figure 10: MN crashes, powers off or leaves the domain
As shown in Figure 10, if the MN crashes, powers off or leaves the
domain, the NUD will fail for all the associated addresses. In this
case, the access router can remove the entry for the mobile node from
the MAP by initiating a UPDATE message.
Laganier & Narayanan Expires October 12, 2006 [Page 15]
Internet-Draft NetLMM MN-AR Interface April 2006
3. Mobile Node Specification
There is no few NetLMM specific requirements place on a Mobile Node
in a NetLMM domain. However, for the smooth operation of the NetLMM
MN-AR interface, the MN MUST behave as specified in the following
documents:
o Neighbor Discovery for IP version 6 [RFC2461] (MUST) and
[I-D.ietf-ipv6-2461bis] (SHOULD)
o IPv6 Stateless Address Autoconfiguration [RFC2462] (MUST) and
[I-D.ietf-ipv6-2462bis] (SHOULD)
o Privacy Extensions for Stateless Address Autoconfiguration in IPv6
[I-D.ietf-ipv6-privacy-addrs-v2]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Hosts [I-D.ietf-dna-hosts]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Routers [I-D.ietf-dna-routers]
o Detecting Network Attachment with Unmodified Routers: A Prefix
List based approach [I-D.ietf-dna-cpl]
o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna-
protocol]
o SEcure Neighbor Discovery [RFC3971]
o Cryptographically Generated Addresses [RFC3972]
and MUST use a single public key to generate all of their CGAs. This
requirement is necessary to make it possible for the AR and MAP to
bind together different addresses of the MN. That way, when a MN
attaches to a new AR, the MAP will correctly updating routing for all
MN CGAs even if the MN is currently using only one of those (e.g. its
link-local CGA to send a router solicitation.)
With respect to the MUST support [RFC2461] and [RFC2462], and SHOULD
support [I-D.ietf-ipv6-2461bis] and [I-D.ietf-ipv6-2462bis], the
reason is that the SEND requirements avoid complication with the "DAD
once per IID" optimization of [RFC2462]. Although it might have been
problematic for the AR to detect the configuration of a global
address for which the MN does not perform DAD because the IID of the
global address is the same than the one of a DADed link-local
address, the fact that SEND is used causes IIDs from CGAs with
different subnet prefixes to be different because the subnet prefixes
Laganier & Narayanan Expires October 12, 2006 [Page 16]
Internet-Draft NetLMM MN-AR Interface April 2006
is used as an input parameter to the CGA generation algorithm.
Therefore, even per [RFC2461] and [RFC2462] the MN cannot do any
optimization and MUST perform DAD for all of its configured CGAs,
which allows the AR to correctly detect any address configured on the
MN.
Laganier & Narayanan Expires October 12, 2006 [Page 17]
Internet-Draft NetLMM MN-AR Interface April 2006
4. Access Router Specification
A NetLMM AR MUST behave as specified in the following documents:
o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis]
o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis]
o Privacy Extensions for Stateless Address Autoconfiguration in IPv6
[I-D.ietf-ipv6-privacy-addrs-v2]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Hosts [I-D.ietf-dna-hosts]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Routers [I-D.ietf-dna-routers]
o Detecting Network Attachment with Unmodified Routers: A Prefix
List based approach [I-D.ietf-dna-cpl]
o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna-
protocol]
o SEcure Neighbor Discovery [RFC3971]
o Cryptographically Generated Addresses [RFC3972]
In addition, the AR MUST conforms to the supplementary NetLMM
specific requirements which follows in this section.
4.1. Promiscuous and all-multicast modes
The AR SHOULD put its external interface (the one exposed to MNs) in
snooping/promiscuous mode so that it can receive most of the packets
exchanged on the link it is serving. If a layer 2 switch is present
between the AR and MNs, the port to which the AR is connected SHOULD
be put in snooping/promiscuous mode. At the minimum, the AR MUST put
its interface into a "receive all-multicast traffic" mode, and
registers with MLDv2 [RFC3810] to all link-local solicited node
multicast addresses to which a MN registers to with MLDv2. This
insure that the AR can receive neighbor solicitations so that it can
proxy solicited neighbor advertisements when the target MN is off-
link.
4.2. Receiving Neighbor Discovery Messages from MN
The NetLMM specific processing of received Neighbor Discovery
Messages depends on whether a packet is a neighbor solicitation part
Laganier & Narayanan Expires October 12, 2006 [Page 18]
Internet-Draft NetLMM MN-AR Interface April 2006
of the DAD procedure, a solicited neighbor advertisement, or any
other neighbor discovery message. Section 4.2.1 defines the
processing rules for neighbor solicitations sent as part of the DAD
procedure. Section 4.2.2 defines the processing rules for solicited
neighbor advertisements. Section 4.2.3 defines the processing rules
for all others ND messages.
4.2.1. Receiving DAD Neighbor Solicitations
If the AR receives a DAD neighbor solicitation, and the solicitation
is secure according to [RFC3971], it MUST tries to register the
target address with the MAP. If the registration fails because this
address is used by a different MN, the AR MUST defend the target
address by sending a proxy neighbor advertisement as described in
Section 4.3.2.
4.2.2. Receiving Solicited Neighbor Advertisements
If the AR receives a Solicited Neighbor Advertisement for a target
address which does not belong to it, and the advertisement contains
both a valid CGA option as specified in Section 5.1.2. of [RFC3971],
a valid RSA Signature option as specified in Section 5.2.2. of
[RFC3971], and a valid Timestamp option as specified in Section
5.3.4.2. of [RFC3971], then it MUST register the target address with
the MAP.
4.2.3. Receiving All Others Neighbor Discovery Messages
If the AR receives any other neighbor discovery message than those
enumerated above, the solicitation is secure according to [RFC3971],
and the source address of the packet is not the unspecified IP
address, it MUST tries to register its source address with the MAP. [
XXX do we need to defend the address if registration fails? That
should not happen except in case of public key collisions... ]
4.3. Sending Neighbor Discovery Messages to MN
4.3.1. Sending Neighbor Solicitations
o The AR receives from the MN a SEND-protected Neighbor Discovery
message which does not allows the AR to verify the MN CGA
ownership. This can occurs if the MN includes a Nonce parameter
which is does not correspond to the Nonce sent by the AR to the
MN, or if the MN includes a Timestamp parameters which fail
because MN and AR clocks are desynchronized.
o The AR receives from the MN sends an IP packet which is not a
Neighbor Discovery Message before it sends a SEND-protected
Laganier & Narayanan Expires October 12, 2006 [Page 19]
Internet-Draft NetLMM MN-AR Interface April 2006
Neighbor Discovery message which allows the AR to verify MN CGA
ownership.
o The AR is performing the periodic reachability test of a MN it has
precedently registered with the MAP. If the MN is unreachable,
the AR MUST deregister this MN with the MAP.
4.3.2. Sending Proxy Neighbor Advertisements
An AR SHOULD send a proxy neighbor advertisement to a MN performing
DAD for an IP address which belongs to a MN which is known to be off-
link by the AR in order to defend that address, as specified in
Section 5.4. of [I-D.ietf-ipv6-2462bis].
An AR SHOULD send a proxy neighbor advertisement to a MN attempting
to communicate directly with a MN (because it think its correspondent
is on-link) which is known to be off-link by the AR. The "override"
flag (O) should be set to 1 (one) so that an existing neighbor cache
entry is replaced, as specified in Section 4.4. of [I-D.ietf-ipv6-
2461bis].
4.3.3. Sending Router Advertisements
All Prefix Information options included in router advertisements sent
by an AR SHOULD have the "on-link" flag (L) set to 0 (zero.) This
ensure that all packets sent by a MN are sent via the router. This
is necessary to insure that a MN trying to communicate with another
MN in the NetLMM domain but attached to a different AR is delivered
to the AR.
4.3.4. Sending Redirects
An AR SHOULD send a redirect to a MN attempting to communicate with a
MN which is known to be on-link by the AR, as specified in Section
4.5. of [I-D.ietf-ipv6-2461bis].
4.4. Receiving All Others IPv6 Packets from MN
If the AR receives any other IPv6 packet than those enumerated above
from a MN, and the source IP address is not registered yet with the
AR, the AR MUST initiate a reachability test with the MN as specified
in Section 4.3.1 to verify the MN CGA ownership.
4.4.1. Authenticated Packets
If the AR receives any other IPv6 packet than those enumerated above,
and the MN origin of this packet is authenticated (by another
security mechanism such as 802.11i or IPsec) and tied by any means to
Laganier & Narayanan Expires October 12, 2006 [Page 20]
Internet-Draft NetLMM MN-AR Interface April 2006
the public key used to generate the source CGA of that packet, then
the AR MAY update the MAP based on reception of such packets. [ XXX
TBD. ]
4.4.2. Unauthenticated Packets
Unauthenticated IPv6 packets MUST not trigger any action in the
NetLMM Domain. [ XXX TBD. ]
4.5. Mobile Node Identifier used by AR
All NetLMM messages generated by an AR upon reception of triggers
described in this document SHOULD use the SEND public key in the MNID
field of NetLMM messages. An alternative would be to use a truncated
(say 128 bits) secure hash of the public key to reduce message size
while keeping an equivalent security level.
Laganier & Narayanan Expires October 12, 2006 [Page 21]
Internet-Draft NetLMM MN-AR Interface April 2006
5. IANA Considerations
There is no IANA considerations.
Laganier & Narayanan Expires October 12, 2006 [Page 22]
Internet-Draft NetLMM MN-AR Interface April 2006
6. Acknowledgments
As usual in the IETF, this document is the result of a collaboration
between many people. The authors would like to thanks James Kempf
and Christian Vogt for discussion and/or comments that helped with
first version of this document.
Laganier & Narayanan Expires October 12, 2006 [Page 23]
Internet-Draft NetLMM MN-AR Interface April 2006
7. References
7.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-05 (work in progress),
October 2005.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[I-D.ietf-ipv6-2462bis]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", draft-ietf-ipv6-2462bis-08
(work in progress), May 2005.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[I-D.ietf-ipv6-privacy-addrs-v2]
Narten, T., "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6",
draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),
Laganier & Narayanan Expires October 12, 2006 [Page 24]
Internet-Draft NetLMM MN-AR Interface April 2006
December 2005.
[I-D.ietf-dna-hosts]
Narayanan, S., "Detecting Network Attachment in IPv6 -
Best Current Practices for hosts.",
draft-ietf-dna-hosts-02 (work in progress), October 2005.
[I-D.ietf-dna-routers]
Narayanan, S., "Detecting Network Attachment in IPv6 -
Best Current Practices for Routers",
draft-ietf-dna-routers-01 (work in progress),
October 2005.
[I-D.ietf-dna-cpl]
Nordmark, E. and J. Choi, "DNA with unmodified routers:
Prefix list based approach", draft-ietf-dna-cpl-02 (work
in progress), January 2006.
[I-D.pentland-dna-protocol]
Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-pentland-dna-protocol-01 (work in
progress), July 2005.
[I-D.wood-netlmm-emp-base]
Wood, J. and K. Nishida, "Edge Mobility Protocol (EMP)",
draft-wood-netlmm-emp-base-00 (work in progress),
October 2005.
7.2. Informative references
[I-D.kempf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for IP Local Mobility",
draft-kempf-netlmm-nohost-ps-01 (work in progress),
January 2006.
[I-D.kempf-netlmm-nohost-req]
Kempf, J., "Requirements and Gap Analysis for IP Local
Mobility", draft-kempf-netlmm-nohost-req-00 (work in
progress), July 2005.
[I-D.kempf-netlmm-threats]
Kempf, J. and C. Vogt, "Security Threats to Network-based
Localized Mobility Management",
draft-kempf-netlmm-threats-00 (work in progress),
February 2006.
Laganier & Narayanan Expires October 12, 2006 [Page 25]
Internet-Draft NetLMM MN-AR Interface April 2006
Authors' Addresses
Julien Laganier
DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312
Munich 80687
Germany
Phone: +49 89 56824 231
Email: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Sathya Narayanan
Panasonic Digital Networking Lab
Two Research Way, 3rd Floor
Princeton, NJ 08536
USA
Phone: +1 609 734 7599
Email: sathya@research.panasonic.com
Laganier & Narayanan Expires October 12, 2006 [Page 26]
Internet-Draft NetLMM MN-AR Interface April 2006
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.
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 (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Laganier & Narayanan Expires October 12, 2006 [Page 27]
