Network Working Group                                        J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Expires: October 12, December 28, 2006                                  S. Narayanan
                                                               Panasonic
                                                          April 10,
                                                              F. Templin
                                                    Boeing Phantom Works
                                                           June 26, 2006

  Network-based Localized Mobility Management Interface between Mobile
                         Node and Access Router
                     draft-ietf-netlmm-mn-ar-if-00
                     draft-ietf-netlmm-mn-ar-if-01

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, December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specify specifies 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
   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. SEND.)

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  . . .
       2.1.1.  SLAAC Method . . . . . . . . . . 11
     2.4.  MN configuring additional CGAs . . . . . . . . . . .  9
       2.1.2.  DHCP Method  . . . 13
     2.5.  MN configuring CGA that is in use by another MN in the
           NETLMM domain . . . . . . . . . . . . . . . . . . 10
     2.2.  First attachment of MN moving into a new NetLMM domain . . 11
       2.2.1.  SLAAC Method . . 13
     2.6.  MN unconfigures CGAs, powers off, crash or leave the
           domain . . . . . . . . . . . . . . . . . . . 11
       2.2.2.  DHCP Method  . . . . . . . 13
   3.  Mobile Node Specification . . . . . . . . . . . . . . 13
     2.3.  MN handovers in a NetLMM-domain  . . . . 16
   4.  Access Router Specification . . . . . . . . . 13
       2.3.1.  MN using SLAAC getting handover hint . . . . . . . . 18
     4.1.  Promiscuous and all-multicast modes . 13
       2.3.2.  MN using DHCP getting handover hint  . . . . . . . . . 14
       2.3.3.  AR getting handover hint . 18
     4.2.  Receiving Neighbor Discovery Messages from MN . . . . . . 18
       4.2.1.  Receiving DAD Neighbor Solicitations . . . . . . . . 15
     2.4.  MN configuring additional CGAs/prefixes  . 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 16
     2.5.  MN configuring CGA that is in use by another MN in the
           NetLMM domain  . . . . . . . . 19
       4.3.1.  Sending Neighbor Solicitations . . . . . . . . . . . . 19
       4.3.2.  Sending Proxy Neighbor Advertisements . . . 16
       2.5.1.  MN using SLAAC configuring colliding CGA . . . . . 20
       4.3.3.  Sending Router Advertisements . . 16
       2.5.2.  MN using DHCP configuring colliding global CGA . . . . 17
     2.6.  MN unconfigures CGAs, powers off, crashes or leaves
           the domain . . . . . . 20
       4.3.4.  Sending Redirects . . . . . . . . . . . . . . . . . . 20
     4.4.  Receiving All Others IPv6 Packets from 17
   3.  MN Specification . . . . . . . . 20
       4.4.1.  Authenticated Packets  . . . . . . . . . . . . . . . . 20
       4.4.2.  Unauthenticated Packets  .
   4.  AR Specification . . . . . . . . . . . . . . 21
     4.5.  Mobile Node Identifier used by AR . . . . . . . . . 22
     4.1.  Promiscuous and all-multicast modes  . . . 21
   5.  IANA Considerations . . . . . . . . 22
     4.2.  Receiving ND Messages from MN  . . . . . . . . . . . . . 22
   6.  Acknowledgments . 23
       4.2.1.  Receiving DAD NSs  . . . . . . . . . . . . . . . . . . 23
       4.2.2.  Receiving All Others ND Messages . . . . . . . . . . . 23
   7.  References
     4.3.  Sending ND Messages to MN  . . . . . . . . . . . . . . . . 23
       4.3.1.  Sending NSs  . . . . . . . . . . . . . . . . . . . . . 23
       4.3.2.  Sending Proxy NAs  . . . . . . . . . . . . . . . . . . 24
     7.1.  Normative references
       4.3.3.  Sending RAs  . . . . . . . . . . . . . . . . . . . . . 24
     7.2.  Informative references
       4.3.4.  Sending Redirects  . . . . . . . . . . . . . . . . . . 24
     4.4.  Receiving All Other IPv6 Packets from MN . . . . . . . . . 24
       4.4.1.  Authenticated Packets  . . . . . . . . . . . . . . . . 24
       4.4.2.  Unauthenticated Packets  . . . . . . . . . . . . . . . 24
       4.4.3.  Forwarding Packets . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses
     4.5.  MN Identifier and IP addresses . . . . . . . . . . . . . . 25
   5.  Multilink Subnet Considerations  . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27

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
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 29
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 30
   Appendix A.  Version history . . . . . . . . . . . . . . . . . . . 32
     A.1.  -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34

1.  Introduction

   It is suggested in [I-D.ietf-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.ietf-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 need to be adapted to the NetLMM
   protocol proposal chosen by the working group.  Because the NetLMM
   protocol is network based, the mobile node (MN) 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. router (AR.)

   Because the IPv6 mobile node MN will use a vanilla IPv6 stack, the interface
   between a mobile node MN and its access router AR 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  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]

   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 specifies an IP layer interface between mobile nodes (MN) MNs and access routers (AR) ARs of
   a network-based localized mobility
   management (NetLMM) 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. SEND.)

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

   The following 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. within the scope of this document:

   Mobile Node (MN): The MN is (MN)
      an IPv6 node moving in the NetLMM domain.

   Access Router (AR): The AR is the Mobile Node's (AR)
      a default router.

   External router that connects the MN to the NetLMM domain.

   access interface : A
      a network interface of an AR attached to the link used by the MN.

   Mobility Anchor Point (MAP): A Mobility Anchor Point is (MAP)
      a router located in the network-based localized mobility NetLMM domain handling
   exchanged between that handles packet
      exchanges with nodes in the domain.

   Network-based Localized Mobility Management Domain (NetLMM domain)
      an administrative domain spanning links served by a set of MAPs
      (and their associated ARs and MNs) that provision addresses from
      the Internet.

1.2.  Abbreviations

   Throughout this document, figures make use same IP subnet prefix(es).

   Network-based Localized Mobility Management Protocol (NLMP)
      The NetLMM Protocol used in the backhaul of the NetLMM domain
      between ARs and MAP.

1.2.  Abbreviations

   The following
   abbreviations: abbreviations are used throughout this document:

   NetLMM: Network-based Localized Mobility Management
   ND: Neighbor Discovery.

   NS: Neighbor Solicitation.

   NA: Neighbor Advertizement.

   RS: Router Solicitation.

   RA: Router Advertisement.

   NDP: Neighbor Discovery Protocol.

   SLAAC: StateLess Address AutoConfiguration

   DHCP: Dynamic Host Configuration Protocol

   SEND: SEcure Neighbor Discovery.

   DNA: Detecting Network Attachment.

   LNMP: NetLMM Protocol used in the backhaul of the NetLMM domain
   (between ARs and MAP.) Network Attachment.

   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 MN 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 MN and an
   access router AR of a NetLMM
   domain.  In the absence of link-layer specific mechanism, it allows
   the AR and/or MN to detect the network attachment
   of a MN and attachment, causing the AR to use
   NLMP to update routing at the MAP so that the MN stays reachable when
   it roams across the NetLMM domain.

                    /-----------\

         /-------------------------\
        /         Internet          \
        \                           /
                    \-----+-----/
                          |
                      +-------+
                      |  MAP
         \-------+---------+-------/
                 |
                      +---+---+         |
             /------------+------------\
         /-------+---------+-------\  ----
        /          NetLMM           \                           \          domain           /    ^
       / \-------------------------/         +-----+             \   |
       |         |
        +--+--+         +--+--+       +--+--+ MAP |-+           |   N
       | AR1         +-----+ |-+         |   E
       | AR2           +-----+ |         | AR3   T
       |             +-----+         |   L
       |       Backhaul Network      |   M
       |    +-----+       +-----+
          / \             / \           / \
         /   \           /   \         /   \
        /     \         /     \       /     \     MN-AR
    - -/- - - -\- - - -/- - - -\- - -/- - - -\- - - -    |   M
       |- - | AR1 | ..... | ARn | - -|
       |    +-----+       +-----+    |   d
       |      / \  Access   / \      |   o
       |     /   \ Interface Network /          +-----+   \     |   m
       |    /     \       /     \    |   a
       |    +----+                   |   i
       |    | MN | ------->  X          |   n
       \    +----+ AR change         /            +-----+ movement / \   |
        \                           /    v
         \-------------------------/  ----

   Figure 1: Reference Network Diagram

   The deployment scenario is shown in the figure Figure 1 above: Several ARs are
   attached to an IP routing domain connected to the outside Internet
   via a MAP.  The MNs, ARs, MAP, MAPs, and in-between routing fabric
   constitute the NetLMM domain.  Each AR announce announces on its external access
   interface a common set of prefix(es) which are routed to the MAP from
   the outside Internet.  Packets incoming arriving at the MAP and directed at the destined to a
   MN are tunneled to the appropriate AR based on the information provided by
   ARs. AR.

   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) ND, DHCP, SEND, and Detecting
   Network Attachment (DNA). DNA.  Interactions of these three components
   with NetLMM are represented in Figure 2 below (note that hints
   received by DNA from other layers are omitted for clarity):

                  MN|AR
                Interface
                    |

                    |     +------------+      +----------+
                          |            |      |          |
                    |     | +--------+ | NLMP | +------+ |
                          | | NetLMM |<-------->|NetLMM| |
                    |     | +--------+ |      | +------+ |
                          |   ^     ^  |      |    ^     |
   +----------+     |     |   |     |  |      |    |     |
   |          |           |   v     |  |      |    |     |
   | +------+ |     |     | +-----+ |  |      |    |     |
   | |  DNA | |    NDP  NDP/DHCP | | DNA | |  |      |    |     |
   | | SEND |<------|------>|SEND | |  |      |    |     |
   | |  ND  | |           | | ND  | |  |      |    |     |
   | +------+ | DHCP | |     |     | |DHCP | |  |      |    |     |
   | +------+ |           | +-----+ |  |      |    |     |
   |    ^     |     |   ^     |   ^     |  |      |    |     |
   |    |     |           |   |     |  |      |    |     |
   |    v     |     |     |   v     |  |      |    v     |
   | +------+ |           |     | +----+  |  |      | +------+ |
   | |      | |     |     |    |<-+ |    |<-+  |      | |      | |
   | |      | |   IPv6    | |    |     | IPv6 | |      | |
   | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | |
   | +------+ |           | +----+     |      | +------+ |
   |          |     |     |            |      |          |
   |    MN    |           |    AR      |      |   MAP    |
   +----------+     |     +------------+      +----------+

                    |

   Figure 2: NetLMM Component Interactions

2.  Protocol Overview

   The following subsections present the different situations in which
   an IP-based MN-AR interface is used to trigger the NetLMM protocol.

   In the 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 an NS with a fresh nonce, to which
   the MN would reply with an NA containing the same fresh nonce.

2.1.  MN powers on in a NetLMM domain

2.1.1.  SLAAC Method

   MN                       AR                     MAP
   |                        |                       |
   |    NS(DAD:CGA_LL)      |  UPDATE(MNID,CGA_LL)  |
   |----------------------->|---------------------->| bind(CGA_LL,MNID)
   |                        |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR)
   |                        |<----------------------|
   |RS(CGA_LL->All_routers) |                       |
   |----------------------->|                       |
   |   IPv6 RA(AR->{MN,All_nodes}) |                       |
   |<-----------------------|                       |
   | IPv6                        |                       |
   |    NS(DAD:CGA_1)       |   UPDATE(MNID,CGA_1)  |
   |----------------------->|---------------------->| bind(CGA_1,MNID)
   | IPv6 |<------|------>|IPv6|<------------>| IPv6                        | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR)
   | +------+                        |<----------------------|
   |                        | +----+                       |
   | +------+    NS(DAD:CGA_2)       |   UPDATE(MNID,CGA_2)  |
   |----------------------->|---------------------->| bind(CGA_2,MNID)
   |                        | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR)
   |                        |<----------------------|
   |                        |                       |

   Figure 3: MN    |           | powers on and configures a Link-Local and two Global
   Unicast CGAs using SLAAC

   As shown in Figure 3 above, when a MN using SLAAC 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 NS(DAD) message generated will contain the public key
   in the CGA option as defined by SEND [RFC3971].  Upon reception of
   this NS message, the AR      |      | MUST generate an UPDATE to the MAP    |
   +----------+     |     +------------+      +----------+

                    |

2.  Protocol Overview with the
   public key as the MNID along with CGA_LL.  The following subsections present MAP MUST bind the different situations in which
   CGA_LL to the MNID and establish a route binding for the CGA_LL to
   the AR.  The MAP acknowledges the receipt of the UPDATE message.

   While waiting for the MN-AR interface is used to trigger completion of DAD, the NetLMM protocol.

2.1. MN powers on in may generate an RS
   message as per [RFC2461] with the unspecified address as the source
   address.  Such a NetLMM domain

   +-------------------------------------------------------------------+
   |Caption :In following figures it is assumed that message will not contain a CGA option.  The AR will
   respond with a multicast RA as per [RFC2461].  Alternatively, the MN and AR     |
   |         clocks are synchronized enough to allow verification
   will wait for completion of ND|
   |         messages via SEND timestamps.  If that would not be DAD and generate an RS message with its
   CGA-LL as the   |
   |         case, source address.  With the prefix information received
   in order the RA message, the MN can cryptographically generate one or more
   global addresses (CGA_*).  For each of these addresses, the MN will
   perform DAD as the IID is likely to verify freshness be different for each of ND signaling sent   |
   |         by these
   cryptographically generated addresses.  For every NS(DAD) received
   from the MN, the AR would will generate an UPDATE message to the MAP
   establishing binding in the MAP.

   The use of multicast RAs may however not be required acceptable in all NetLMM
   domains, e.g., when multiple MAPs and/or prefixes are used.  In that
   case, the network has to solicit somehow force the MN by  |
   |         sending to it a NS with a fresh nonce, to which source RSs from its
   CGA-LL, so that the MN    |
   |         would reply with AR can send to that CGA-LL a NA unicast RA
   containing the same fresh nonce.    |
   +-------------------------------------------------------------------+ appropriate prefix information.  This can be achieved
   by having the AR simply discard any RS sourced from the unspecified
   address, so that eventually the MN will complete DAD for its CGA-LL
   and start to use it as a source address while retransmitting RSs.

2.1.2.  DHCP Method

   MN                      AR1                       AR                     MAP
   |                        |                       |
   |    NS(DAD:CGA_LL)      |  UPDATE(MNID,CGA_LL)  |
   |----------------------->|---------------------->| bind(CGA_LL,MNID)
   |                        |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR1) route(CGA_LL->AR)
   |                        |<----------------------|
   |         RS
   |RS(CGA_LL->All_routers) |                       |
   |----------------------->|                       |
   |         RA RA(AR->{MN,All_nodes}) |                       |
   |<-----------------------|                       |
   |    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)  DHCP SOLICIT(CGA_*)   |   UPDATE(MNID,CGA_2)   UPDATE(MNID,CGA_*)  |
   |----------------------->|---------------------->| bind(CGA_2,MNID)
   | bind(CGA_1,MNID)
   | REPLY[OK](MNID,CGA_2)  DHCP REPLY(STATUS)    | route(CGA_2->AR1) REPLY[OK](MNID,CGA_*) |                        |<----------------------| route(CGA_1->AR)
   |<-----------------------|<----------------------| route(CGA_2->AR)
   |                        |                       |

   Figure 1: 4: MN powers on and configures a Link-Local and two Global
   Unicast CGAs

   When using DHCP with two-message exchange
   As shown in Figure 4 above, when a MN using DHCP powers on for the
   first time, time it will cryptographically generate a link local
   address based on CGA_LL and perform an
   RS/RA exchange as specified for the SLAAC method in Section 2.1.1.

   The MN will then use its public key (CGA_LL) as to generate a DHCP Unique
   Identifier (DUID) and Identity Association (IA) per [RFC3972], ([RFC3315],
   Sections 9 and
   perform DAD on 10).  If prefix information is included in the address as RA
   message, the MN can next cryptographically generate one or more
   global addresses (CGA_*).  (The MN can additionally request
   delegation of prefixes per [RFC2462]. [RFC3633].)  The DAD-NS MN will then issue a DHCP
   SOLICIT message
   generated including the DUID, IA and IA Address options that
   encode any CGA_*s as options.  (Alternatively, the MN can omit IA
   Address options and allow the network to delegate non-CGA addresses.)
   If a two-message exchange is preferred, the MN will contain also include a
   Rapid Commit option in the public key DHCP SOLICIT per ([RFC3315], Section
   17.1.2).

   When the AR receives the DHCP SOLICIT (using two-message exchange) or
   DHCP REQUEST (using four-message exchange), it performs the same
   UPDATE/REPLY procedure as specified in Section 2.1.1, and returns a
   DHCP REPLY message with an appropriate status code to the CGA option MN.

   The issues involved with the use of multicast RAs as defined by
   SEND [RFC3971].  Upon reception described in
   Section 2.1.1 might be valid when DHCP is used for address
   configuration.

2.2.  First attachment of this NS message, the access router
   (AR1) SHOULD generate MN moving into a new NetLMM domain

2.2.1.  SLAAC Method
   MN                     AR                      MAP
   |                       |                       |
   |        RS             |  UPDATE(MNID,CGA_LL)  |
   |---------------------->|---------------------->| bind(CGA_LL,MNID)
   |        RA             |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR)
   |<----------------------|<----------------------|
   |   NS(DAD:CGA_LL)      |                       |
   |---------------------->|                       |
   |                       |                       |
   |                       |                       |
   |   NS(DAD:CGA_1)       |   UPDATE(MNID,CGA_1)  |
   |---------------------->|---------------------->| bind(CGA_1,MNID)
   |                       | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR)
   |                       |<----------------------|
   |                       |                       |
   |   NS(DAD:CGA_2)       |   UPDATE(MNID,CGA_2)  |
   |---------------------->|---------------------->| bind(CGA_2,MNID)
   |                       | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR)
   |                       |<----------------------|
   |                       |                       |

   Figure 5: MN moves into a UPDATE to the MAP with the public key as the
   MNID along with CGA_LL.  The MAP SHOULD bind the CGA_LL to the MNID NetLMM domain and establish configures a route binding Link-Local
   and two Global Unicast CGAs using SLAAC

   As shown in Figure 5 above, when a MN using SLAAC moves into a NetLMM
   domain for the CGA_LL to the access router
   AR1.  The MAP acknowledges the receipt first time, it will initiate link change detection as
   specified in [I-D.pentland-dna-protocol] by multicast transmission of the UPDATE
   an RS message.

   While waiting for the completion of DAD,  When the MN may generate RS
   message as per [RFC2461] with the unspecified address as the source
   address.  Such receives an RS RA message in response, it
   will not contain figure out that it has changed to a CGA option.  The
   access router will respond with link in a multicast RA new NetLMM domain
   as per [RFC2461].
   With the prefix information received in defined by the RA message, DNA specification [I-D.pentland-dna-protocol].
   Once the MN realizes it has changed to a new NetLMM domain, it will
   cryptographically generate one or more global
   discard its current IP addresses (CGA_*).  For
   each of these addresses, the MN and will perform execute 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 its link-
   local address and new global addresses based on the MAP establishing binding prefix
   information in the MAP.

2.2.  First attachment received RA messages.

   The global address configuration procedures of the MN, AR and MAP are
   the same as specified in Section 2.1.1.

2.2.2.  DHCP Method

   MN moving into a NetLMM domain

   MN                     AR2                     AR                      MAP
   |                       |                       |
   |        RS             |                       |
   |---------------------->|                       |
   |        RA             |                       |
   |<----------------------|                       |
   |   NS(DAD:CGA_LL)      |
   |RS(CGA_LL->All_routers)|  UPDATE(MNID,CGA_LL)  |
   |---------------------->|---------------------->| bind(CGA_LL,MNID)
   |        RA             |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2)
   |<----------------------|<----------------------|
   |                       |<----------------------|
   |   NS(DAD:CGA_1)       |   UPDATE(MNID,CGA_1)  |
   |---------------------->|---------------------->| bind(CGA_1,MNID)
   |   NS(DAD:CGA_LL)      | REPLY[OK](MNID,CGA_1)                       | route(CGA_1->AR2)
   |---------------------->|                       |                       |<----------------------|
   |                       |                       |
   |   NS(DAD:CGA_2)  DHCP SOLICIT(CGA_*)  |   UPDATE(MNID,CGA_2)   UPDATE(MNID,CGA_*)  |
   |---------------------->|---------------------->| bind(CGA_2,MNID)
   | bind(CGA_1,MNID)
   | REPLY[OK](MNID,CGA_2)  DHCP REPLY(STATUS)   | route(CGA_2->AR2) REPLY[OK](MNID,CGA_1) |                       |<----------------------| route(CGA_1->AR)
   |<----------------------|<----------------------| route(CGA_2->AR)
   |                       |                       |

   Figure 2: 6: MN moves into a NetLMM domain and configures a Link-Local
   and two Global Unicast CGAs

   When using DHCP

   As shown in Figure 6 above, when a MN using DHCP moves into a NETLMM NetLMM
   domain for the first time, it will initiate link change detection as
   specified in [I-D.pentland-dna-
   protocol] [I-D.pentland-dna-protocol] by multicast transmission of a
   an RS message.  When the MN receives a an RA message in response, it
   will figure out that it has changed to a link in a new NetLMM domain
   as defined by the DNA specification [I-D.pentland-dna-
   protocol]. [I-D.pentland-dna-protocol]
   and/or by sending a DHCP CONFIRM message as specified in
   Section 2.3.2.  Once the MN realizes it has changed link, to a new NetLMM
   domain, it will discard its current IP addresses and will execute DAD
   for its link-local address and configure new global addresses based on the prefix information in
   the received RA messages. addresses/
   prefixes using DHCP.

   The behavior global address configuration procedures of the access router AR2 in response to MN, AR and MAP are
   the DAD messages
   is similar to that of AR1 specific same as specified in Section 2.1. 2.1.2.

2.3.  MN handovers in a NetLMM-domain

2.3.1.  MN using SLAAC getting handover hint
   MN                      AR3                       AR                     MAP
   |                        |                       |
   |RS(CGA_LL->All_routers) |   UPDATE(MNID,CGA_*)  |
   |----------------------->|---------------------->| route(CGA_LL->AR3) route(CGA_LL->AR)
   |                        |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR3) route(CGA_1->AR)
   |    RA(AR->CGA_LL)      |          CGA_1,CGA_2) | route(CGA_2->AR3) route(CGA_2->AR)
   |<-----------------------|<----------------------|
   |                        |                       |

   Figure 3: 7: MN using SLAAC getting handover hint and receives a unicast
   RA

   When the

   As shown in Figure 7, when MN using SLAAC moves within the NETLMM NetLMM
   domain, it will send a an RS message with the source address as its
   link-local address as specified by [I-D.pentland-dna-protocol].  The access router
   AR again can use the public key in the CGA option to infer the MNID
   and send updates UPDATEs to the MAP.  If the access router AR chooses to respond with a
   unicast RA, all required steps are done.

   MN                      AR4                       AR                     MAP
   |                        |                       |
   |RS(CGA_LL->All_routers) |   UPDATE(MNID,CGA_*)  |
   |----------------------->|---------------------->| route(CGA_LL->AR4) route(CGA_LL->AR)
   |                        |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR4) route(CGA_1->AR)
   |   RA(AR->All_nodes)    |          CGA_1,CGA_2) | route(CGA_2->AR4) route(CGA_2->AR)
   |<-----------------------|<----------------------|
   |         NS     NS(CGA_LL->AR)     |                       |
   |----------------------->|                       |
   |         NA     NA(AR->CGA_LL)     |                       |
   |<-----------------------|                       |
   |                        |                       |

   Figure 4: 8: MN using SLAAC getting handover hint and receives a
   multicast RA

   In a similar scenario, as shown in Figure 8, if the AR chooses to
   respond with a multicast RA, the MN will send an NS to learn about
   the AR and confirm reachability.

2.3.2.  MN using DHCP getting handover hint

   When a MN using the DHCP access method moves within the NetLMM
   domain, it receives the same handover hints as specified in
   Section 2.3.1.

   MN                      AR                     MAP
   |                        |                       |
   |  DHCP CONFIRM(CGA_*)   |  UPDATE(MNID,CGA_*)   |
   |----------------------->|---------------------->| route(CGA_LL->AR)
   |  DHCP REPLY(STATUS)    | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR)
   |<-----------------------|<----------------------| route(CGA_2->AR)
   |                        |                       |

   Figure 9: DHCP CONFIRM message exchange

   As shown in Figure 9, when the MN getting handover hint and receives a multicast RA
   In figures out that it has changed
   link, it sends a similar scenario, if DHCP CONFIRM message containing its IA and all of
   the access router chooses CGAs/prefixes it has previously registered per ([RFC3315],
   Section 18.1.2).  The AR will generate an UPDATE message to respond with a
   multicast RA, the MN MAP
   and will send a NS DHCP REPLY message to learn about the access router
   and confirm reachability. MN                      AR5 with appropriate status
   codes.

2.3.3.  AR getting handover hint

   MN                       AR                     MAP
   |                        |                       |
   |     NS(AR->CGA_*)      |                       |
   |<-----------------------|                       |
   |     NA(CGA_*->AR)      |  UPDATE(MNID,CGA_*)   |
   |----------------------->|---------------------->| route(CGA_LL->AR5) route(CGA_LL->AR)
   |                        |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR5) route(CGA_1->AR)
   |                        |          CGA_1,CGA_2) | route(CGA_2->AR5) route(CGA_2->AR)
   |                        |<----------------------|
   |                        |                       |

   Figure 5: 10: AR getting handover hint of MN whose IP address is known

   Instead

   As shown in Figure 10, instead of the MN receiving the hint, hint in
   scenarios were where the access
   router AR receives the hint with the IP address of the
   handing over MN, the AR can send a an 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 an UPDATE message to the MAP.

   MN                      AR6                       AR                     MAP
   |                        |                       |
   |   RA(AR->All_nodes)    |                       |
   |<-----------------------|                       |
   |     NS(CGA_*->AR)      |   UPDATE(MNID,CGA_*)  |
   |----------------------->|---------------------->| route(CGA_LL->AR6) route(CGA_LL->AR)
   |                        |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR6) route(CGA_1->AR)
   |     NA(AR->CGA_*)      |          CGA_1,CGA_2) | route(CGA_2->AR6) route(CGA_2->AR)
   |<-----------------------|<----------------------|
   |                        |                       |

   Figure 6: 11: AR getting handover hint of MN whose IP address is unknown

   If

   As shown in Figure 11, if the access router AR 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 AR and confirm its reachability by initiating a an
   NS message to the AR.  The AR can then send update an UPDATE message to the
   MAP based on the public key in the NS message.

2.4.  MN configuring additional CGAs CGAs/prefixes

   If the MN choose chooses to configure new global addresses addresses/prefixes 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 AR to configure the corresponding public key new addresses/
   prefixes as specified in the Section 2.1.

2.5.  MN configuring CGA option. that is in use by another MN                      AR in the NetLMM
      domain

2.5.1.  MN using SLAAC configuring colliding CGA

   MN1       AR1                 MAP               AR2       MN2
    |         |                   |                 |     NS(DAD:CGA_3)         |   UPDATE(MNID,CGA_3)
    |
   |----------------------->|---------------------->| bind(CGA_3,MNID) NS(DAD) |UPDATE(MNID,CGA,NS)|                 |         | REPLY[OK](MNID,CGA_3)
    |-------->|------------------>| collision(MNID) | route(CGA_3->AR)         |                        |<----------------------|
    |         |                   |                 |         |
    |         |                   | QUERY[DAD](NS)  | NS(DAD) |
    |         |                   |---------------->|-------->|
    |         |                   | REPLY[DAD](NA)  |  NA     |
    |         |                   |<----------------|<--------|
    |   NA    |REPLY[COLLIDE](NA) |
    |<--------|<------------------|
    |         |                   |

   Figure 7: MN configuring later on additional CGAs

2.5. 12: MN using SLAAC configuring a colliding CGA that is in use by another MN
   As shown in the NETLMM
      domain

   The access router Figure 12, AR1 learns about new global addresses
   configured by the an MN MN1 from the NS-DAD NS(DAD) message sent by MN. MN1.  When the AR
   AR1 sends an UPDATE to the MAP based on this DAD-NS, NS(DAD), it also
   includes the entire NS in the message, and waits for a positive
   acknowledgment from the MAP.  If the MAP has an entry for the save same
   CGA with a different MNID, it will respond proxy this NS(DAD) up to the AR
   where the duplicate occurs (AR2).  AR2 will then proxy the NS(DAD) by
   sending it to the solicited-node multicast address of the colliding
   MN MN2, and will receive back with a message
   indicating collision and signed NA from MN2.  AR2 will then
   forward this signed NA to AR1 via the AR must proxy for MAP.  At that point, AR1 can
   securely defend the other MN duplicate address on behalf of MN2 by
   responding sending to
   MN1 the DAD-NS. signed NA.

2.5.2.  MN using DHCP configuring colliding global CGA

   MN                       AR                     MAP
   |                        |                       |
   |     NS(DAD:CGA_3)  DHCP SOLICIT(CGA_*)   |   UPDATE(MNID,CGA_3)  UPDATE(MNID,CGA_*)   |
   |----------------------->|---------------------->| collision(MNID) collision(CGA_*)
   |  DHCP REPLY(status)    | REPLY[COLLIDE](CGA_*) |     NA(CGA_3->MN)      |REPLY[COLLISION](CGA_3)|
   |<-----------------------|<----------------------|
   |                        |                       |

   Figure 8: 13: MN using DHCP configuring later on a colliding global CGA

   As shown in Figure 13, when a MN using DHCP configures one or more
   global CGAs, the MAP sends a REPLY to the AR with an indication for
   each global CGA that collided.  The AR then sends a DHCP REPLY
   message to the MN with the appropriate status code for each colliding
   CGA.

2.6.  MN unconfigures CGAs, powers off, crash crashes or leave leaves the domain

   It is recommended that the access router

   The AR SHOULD do periodic reachability testing with MN, the MN using
   Neighbor Unreachability Detection (NUD), (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
   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: 14: MN unconfigures a CGA

   As shown in Figure 14, the MN stops using the address CGA_1 and when
   the AR tries NUD for each of these addresses, it doesn't receive a
   response for CGA_1, resulting in an UPDATE message to the MAP to
   remove the mapping between MNID and CGA_1.

   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)

   Figure 10: 15: MN crashes, powers off or leaves the domain
   As shown in Figure 10, 15, 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 AR can remove the entry for the mobile node MN from the MAP by
   initiating a an UPDATE message.

3.  Mobile Node  MN Specification

   There is no few

   NetLMM place few specific requirements place on a Mobile Node an MN 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

   Also, for MNs attached to networks that use DHCP, the MN MUST support
   the DHCP client message exchanges specified in:

   o  Dynamic Host Configuration Protocol for IPv6 [RFC3315]

   The MN MUST use a single public key to generate all of their its 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 update routing for all
   MN CGAs even if the MN is currently using only one of those (e.g. its
   link-local CGA CGA) to send a router solicitation.) an RS.

   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 avoids 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  This is used causes because IIDs from of CGAs with
   different subnet prefixes to be are different because the subnet prefixes (subnet prefix 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 algorithm.)

   For NBMA links, links over which multicast is not well supported or
   for all selection of its configured CGAs,
   which allows specific neighbors, MNs and ARs can send packets
   addressed to the AR pre-defined multicast addresses specified in
   ([RFC4291], Section 2.7.1) to correctly detect any address configured on the
   MN. Layer-2 unicast address(es) of one
   or more neighbors.

4.  Access Router  AR 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]

   Also, ARs MUST respond to DHCP client messages in a manner that is
   consistent with the DHCP relay/server messaging specified in:

   o  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]

   In addition, the AR MUST conforms conform to the supplementary NetLMM specific
   requirements which follows follow in this section.

4.1.  Promiscuous and all-multicast modes

   The AR SHOULD put its external access 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
   insures that the AR can receive neighbor solicitations NSs so that it can proxy solicited neighbor advertisements
   NAs when the target MN is off-
   link. off-link.

4.2.  Receiving Neighbor Discovery ND Messages from MN

   The NetLMM specific processing of received Neighbor Discovery ND Messages depends on
   whether a packet is a neighbor solicitation an NS part of the DAD procedure, a solicited neighbor advertisement, or any other neighbor discovery ND
   message.  Section 4.2.1 defines the processing rules for neighbor solicitations NSs 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 NSs

   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 DAD NS which is secure according to [RFC3971], then
   it MUST try to register the target address with the MAP.

4.2.3.  If the
   registration fails because this address is used by a different MN,
   the AR MUST defend the target address by sending a proxy NA as
   described in Section 4.3.2.

4.2.2.  Receiving All Others Neighbor Discovery ND Messages

   If the AR receives any other neighbor discovery ND message than those enumerated above,
   the solicitation message is secure according to [RFC3971], and the source address
   of the packet is not the unspecified IP address, it MUST tries try 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 ND Messages to MN

4.3.1.  Sending Neighbor Solicitations NSs

   An AR sends an NS to a MN in the following cases:

   o  The AR receives from the MN a SEND-protected Neighbor Discovery ND message which does
      not allows allow the AR to verify the MN CGA ownership.  This can occurs occur
      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 parameter which fail fails because the MN and AR clocks are
      desynchronized.

   o  The AR receives from the MN sends an IP packet which is not a
      Neighbor Discovery ND or DHCP
      Message before it sends a SEND-protected
      Neighbor Discovery message which allows the AR to verify MN CGA
      ownership. registers the IP packet's source address.

   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.

   In all the cases described above, the AR MUST verify MN CGA ownership
   by sending to the MN CGA an NS message including the MN CGA as a
   target address and a fresh Nonce.

4.3.2.  Sending Proxy Neighbor Advertisements NAs

   An AR SHOULD send a proxy neighbor advertisement NA to a MN performing DAD for an IP address
   which belongs to a MN which is known to be off-
   link 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 allow SEND MNs to be off-link accept proxy NS sent by the AR.  The "override"
   flag (O) AR, the AR should be set to 1 (one) so that an existing neighbor cache
   entry is replaced, as specified
   follow the procedure described in Section 4.4. of [I-D.ietf-ipv6-
   2461bis]. Figure 12.

4.3.3.  Sending Router Advertisements RAs

   All Prefix Information options included in router advertisements RAs sent by an AR SHOULD
   have the "on-link" flag (L) set to 0 (zero.)  This
   ensure ensures 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 AR.

   When the NetLMM domain but attached to a different AR is delivered RAs contain no Prefix Information options, or when the MN
   wishes to procure additional prefixes, the AR. MN can use DHCP prefix
   delegation mechanisms per [RFC3633].

4.3.4.  Sending Redirects

   An AR SHOULD send a redirect to a MN attempting to communicate with SHOULD NOT send a
   MN which is known to be on-link by the AR, as specified in redirect message ([I-D.ietf-ipv6-2461bis],
   Section
   4.5. of [I-D.ietf-ipv6-2461bis]. 8.2) unless it can determine that the sending node and better
   first-hop node reside on the same link and will remain on the same
   link.

4.4.  Receiving All Others Other 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
   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 NOT trigger any action in the
   NetLMM Domain. [ XXX TBD. ]

4.4.3.  Forwarding Packets

   [RFC4291] states that:

      ARs MUST NOT forward any packets with Link-Local source or
      destination addresses to other links.

      Link-Local multicast scope spans the same topological region as
      the corresponding unicast scope.

   This specification does not modify that behavior, i.e. an AR MUST NOT
   forward packets sent by a MN from or to a link-local address (unicast
   or multicast).

4.5.  Mobile Node  MN Identifier used by AR and IP addresses

   All NetLMM NLMP 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.

5. this document SHOULD use the SEND public key in the MNID
   field of NLMP 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.  This public key MNID is
   hence securely bound to the set of IP addresses used by the MN,
   therefore preventing different redirection attacks.

   In some deployments where MNs do not use ND and SEND (e.g. some
   cellular systems [RFC3316]), ARs and MAPs in the NetLMM domain SHOULD
   enforce the binding between an authenticated MN identity and the set
   of IP addresses used by the MN.  In other words the network keeps
   track of IP addresses allocated to a specific MN identity.  In the
   case of DHCP address allocation, DHCP requests and replies should be
   protected by a link-layer security context indexed by the
   authenticated MN identity.

5.  Multilink Subnet Considerations

   Multilink subnet issues are analyzed in [I-D.thaler-intarea-
   multilink-subnet-issues].

   When each MN assigns addresses from separate IP prefixes, (e.g., per
   [I-D.thaler-autoconf-multisubnet-manets]) there are no multilink
   subnet issues.

   When multiple MNs assign addresses from a shared IP prefix, multilink
   subnet issues can be avoided if ARs and MAPs act as neighbor
   discovery proxies as described in Figure 12, and ARs do not advertize
   subnet prefixes as "on-link" as described in Section 4.3.3.

6.  IANA Considerations

   There is are no IANA considerations.

6.

7.  Acknowledgments

   As usual in the IETF, this document is the result of a collaboration
   between many people.  The authors would like to thanks (in
   alphabetical order) James Kempf Kempf, Alexandru Petrescu and Christian
   Vogt for discussion and/or comments that helped with first version of
   this document.

7.

   Ian Chakeres contributed the reference network diagram.  Portions of
   this work were supported by the Boeing IRAD program and Boeing
   colleagues.

   Julien Laganier is partly funded by Ambient Networks, a research
   project supported by the European Commission under its Sixth
   Framework Program.  The views and conclusions contained herein are
   those of the authors and should not be interpreted as necessarily
   representing the official policies or endorsements, either expressed
   or implied, of the Ambient Networks project or the European
   Commission.

8.  References

7.1.

8.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
              draft-ietf-ipv6-2461bis-07 (work in progress),
              October 2005. May 2006.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [I-D.ietf-ipv6-2462bis]
              Thomson, S., Narten,

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and T. Jinmei, M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Stateless
              Address Autoconfiguration", draft-ietf-ipv6-2462bis-08
              (work in progress), May 2005. Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [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.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [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),
              December 2005.

   [I-D.ietf-dna-hosts]
              Narayanan, S., "Detecting Network Attachment in IPv6 -
              Best Current Practices for hosts.",
              draft-ietf-dna-hosts-02
              draft-ietf-dna-hosts-03 (work in progress), October 2005. May 2006.

   [I-D.ietf-dna-routers]
              Narayanan, S., "Detecting Network Attachment in IPv6 -
              Best Current Practices for Routers",
              draft-ietf-dna-routers-01
              draft-ietf-dna-routers-02 (work in progress),
              October 2005. March 2006.

   [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.

   [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.

8.2.  Informative references

   [I-D.kempf-netlmm-nohost-ps]

   [RFC3316]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
              Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
              Second and Third Generation Cellular Hosts", RFC 3316,
              April 2003.

   [I-D.ietf-netlmm-nohost-ps]
              Kempf, J., "Problem Statement for IP Local Mobility",
              draft-kempf-netlmm-nohost-ps-01 Network-based Localized
              Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work
              in progress),
              January June 2006.

   [I-D.kempf-netlmm-nohost-req]

   [I-D.ietf-netlmm-nohost-req]
              Kempf, J., "Requirements and Gap Analysis "Goals for IP Local
              Mobility", draft-kempf-netlmm-nohost-req-00 Network-based Localized Mobility
              Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
              (work in progress), July 2005.

   [I-D.kempf-netlmm-threats] April 2006.

   [I-D.ietf-netlmm-threats]
              Kempf, J. and C. Vogt, "Security Threats to Network-based
              Localized Mobility Management",
              draft-kempf-netlmm-threats-00
              draft-ietf-netlmm-threats-00 (work in progress),
              April 2006.

   [I-D.thaler-intarea-multilink-subnet-issues]
              Thaler, D., "Issues With Protocols Proposing Multilink
              Subnets", draft-thaler-intarea-multilink-subnet-issues-00
              (work in progress), March 2006.

   [I-D.thaler-autoconf-multisubnet-manets]
              Thaler, D., "Multi-Subnet MANETs",
              draft-thaler-autoconf-multisubnet-manets-00 (work in
              progress), February 2006.

Appendix A.  Version history

A.1.  -00 to -01

   o  added DHCP access method including DHCP prefix delegation.

   o  added new network reference diagram.

   o  added definitions for NetLMM domain and NLMP.

   o  updated NA proxying method for colliding CGAs.

   o  added text on sending IP multicast messages to a Layer-2 unicast
      address.

   o  added new Section 4.5 text on MNID/IP address binding.

   o  added new Section 5. on multilink subnet issues.

   o  various editorial changes."

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

   Fred L. Templin
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: fred.l.templin@boeing.com

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.