Network Working Group                                        J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Expires: December 28, 2006
Intended status: Informational                              S. Narayanan
Expires: November 23, 2007                                     Panasonic
                                                              F. Templin
                                                    Boeing Phantom Works
                                                           June 26, 2006
                                                            May 22, 2007

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

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

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   This document specifies describes an IP layer interface between mobile nodes (MN) and
   mobility access routers (AR) gateway (MAG) of a network-based localized mobility
   management (NetLMM) (NETLMM) domain.  Such an  The interface is subject to a
   certain number of threats, amongst has two functions which
   are attacks on invocated when a MN attaches and detaches from a MAG.  The
   attachment function let the mapping
   between MAG authenticate the MN Identifier identifier, does
   address(es) 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 default router configuration for the absence MN, and inform
   the MAG about the multicast listener state 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 MN.  During a
   successful execution of the detachment function, the NETLMM protocol
   is present on MNs. triggered between the MAG and the localized mobility anchor (LMA).
   The IP
   layer MN-AR interface described in this document fulfills these two
   requirements by using detachment function let the SEND public key as MAG detect that the MN identifier, while
   being solely based on standard track IPv6 protocols (DNA and SEND.) has left so
   that it can deregister the MN at the LMA using the NETLMM protocol.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Abbreviations
   3.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  7
   4.  Interactions of NETLMM Architecture with Subnet and Link
       Models . .  5
     1.3.  Operating Environment . . . . . . . . . . . . . . . . . .  6
   2.  Protocol Overview . . . . . . . . 10
     4.1.  NETLMM Subnet Model  . . . . . . . . . . . . . .  9
     2.1.  MN powers on in a NetLMM domain . . . . . 10
     4.2.  NETLMM Link Model  . . . . . . . .  9
       2.1.1.  SLAAC Method . . . . . . . . . . . . 11
   5.  Address Collision Considerations . . . . . . . . .  9
       2.1.2.  DHCP Method . . . . . . 12
   6.  MN_ATTACH Function . . . . . . . . . . . . . . . 10
     2.2.  First attachment of MN moving into a new NetLMM domain . . 11
       2.2.1.  SLAAC Method . . . . . 13
     6.1.  MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 11
       2.2.2.  DHCP Method 13
     6.2.  MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15
     6.3.  MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . 13
     2.3.  MN handovers in a NetLMM-domain . . . . . 15
     6.4.  MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . 13
       2.3.1.  MN using SLAAC getting handover hint . . . 15
   7.  MN_DETACH Function . . . . . . 13
       2.3.2.  MN using DHCP getting handover hint . . . . . . . . . 14
       2.3.3.  AR getting handover hint . . . . . . . 17
   8.  Security Considerations  . . . . . . . . 15
     2.4.  MN configuring additional CGAs/prefixes . . . . . . . . . 16
     2.5.  MN configuring CGA that is in use by another MN in the
           NetLMM domain . . 18
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
       2.5.1.  MN using SLAAC configuring colliding CGA . 19
   10. Acknowledgments  . . . . . . 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
   11. References . . . . . . 17
   3.  MN Specification . . . . . . . . . . . . . . . . . . . . 21
     11.1. Normative references . . . 20
   4.  AR Specification . . . . . . . . . . . . . . . . 21
     11.2. Informative references . . . . . . . 22
     4.1.  Promiscuous and all-multicast modes . . . . . . . . . . . 22
     4.2.  Receiving ND Messages from MN  . . . . . . . . . . . . . . 23
       4.2.1.  Receiving DAD NSs  . . . . . . . . . .
   Appendix A.  Version history . . . . . . . . 23
       4.2.2.  Receiving All Others ND Messages . . . . . . . . . . . 23
     4.3.  Sending ND Messages
     A.1.  -01 to MN  . . . . . . . . . . -02 . . . . . . 23
       4.3.1.  Sending NSs  . . . . . . . . . . . . . . . . . . . . . 23
       4.3.2.  Sending Proxy NAs  . . . . . . . . . . . . . . . . . . 24
       4.3.3.  Sending RAs  . . . . . . . . . . . . . . . . . . . . . 24
       4.3.4.  Sending Redirects  . . . . . . . . . .
     A.2.  -00 to -01 . . . . . . . . 24
     4.4.  Receiving All Other IPv6 Packets from MN . . . . . . . . . 24
       4.4.1.  Authenticated Packets . . . . . . . 23
   Authors' Addresses . . . . . . . . . 24
       4.4.2.  Unauthenticated Packets . . . . . . . . . . . . . . . 24
       4.4.3.  Forwarding Packets . . . . . . . . . . . . . . . . . . 25
     4.5.  MN Identifier
   Intellectual Property and IP addresses . . . . Copyright Statements . . . . . . . . . . 25
   5.  Multilink Subnet Considerations  . . . . . . . . . . . . . . . 26
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   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] [RFC4830] 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].
   [RFC4831].  Accordingly, a protocol for network-based localized
   mobility management (NetLMM) (NETLMM) of IPv6 nodes will be is 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 NETLMM
   working group. group [I-D.ietf-netlmm-proxymip6].  Because the NetLMM 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 mobility access router (AR.) gateway (MAG).

   Because the IPv6 MN will use a vanilla IPv6 stack, the interface
   between a MN and its AR MAG 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] [RFC2461]

   o  IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] [RFC2462]

   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]
      [RFC3041]

   o  Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna-
      protocol] (DNAv6)
      [I-D.ietf-dna-protocol]

   o  SEcure Neighbor Discovery [RFC3971]

   o  Cryptographically Generated Addresses [RFC3972]

   This document specifies describes an IP layer interface between MNs mobile nodes (MN) and ARs
   mobility access gateway (MAG) of a NetLMM network-based localized mobility
   management (NETLMM) domain.  Such an  The interface is subject to a certain number of
   threats, amongst has two functions which
   are attacks on invocated when a MN attaches and detaches from a MAG.  The
   attachment function let the mapping between MAG authenticate the MN
   Identifier identifier, does
   address(es) and IPv6 address set.  A binding enforcement mechanism
   between those two default router configuration for the MN, and inform
   the MAG about the multicast listener state of the MN.  During a
   successful execution of the detachment function, the NETLMM protocol
   is hence required to prevent malicious nodes to
   carry on various attacks like service theft or denial-of-service
   attacks. triggered between the MAG and the localized mobility anchor (LMA).
   The detachment function let the MAG detect that the MN has left so
   that it can deregister the MN at the LMA using the NETLMM protocol.

   In the absence of link-layer specific mechanisms enforcing implementing these
   functions, this binding, it is required document describe which IP protocols should be used
   to implement such mechanism at provide 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 necessary interface described in this document fulfills these two requirements
   by using the SEND public key as between the MN identifier, while being solely
   based on standard track IPv6 protocols (DNA and SEND.)

1.1. the MAG.

2.  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].

   The following terms are defined within the scope of this document:

   Mobile Node (MN)
      an IPv6 node moving in the NetLMM NETLMM domain.

   Mobility Access Router (AR) Gateway (MAG)
      a default router that connects the MN to the NetLMM NETLMM domain.

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

   Localized Mobility Anchor Point (MAP) (LMA)
      a router located in the NetLMM NETLMM domain that handles packet
      exchanges with nodes in the domain.

   Network-based Localized Mobility Management Domain (NetLMM (NETLMM domain)
      an administrative domain spanning links served by a set of MAPs LMAs
      (and their associated ARs MAGs and MNs) that provision addresses from
      the same IP subnet prefix(es).

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

1.2.  Abbreviations LMA.

   The following abbreviations are used throughout this document:

   NetLMM:

   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.

   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: An authenticated MN identifier set to the (e.g.  NAI, a SEND public key
   used by the MN for generating its CGAs.

1.3. CGAs,an IMSI or TMSI, etc.).

3.  Operating Environment

   The MN-AR NetLMM MN-MAG NETLMM interface is used between a MN and an AR MAG of a NetLMM
   NETLMM domain.  In the absence of link-layer specific mechanism, it  It allows the AR MAG and/or MN to detect network attachment,
   attachment and detachment, causing the AR MAG to use
   NLMP the NETLMM protocol
   to update routing at the MAP LMA so that the MN stays reachable when it
   roams across the NetLMM NETLMM domain.

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

         /---------------------------\
        /          Internet           \
        \                             /
         \-------+---------+-------/
         \-------+---------+---------/
                 |         |
         /-------+---------+-------\
         /--------+---------+--------\  ----
        /                             \    ^
       /          +-----+              \   |
       |          | MAP LMA |-+            |   N
       |          +-----+ |-+          |   E
       |            +-----+ |          |   T
       |              +-----+          |   L
       |        Backhaul Network       |   M
       |    +-----+       +-----+    +------+       +------+    |   M
       |- - | AR1 MAG1 | ..... | ARn MAG2 | - -|
       |    +-----+       +-----+    +------+       +------+    |   d
       |       / \  Access   / \       |   o
       |      /   \ Network /   \      |   m
       |     /     \       /     \     |   a
       |     +----+                    |   i
       |     | MN | ------->           |   n
       \     +----+ AR MAG change         /   |
        \                             /    v
         \-------------------------/
         \---------------------------/  ----

                    Figure 1: Reference Network Diagram

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

   In the absence of a link-layer specific MN-AR mechanisms to implement the
   MN-MAG interface, it is required to have a common interface defined
   at the IP layer.  Because no NetLMM NETLMM specific software support is
   assumed to be present on MNs, this interface has to rely only on
   standard tracks IPv6 protocols such as ND, DHCP, SEND, and DNA.
   Interactions of these components with NetLMM NETLMM are represented in
   Figure 2 below (note that hints received by DNA from other layers are
   omitted for clarity):

                  MN|AR

                  MN|MAG
                Interface
                    |

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

                    |

                  Figure 2: NetLMM 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|MAG
               Interface
    MN                       AR                     MAP             |             MAG                LMA
    |              |              |                  |
    |   /          |          \   |   /          \   |
    |  /|          |          |\  |  /|          |\  |
    | / +---------------------+ \ | / +----------+ \ |
    |/         MN_ATTACH         \|/     NETLMM     \|
    |\          function         /|\    protocol    /|
    | \ +---------------------+ / | \ +----------+ / |
    |  \|          |          |/  |  \|          |/  |
    |   \          |          /   |   \          /   |
    |              |              |    NS(DAD:CGA_LL)                  |  UPDATE(MNID,CGA_LL)
    |
   |----------------------->|---------------------->| bind(CGA_LL,MNID)   /          |          \   |   /          \   |
    |  /|          |          |\  |  /|          |\  |
    | / +---------------------+ \ | / +----------+ \ |
    |/        data packet        \|/  data packet   \|
    |\          traffic          /|\    traffic     /|
    | \ +---------------------+ / | \ +----------+ / |
    |  \|          |          |/  |  \|          |/  |                        |REPLY[OK](MNID,CGA_LL)
    | route(CGA_LL->AR)   \          |          /   |   \          /   |                        |<----------------------|
   |RS(CGA_LL->All_routers)
    |              |
   |----------------------->|              |                  | RA(AR->{MN,All_nodes})
    |   /          |
   |<-----------------------|          \   |   /          \   |
    |  /|          |          |\  |    NS(DAD:CGA_1)  /|          |\  |   UPDATE(MNID,CGA_1)
    |
   |----------------------->|---------------------->| bind(CGA_1,MNID) / +---------------------+ \ | / +----------+ \ | REPLY[OK](MNID,CGA_1)
    |/         MN_DETACH         \|/     NETLMM     \|
    |\          function         /|\    protocol    /|
    | 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 NETLMM MN-MAG Interface Usage Overview

4.  Interactions of NETLMM Architecture with Subnet and two Global
   Unicast CGAs using SLAAC

   As shown in Figure 3 above, when a MN using SLAAC powers on for Link Models

   Within the Internet addressing model, the
   first time, it will generate a link local address based on its public
   key (CGA_LL) as per [RFC3972], and perform DAD on subnet terms, have
   a tight relationship.  Their generally admitted definitions are
   [I-D.thaler-intarea-multilink-subnet-issues]:

      Link: a topological area of an IP network delimited by routers.

      Subnet: a topological area of an IP network that uses the same
      unsubdivided 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, prefix.

   There has recently been protocol proposals achieving multi-link
   subnets, i.e. the AR MUST generate an UPDATE ability for a subnet to span multiple links.
   However, the MAP with the
   public key as the MNID along with CGA_LL.  The MAP MUST bind consensus in the
   CGA_LL IETF has been, and remains, that one
   subnet spans only one link
   [I-D.thaler-intarea-multilink-subnet-issues].

   A straightforward approach to the MNID and establish design of NETLMM would have been to
   lay a route binding for single subnet on the CGA_LL to entire NETLMM domain.  That would ensure
   that the AR.  The MAP acknowledges MN does not see layer 3 movements since the receipt subnet would
   never change.  However, such an approach would constitute a multi-
   link subnet, and is thus not deemed acceptable.

   The following subsection will discuss what kind of the UPDATE message.

   While waiting subnet and link
   models have been chosen for the completion of DAD, the MN may generate an RS
   message as per [RFC2461] with NETLMM architecture.

4.1.  NETLMM Subnet Model

   Thus, the unspecified address as NETLMM addressing model is subject to the source
   address.  Such following two
   constraints:

   o  The subnet of a message will MN does not contain a CGA option. change when the MN changes its
      attachment point in the domain.

   o  The AR will
   respond with subnet of a multicast RA as per [RFC2461].  Alternatively, the MN
   will wait for completion does not span more than one link.

   Because of DAD and generate an RS message with its
   CGA-LL as the source address.  With first constraint, the prefix information received subnet of a MN must be valid
   wherever in the RA message, domain the MN can cryptographically generate one or attaches to.  However, because of the
   second constraint, the subnet cannot be valid at more
   global addresses (CGA_*).  For each than one such
   attachment points.  Thus, the subnet of these addresses, the MN will
   perform DAD as has to follow the
   movements of the IID MN.  This addressing model is likely to be different for each denoted "per-MN subnet
   model", and satisfies constraints of these
   cryptographically generated addresses.  For every NS(DAD) received
   from both the MN, Internet and NETLMM
   architectures:

      A unique prefix MUST be assigned by the AR will generate an UPDATE message NETLMM fabric to each of
      the MAP
   establishing binding MN in the MAP. domain.  The use MAG MUST NOT configure a global unicast
      address based on this prefix.

4.2.  NETLMM Link Model

   The choice of multicast RAs may however not be acceptable in all NetLMM
   domains, e.g., when multiple MAPs and/or prefixes are used.  In that
   case, the network has to somehow force the MN to source RSs from its
   CGA-LL, so that per-MN addressing model is however conflicting with
   the AR can send to that CGA-LL use of a unicast RA
   containing shared link layer (e.g.  Ethernet, 802.11) as a last hop
   of the appropriate prefix information.  This can be achieved
   by having NETLMM domain.

   In the AR simply discard any RS sourced from per-MN subnet model, two MNs always have different subnets.
   Hence, even though they might be attached to the unspecified
   address, so same shared link
   layer, they will never communicate directly with global addresses.
   That happens since on-link determination will always conclude that eventually the MN
   they are attached to different link because it is based on subnet
   comparisons.

   They will complete DAD for its CGA-LL however be able to communicate directly with link-local
   addresses.  This is not problematic since link-local addresses are
   confined to one link and start therefore it does not introduce multi-link
   subnet issues.

   There is however one problem that arises due to the use it of Solicited-
   Node and All-Nodes multicast IPv6 addresses [RFC4291] as a source
   destination address while retransmitting RSs.

2.1.2.  DHCP 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) |                       |
   |----------------------->|                       |
   | RA(AR->{MN,All_nodes}) |                       |
   |<-----------------------|                       |
   |                        |                       |
   |  DHCP SOLICIT(CGA_*)   |   UPDATE(MNID,CGA_*)  |
   |----------------------->|---------------------->| bind(CGA_1,MNID)
   |  DHCP REPLY(STATUS)    | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR)
   |<-----------------------|<----------------------| route(CGA_2->AR)
   |                        |                       |

   Figure 4: for sending unsolicited Neighbor Advertisement
   (NA) messages [RFC2461].  When one MN powers sends such message, it can be
   received by other MNs on and configures the same link which will, as a Link-Local and two Global
   Unicast CGAs using DHCP with two-message exchange
   As shown in Figure 4 above, when result,
   create a MN using DHCP powers on neighbor cache entry for the
   first time it will cryptographically generate a CGA_LL and perform an
   RS/RA exchange as specified for sender of the SLAAC method in Section 2.1.1.

   The MN will then use its public key to generate a DHCP Unique
   Identifier (DUID) and Identity Association (IA) per ([RFC3315],
   Sections 9 and 10). NA.  If prefix information is included in the RA
   message, the MN can next cryptographically generate NA
   contained as a target address one or more
   global addresses (CGA_*).  (The MN can additionally request
   delegation of prefixes per [RFC3633].)  The MN will then issue a DHCP
   SOLICIT message 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 MN's global unicast address,
   the network to delegate non-CGA addresses.)
   If a two-message exchange receiver is preferred, the MN will also include a
   Rapid Commit option in the 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 then in Section 2.1.1, and returns a
   DHCP REPLY message with an appropriate status code position to the MN.

   The issues involved communicate directly with the use of multicast RAs as described in
   Section 2.1.1 might be valid when DHCP is used for address
   configuration.

2.2.  First attachment of 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 NetLMM domain and configures a 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 first time, it will initiate link change detection as
   specified in [I-D.pentland-dna-protocol] by multicast transmission of
   an RS message.  When the MN receives an RA message in response, it
   will figure out that this
   global unicast address, even though it has changed to does not share a link in common subnet
   prefix (they are per-MN subnet prefixes).  This is not a new NetLMM domain problem as defined by the DNA specification [I-D.pentland-dna-protocol].
   Once the MN realizes it has changed to a new NetLMM domain, it will
   discard its current IP addresses and will execute DAD for its link-
   local address and new global addresses based
   long as these two MNs remain attached on the prefix
   information in the 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                     AR                      MAP
   |                       |                       |
   |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_LL)      |                       |
   |---------------------->|                       |
   |                       |                       |
   |  DHCP SOLICIT(CGA_*)  |   UPDATE(MNID,CGA_*)  |
   |---------------------->|---------------------->| bind(CGA_1,MNID)
   |  DHCP REPLY(STATUS)   | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR)
   |<----------------------|<----------------------| route(CGA_2->AR)
   |                       |                       |

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

   As shown in Figure 6 above, when a MN using DHCP 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
   an RS message.  When the MN receives 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]
   and/or by sending a DHCP CONFIRM message as specified in
   Section 2.3.2.  Once the MN realizes it has changed 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/
   prefixes using DHCP.

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

2.3.  MN handovers in a NetLMM-domain

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

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

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

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

   Figure 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 figures out that it has changed
   link, it sends a DHCP CONFIRM message containing its IA and all of
   the CGAs/prefixes it has previously registered per ([RFC3315],
   Section 18.1.2).  The AR will generate an UPDATE message to the MAP
   and will send a DHCP REPLY message to the MN 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->AR)
   |                        |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR)
   |                        |          CGA_1,CGA_2) | route(CGA_2->AR)
   |                        |<----------------------|
   |                        |                       |

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

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

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

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

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

2.4.  MN configuring additional CGAs/prefixes

   If the MN chooses to configure new global addresses/prefixes at any
   point in time, it will contact the AR to configure the new addresses/
   prefixes as specified in Section 2.1.

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

2.5.1.  MN using SLAAC configuring colliding CGA

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

   Figure 12: MN using SLAAC configuring a colliding CGA
   As shown in Figure 12, AR1 learns about new global addresses
   configured by an MN MN1 from the NS(DAD) message sent by MN1.  When
   AR1 sends an UPDATE to the MAP based on this 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 same
   CGA with a different MNID, it will 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 a signed NA from MN2.  AR2 will then
   forward this signed NA to AR1 via the MAP.  At that point, AR1 can
   securely defend the duplicate address on behalf of MN2 by sending to
   MN1 the signed NA.

2.5.2.  MN using DHCP configuring colliding global CGA

   MN                       AR                     MAP
   |                        |                       |
   |  DHCP SOLICIT(CGA_*)   |  UPDATE(MNID,CGA_*)   |
   |----------------------->|---------------------->| collision(CGA_*)
   |  DHCP REPLY(status)    | REPLY[COLLIDE](CGA_*) |
   |<-----------------------|<----------------------|
   |                        |                       |

   Figure 13: MN using DHCP configuring 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, crashes or leaves the domain

   The AR SHOULD do periodic reachability testing with the MN using
   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.

   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 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 15: MN crashes, powers off or leaves the domain
   As shown in Figure 15, if the MN crashes, powers off or leaves the
   domain, the NUD will fail for all the associated addresses.  In this
   case, the AR can remove the entry for the MN from the MAP by
   initiating an UPDATE message.

3.  MN Specification

   NetLMM place few specific requirements link.  But if later
   on an one of the MN moves onto a different link, they will no longer be
   able to communicate directly and this will result in a NetLMM domain.
   However, for communication
   failure, although they were using global addresses whose reachability
   should be maintained.  This is not acceptable.

      Thus, the smooth operation of interface described in this document MUST only be used
      in deployments where the NetLMM MN-AR interface, link between the MN and the MAG is point-
      to-point.  The interface MUST behave as specified NOT be used in deployments where 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)
      link between the MN 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]

   Also, the MAG is shared and/or multi-access.
      Future specifications MAY define interfaces for MNs attached to networks that use DHCP, with shared
      and/or multi-access links.

5.  Address Collision Considerations

   As per the MN MUST support DNAv6 protocol [I-D.ietf-dna-protocol], the DHCP client message exchanges specified in:

   o  Dynamic Host Configuration Protocol for IPv6 [RFC3315]

   The MN MUST use will not
   execute again Duplicate Address Detection (DAD)[RFC2462] after a single public key to generate all of its CGAs.
   handoff in the domain.  This requirement is necessary to make it possible for the AR and MAP
   to bind together different addresses of because the MN.  That way, when a MN
   attaches to a new AR, the MAP will correctly update routing always receive
   the same subnet prefix in the RA and conclude that it did not changed
   link.  Hence there seems to be no need for all
   MN CGAs even if executing DAD again.
   However, in NETLMM the MN link did changed.  Because the link is currently using point-
   to-point the only one of those (e.g. its
   link-local CGA) to send an RS.

   With respect to new entity on the MUST support [RFC2461] and [RFC2462], link is the MAG, and SHOULD
   support [I-D.ietf-ipv6-2461bis] it is
   possible that a collision occurs between link local addresses of the
   MN and [I-D.ietf-ipv6-2462bis], the
   reason is MAG (Note that SEND avoids complication no collision are possible with global
   unicast address(es) since the "DAD once per IID"
   optimization of [RFC2462].  This is because IIDs of CGAs with
   different subnet prefixes are different (subnet prefix is used as an
   input parameter has been uniquely
   assigned to the CGA generation algorithm.)

   For NBMA links, links over which multicast is not well supported or
   for selection of specific neighbors, MNs and ARs can send packets
   addressed MN).

   One solution to the pre-defined multicast this issue would be that in a given domain, each MAG
   also defends link-local addresses specified of other MAGs in
   ([RFC4291], Section 2.7.1) the domain.  This
   would ensure that when the MN first attaches to the Layer-2 unicast address(es) NETLMM domain and
   execute DAD it is able to pro-actively detect collision that may
   happen with any MAG of one
   or more neighbors.

4.  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] domain.  Such a solution has however two
   drawbacks:

   o  Detecting Network Attachment  Each MAG needs to know link-local addresses of all other MAGs in IPv6 - Best Current Practices for
      Routers [I-D.ietf-dna-routers]
      the domain.

   o  Detecting Network Attachment  If SEND is used, each MAG also need to know private keys of all
      other MAGs since SEND requires a Neighbor Advertisement (NA)
      message defending an address to be signed with Unmodified Routers: the SEND public key
      generating the CGA link-local address.

   A Prefix
      List based approach [I-D.ietf-dna-cpl]

   o  Detecting Network Attachment much simpler solution is:

      All MAGs in IPv6 Networks [I-D.pentland-dna-
      protocol]

   o  SEcure Neighbor Discovery [RFC3971]

   o  Cryptographically Generated Addresses [RFC3972]

   Also, ARs a NETLMM domain MUST respond to DHCP client messages configure the same link-local
      address.

   When SEND is used, that means that all MAGs share a single SEND
   public-private key pair, and hence a single link-local CGA.

   Since all MAGs in a manner domain have the same link local address, if the
   MN executes DAD at his first attachment and concludes that there is
   consistent
   no collision with the DHCP relay/server messaging specified in:

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

   In addition, the AR MUST conform to link-local address of the supplementary NetLMM specific
   requirements which follow in this section.

4.1.  Promiscuous and all-multicast modes

   The AR SHOULD put its access interface (the one exposed to MNs) first MAG, a
   collision with any other MAG in
   snooping/promiscuous mode so that it can receive most of the packets
   exchanged on domain is impossible.

6.  MN_ATTACH Function

   The MN_ATTACH function is invocated by the link MN whenever it is serving.  If attaches to
   a layer 2 switch new MAG, and is present
   between constituted by the AR and MNs, following sub-functions:

   o  MAG_GET_MN_ID: It provides the port to which MAG with the AR is connected SHOULD identifier of the MN
      (MNID).  This identifier MUST be put in snooping/promiscuous mode.  At securely bound to the minimum, MN, and the AR
      corresponding binding MUST put
   its interface into a "receive all-multicast traffic" mode, and
   registers with MLDv2 [RFC3810] to all link-local solicited node
   multicast addresses be verifiable by the MAG.  This
      triggers the MAG to which a authenticate the MN registers to with MLDv2.  This
   insures that as the AR can receive NSs so that owner of this MNID.
      If authentication fails the MN_ATTACH function terminates with
      failure status, otherwise it can proxy solicited
   NAs when continues.

   o  MN_GET_ADDR_PARMS: It provides the target MN is off-link.

4.2.  Receiving ND Messages from MN with IPv6 addressing
      configuration parameters, i.e.  IPv6 subnet prefix(es) or global
      address(es).  The NetLMM specific processing of received ND Messages depends on
   whether a packet is an NS part of MAG will then register the DAD procedure, MN IPv6 subnet
      prefix(es) or any other ND
   message.  Section 4.2.1 defines address(es) with the processing rules for NSs sent as
   part LMA using the NETLMM protocol.

   o  MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6
      address of its default router (e.g. the DAD procedure.  Section 4.2.2 defines MAG).

   o  MAG_GET_MN_MCAST_GROUPS: It provides the processing
   rules for all others ND messages.

4.2.1.  Receiving DAD NSs

   If MAG with the AR receives multicast
      group(s) that the MN previously joined (while attached to a DAD NS which is secure according
      previous MAG).  This triggers the MAG to [RFC3971],
   it MUST try subscribe to register the target address
      multicast tree(s) corresponding to the group(s) joined by the MN.

   The MN_ATTACH function will typically be implemented by multiple
   protocols, some of them possibly non-IP protocols.  The following
   subsections will describe in more details the MAG_GET_MN_ID,
   MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER, and MAG_GET_MN_MCAST_GROUPS
   subfunctions, in particular what they achieve, and how.

6.1.  MAG_GET_MN_ID Sub-function

   The MAG_GET_MN_ID function provides the MAG with the MAP.  If identifier of
   the MN (MNID).  This identifier MUST be securely bound to the
   registration fails because this address is used by a different MN, and
   the AR corresponding binding MUST defend the target address be verifiable by sending a proxy NA as
   described in Section 4.3.2.

4.2.2.  Receiving All Others ND Messages

   If the AR receives any other ND message than those enumerated above, MAG [RFC4832].
   This triggers the message is secure according MAG to [RFC3971], and authenticate the source address
   of MN as the packet is not owner of this
   MNID.  If authentication fails the unspecified address, it MUST try to register
   its source address MN_ATTACH function terminates with
   failure status, otherwise it continues.

   When the MN_ATTACH functions includes a network access authentication
   protocol, such as EAP [RFC3748], the MAP.

4.3.  Sending ND Messages to MN

4.3.1.  Sending NSs

   An AR sends an NS to identifier authenticated by
   the network access authentication protocol is a valid MN in ID it
   satisfies above constraints (freshness of authentication, verifiable
   by the following cases:

   o  The AR receives from MAG).

   When the MN a SEND-protected ND message which mix of protocols implementing the MN_ATTACH does not allow the AR to verify the MN CGA ownership.  This can occur
      if include
   a network access authentication protocol, or the MN includes network access
   authentication protocol does not provide a Nonce parameter which suitable MN identifier, or
   does not correspond to guarantee fresh authentication of the Nonce sent by MN, an alternative
   authentication method based on the DNAv6 protocol
   [I-D.ietf-dna-protocol] and the AR SEND protocol [RFC3971] MUST be used
   to authenticate the MN, or if the as described below:

   MN includes      MAG      LMA
    |------>|        |      REQ1. RS(Nonce_MN,PK_MN,Signature_MN)
    |<------|        |      REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG)
    |------>|        |      REP2. NA(Nonce_MAG,PK_MN,Signature_MN)
    |<------|        |      REP1. RA(Nonce_MN,PK_MAG,Signature_MAG)

              Figure 4: DNAv6/SEND based MNID authentication

   o  In step REQ1, after attachment occurs, and upon the occurrence of
      a
      Timestamp parameter which fails because Layer 2 link-up event notification, the MN and AR clocks are
      desynchronized.

   o  The AR receives initiate self-
      authentication to the MAG by sending a RS from its link local
      address to the MN an IP packet which link-scope all-routers multicast address, as per
      Section 5.2.5 of the DNAv6 protocol [I-D.ietf-dna-protocol].
      Since this RS is not sent from the unspecified address, it
      contains the MN SEND public key (PK_MN) in a ND or DHCP
      Message before CGA option, as per
      Section 5.1.1 of the SEND protocol [RFC3971].  This public key is
      used as a MN registers ID by the IP packet's source address. MAG.

   o  The AR is performing  In step REQ2, after the MAG received from the periodic reachability test of a MN it has
      precedently registered with the MAP.  If a RS containing
      the MN is unreachable, ID (PK_MN) and the AR MUST deregister this MN with link local address, the MAP.

   In all MAG MUST
      sollicit the cases described above, link-local address of the AR MUST verify MN CGA ownership by sending a NS to the MN CGA an
      link-local address of the MN.  This NS message including contains a fresh nonce
      (Nonce_MN) as per Section 5.3.3. of the SEND protocol [RFC3971].

   o  In step REP2, after the MN CGA as received from the MAG a
   target address and NS containing a
      fresh Nonce.

4.3.2.  Sending Proxy NAs

   An AR SHOULD send a proxy NA nonce, it replies to the MAG with a NA containing the same
      fresh nonce as per Section 5.3.3 of the SEND protocol [RFC3971].
      This NA is signed with the MN performing DAD for an IP address
   which belongs to a public key (i.e. the MN which ID) as per
      Section 5.2.1 of the SEND protocol [RFC3971].  The MAG will verify
      1) that the Nonce is known to be off-link by fresh as per Section 5.3.4.1 of the AR in
   order to defend SEND
      protocol [RFC3971], and 2) that address, the signature is valid for this
      public key as specified in per Section 5.4. 5.2.2 of
   [I-D.ietf-ipv6-2462bis].

   To allow the SEND MNs to accept proxy NS sent by protocol [RFC3971].
      If these verifications succeeds, the AR, MAG has successfully
      authenticated the AR should
   follow MN as the procedure described in Figure 12.

4.3.3.  Sending RAs

   All Prefix Information options included in RAs sent by an AR SHOULD
   have owner of the "on-link" flag (L) set MN ID.

   o  In step REP1, the MAG concludes the DNAv6 protocol
      [I-D.ietf-dna-protocol] by sending to 0 (zero.) the MN a RA.  This ensures step is
      not part of the authentication of the MN and is shown here for
      completeness only.  Note that all
   packets sent by a step REP1 can happen before steps
      REQ2 or REP2.

6.2.  MN_GET_ADDR_PARMS Sub-function

   The MN_GET_ADDR_PARMS function allows the MN are sent to configure IP
   addresses.  This can be achieved via different means, including:

   o  Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the AR.

   When
      MN to configure both link local and global unicast address(es).

   o  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]:
      Allows the RAs contain no Prefix Information options, or when MN to configure global unicast address(es).  Typically
      not used to configure link local unicast address(es).

   o  IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN
   wishes
      to procure additional prefixes, configure link local unicast address(es).

   Whenever the MN can use DHCP prefix
   delegation mechanisms per [RFC3633].

4.3.4.  Sending Redirects

   An AR SHOULD NOT send attaches to a redirect message ([I-D.ietf-ipv6-2461bis],
   Section 8.2) unless it can determine that the sending node and better
   first-hop node reside on the same link and will remain on new MAG which is the same
   link.

4.4.  Receiving All Other IPv6 Packets from MN

   If domain as its
   old MAG, the AR receives any other IPv6 packet than those enumerated above
   from a MN, and MN_GET_ADDR_PARMS at the source IP address is new MAG MUST must not registered yet with change
   the
   AR, address(es) that were configured by the AR MUST initiate a reachability test with MN at the old MAG.

6.3.  MN_GET_DEFAULT_ROUTER Sub-function

   The MN_GET_DEFAULT_ROUTER function provides the MN with its default
   router.  This can be achieved via different means, including:

   o  Router Discovery as specified
   in Section 4.3.1 by the Neighbor Discovery Protocol
      [RFC2461].

   o  IP Version 6 over PPP (PPPv6) [I-D.ietf-ipv6-over-ppp-v2].

   Note that Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   [RFC3315] does not provide a default router.  Instead, Router
   Discovery has to verify be used.

6.4.  MAG_GET_MN_MCAST_GROUPS Sub-function

   The MAG acts as a multicast router for the MN CGA ownership.

4.4.1.  Authenticated Packets

   If MN.  The
   MAG_GET_MN_MCAST_GROUPS provides the AR receives any other IPv6 packet than those enumerated above,
   and MAG with the MN origin Multicast Address
   Listening state of this packet is authenticated (by another
   security mechanism such as 802.11i or IPsec) and tied by any means the newly attached MN (this state might have been
   established while attached to a previous MAG).  This triggers the public key used MAG
   to subscribe to generate the source CGA of that packet, then multicast tree(s) corresponding to the AR MAY update source(s)
   the MAP based on reception MN is listening to.

   In many system architectures, this can be achieved by having, upon
   movement of such packets.

4.4.2.  Unauthenticated Packets

   Unauthenticated IPv6 packets MUST NOT trigger any action in the
   NetLMM Domain.

4.4.3.  Forwarding Packets

   [RFC4291] states that:

      ARs MUST NOT forward any packets with Link-Local source or
      destination addresses MN, the old MAG doing context transfer to other links.

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

   This specification Multicast Address Listening state learned via MLDv2 [RFC3810]
   messages.

   When the deployment does not modify that behavior, i.e. an AR offer such context transfer, upon each
   new MN attachment the MAG MUST NOT
   forward packets sent by send a MN from or MLDv2 [RFC3810] General Query
   to a link-local the link-scope all-nodes multicast address (unicast
   or multicast).

4.5.  MN Identifier as per Section 5.1.15
   and IP addresses

   All NLMP messages generated by an AR upon reception 7.1 of triggers
   described in this document SHOULD use the SEND public key in the MNID
   field MLDv2 protocol [RFC3810].  A newly attached MN will
   then reports its Multicast Address Listening state as per Section 6.2
   of NLMP messages.  An alternative would be the MLDv2 protocol [RFC3810], thus allowing the MAG to use register to
   the appropriate multicast tree(s).

7.  MN_DETACH Function

   When a truncated
   (say 128 bits) secure hash of MN detaches from a MAG, the public key to reduce message size
   while keeping an equivalent security level.  This public key MNID is
   hence securely bound MAG has to deregister this MN with
   the set LMA.

   When the underlying link layer provides a reliable indication of IP addresses used by a MN
   having detached from 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 MAG, the NetLMM domain SHOULD
   enforce MAG MUST deregister the binding between an authenticated MN identity and with the set
   LMA upon reception of IP addresses used by the MN.  In other words such indication.

   When the network keeps
   track underlying link layer provides no reliable indication of IP addresses allocated to a specific
   MN identity.  In having detached from the
   case of DHCP address allocation, DHCP requests and replies should be
   protected by MAG, it is necessary to allow the MAG to
   detect a link-layer security context indexed by MN which silently detaches, or crashes, so that it can
   deregister the
   authenticated MN identity.

5.  Multilink Subnet Considerations

   Multilink subnet issues are analyzed in [I-D.thaler-intarea-
   multilink-subnet-issues]. as a consequence.  When each MN assigns addresses from separate IP prefixes, (e.g., per
   [I-D.thaler-autoconf-multisubnet-manets]) there such link layer are used,
   the MAG MUST periodically execute Neighbor Unreachability Detection
   as per Section 7.3 of the Neighbor Discovery Protocol [RFC2461] with
   each of the attached MN, even though it has no multilink
   subnet issues. traffic to deliver to
   the MN.

   When multiple MNs assign addresses from a shared IP prefix, multilink
   subnet issues can a MN detaches from a MAG, the MAG MUST conclude that multicast
   address listening for the MN terminates for all the sources it was
   listening to.

8.  Security Considerations

   The security considerations regarding the specified interface will 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
   evaluated in Section 4.3.3.

6. further revisions of this document.

9.  IANA Considerations

   There are no IANA considerations.

7.

10.  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, Alexandru Petrescu Petrescu, Fred Templin and
   Christian Vogt for discussion and/or comments that helped with first version
   versions of this document.

   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.

11.  References

8.1.

11.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-07 (work in progress), May 2006.

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

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

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

   [RFC3633]  Troan, O.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration H.
              Levkowetz, "Extensible Authentication Protocol (DHCP) version 6", (EAP)",
              RFC 3633,
              December 2003. 3748, June 2004.

   [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-03 (work in progress), May 2006.

   [I-D.ietf-dna-routers]
              Narayanan, S., "Detecting Network Attachment in IPv6 -
              Best Current Practices for Routers",
              draft-ietf-dna-routers-02 (work in progress), 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.,

   [I-D.ietf-dna-protocol]
              Kempf, J., "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 draft-ietf-dna-protocol-05 (work in progress),
              October 2005.

   [I-D.ietf-ipv6-2462bis]
              Thomson,
              March 2007.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", draft-ietf-ipv6-2462bis-08 "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-00 (work in progress), May 2005.

8.2.
              April 2007.

11.2.  Informative references

   [RFC3316]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
              Wiljakka, "Internet Protocol

   [I-D.ietf-ipv6-over-ppp-v2]
              Varada, S., "IP Version 6 (IPv6) for Some
              Second and Third Generation Cellular Hosts", RFC 3316,
              April 2003.

   [I-D.ietf-netlmm-nohost-ps] over PPP",
              draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
              May 2007.

   [RFC4830]  Kempf, J., "Problem Statement for Network-based Network-Based Localized
              Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work
              in progress), June 2006.

   [I-D.ietf-netlmm-nohost-req] Management (NETLMM)", RFC 4830, April 2007.

   [RFC4831]  Kempf, J., "Goals for Network-based Network-Based Localized Mobility
              Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
              (work in progress), RFC 4831, April 2006.

   [I-D.ietf-netlmm-threats]
              Kempf, J. and C. 2007.

   [RFC4832]  Vogt, C. and J. Kempf, "Security Threats to Network-based
              Localized Mobility Management",
              draft-ietf-netlmm-threats-00 (work in progress), Network-Based
              Localized Mobility Management (NETLMM)", RFC 4832,
              April 2006. 2007.

   [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.  -01 to -02

   o  revamped document structure to make it agnostic to attachment
      method (e.g. authentication, address-configuration, etc.).

   o  specified per-MN subnet prefix, and point-to-point link model.

   o  specified support for multicast.

   o  various editorial changes.

A.2.  -00 to -01

   o  added DHCP access method including DHCP prefix delegation.

   o  added new network reference diagram.

   o  added definitions for NetLMM 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." 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

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 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. IETF
   Administrative Support Activity (IASA).