[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-laganier-netlmm-mn-ar-if) 00 01 02 03

Network Working Group                                        J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Intended status: Informational                              S. Narayanan
Expires: November 23, 2007                                     Panasonic
                                                            May 22, 2007


  Network-based Localized Mobility Management Interface between Mobile
                    Node and Mobility Access 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.

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

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Laganier & Narayanan    Expires November 23, 2007               [Page 1]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


Abstract

   This document describes an interface between mobile nodes (MN) and
   mobility access gateway (MAG) of a network-based localized mobility
   management (NETLMM) domain.  The interface has two functions which
   are invocated when a MN attaches and detaches from a MAG.  The
   attachment function let the MAG authenticate the MN identifier, does
   address(es) and 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 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  7
   4.  Interactions of NETLMM Architecture with Subnet and Link
       Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  NETLMM Subnet Model  . . . . . . . . . . . . . . . . . . . 10
     4.2.  NETLMM Link Model  . . . . . . . . . . . . . . . . . . . . 11
   5.  Address Collision Considerations . . . . . . . . . . . . . . . 12
   6.  MN_ATTACH Function . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 13
     6.2.  MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15
     6.3.  MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . . . . . . 15
     6.4.  MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . . . . 15
   7.  MN_DETACH Function . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Normative references . . . . . . . . . . . . . . . . . . . 21
     11.2. Informative references . . . . . . . . . . . . . . . . . . 22
   Appendix A.  Version history . . . . . . . . . . . . . . . . . . . 23
     A.1.  -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23
     A.2.  -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25









Laganier & Narayanan    Expires November 23, 2007               [Page 2]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


1.  Introduction

   It is suggested in [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
   [RFC4831].  Accordingly, a protocol for network-based localized
   mobility management (NETLMM) of IPv6 nodes is specified by the NETLMM
   working group [I-D.ietf-netlmm-proxymip6].  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 mobility access gateway (MAG).

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

   o  IPv6 Stateless Address Autoconfiguration [RFC2462]

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

   o  Privacy Extensions for Stateless Address Autoconfiguration in IPv6
      [RFC3041]

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

   o  SEcure Neighbor Discovery [RFC3971]

   o  Cryptographically Generated Addresses [RFC3972]

   This document describes an interface between mobile nodes (MN) and
   mobility access gateway (MAG) of a network-based localized mobility
   management (NETLMM) domain.  The interface has two functions which
   are invocated when a MN attaches and detaches from a MAG.  The
   attachment function let the MAG authenticate the MN identifier, does
   address(es) and 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 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 implementing these
   functions, this document describe which IP protocols should be used



Laganier & Narayanan    Expires November 23, 2007               [Page 3]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


   to provide the necessary interface between the MN and the MAG.


















































Laganier & Narayanan    Expires November 23, 2007               [Page 4]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


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

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

   Localized Mobility Anchor (LMA)
      a router located in the NETLMM domain 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 LMAs
      (and their associated MAGs and MNs) that provision addresses from
      the same IP subnet prefix(es).

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

   The following 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.



Laganier & Narayanan    Expires November 23, 2007               [Page 5]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


   DNA: Detecting Network Attachment.

   CGA: Cryptographically Generated Address.

   MNID: An authenticated MN identifier (e.g.  NAI, a SEND public key
   used by the MN for generating its CGAs,an IMSI or TMSI, etc.).













































Laganier & Narayanan    Expires November 23, 2007               [Page 6]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


3.  Operating Environment

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

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

                    Figure 1: Reference Network Diagram

   The deployment scenario is shown in Figure 1 above: Several MAGs are
   attached to an IP routing domain connected to the outside Internet
   via a LMA.  The MNs, MAGs, LMAs, and in-between routing fabric
   constitute the NETLMM domain.  Packets arriving at the LMA and
   destined to a MN are tunneled to the appropriate MAG.

   In the absence of a link-layer specific mechanisms to implement the
   MN-MAG 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 ND, DHCP, SEND, and DNA.
   Interactions of these components with NETLMM are represented in
   Figure 2 below (note that hints received by DNA from other layers are



Laganier & Narayanan    Expires November 23, 2007               [Page 7]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


   omitted for clarity):


                  MN|MAG
                Interface
                    |

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

                    |

                  Figure 2: NETLMM Component Interactions















Laganier & Narayanan    Expires November 23, 2007               [Page 8]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


                 MN|MAG
               Interface
    MN             |             MAG                LMA
    |              |              |                  |
    |   /          |          \   |   /          \   |
    |  /|          |          |\  |  /|          |\  |
    | / +---------------------+ \ | / +----------+ \ |
    |/         MN_ATTACH         \|/     NETLMM     \|
    |\          function         /|\    protocol    /|
    | \ +---------------------+ / | \ +----------+ / |
    |  \|          |          |/  |  \|          |/  |
    |   \          |          /   |   \          /   |
    |              |              |                  |
    |   /          |          \   |   /          \   |
    |  /|          |          |\  |  /|          |\  |
    | / +---------------------+ \ | / +----------+ \ |
    |/        data packet        \|/  data packet   \|
    |\          traffic          /|\    traffic     /|
    | \ +---------------------+ / | \ +----------+ / |
    |  \|          |          |/  |  \|          |/  |
    |   \          |          /   |   \          /   |
    |              |              |                  |
    |   /          |          \   |   /          \   |
    |  /|          |          |\  |  /|          |\  |
    | / +---------------------+ \ | / +----------+ \ |
    |/         MN_DETACH         \|/     NETLMM     \|
    |\          function         /|\    protocol    /|
    | \ +---------------------+ / | \ +----------+ / |
    |  \|          |          |/  |  \|          |/  |
    |   \          |          /   |   \          /   |
    |              |              |                  |

             Figure 3: NETLMM MN-MAG Interface Usage Overview


















Laganier & Narayanan    Expires November 23, 2007               [Page 9]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


4.  Interactions of NETLMM Architecture with Subnet and Link Models

   Within the Internet addressing model, the link and 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 prefix.

   There has recently been protocol proposals achieving multi-link
   subnets, i.e. the ability for a subnet to span multiple links.
   However, the consensus in the IETF has been, and remains, that one
   subnet spans only one link
   [I-D.thaler-intarea-multilink-subnet-issues].

   A straightforward approach to the design of NETLMM would have been to
   lay a single subnet on the entire NETLMM domain.  That would ensure
   that the MN does not see layer 3 movements since the 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 subnet and link
   models have been chosen for the NETLMM architecture.

4.1.  NETLMM Subnet Model

   Thus, the NETLMM addressing model is subject to the following two
   constraints:

   o  The subnet of a MN does not change when the MN changes its
      attachment point in the domain.

   o  The subnet of a MN does not span more than one link.

   Because of the first constraint, the subnet of a MN must be valid
   wherever in the domain the MN attaches to.  However, because of the
   second constraint, the subnet cannot be valid at more than one such
   attachment points.  Thus, the subnet of the MN has to follow the
   movements of the MN.  This addressing model is denoted "per-MN subnet
   model", and satisfies constraints of both the Internet and NETLMM
   architectures:

      A unique prefix MUST be assigned by the NETLMM fabric to each of
      the MN in the domain.  The MAG MUST NOT configure a global unicast
      address based on this prefix.




Laganier & Narayanan    Expires November 23, 2007              [Page 10]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


4.2.  NETLMM Link Model

   The choice of the per-MN addressing model is however conflicting with
   the use of a shared link layer (e.g.  Ethernet, 802.11) as a last hop
   of the NETLMM domain.

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

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

   There is however one problem that arises due to the use of Solicited-
   Node and All-Nodes multicast IPv6 addresses [RFC4291] as a
   destination address for sending unsolicited Neighbor Advertisement
   (NA) messages [RFC2461].  When one MN sends such message, it can be
   received by other MNs on the same link which will, as a result,
   create a neighbor cache entry for the sender of the NA.  If the NA
   contained as a target address one of the MN's global unicast address,
   the receiver is then in a position to communicate directly with this
   global unicast address, even though it does not share a common subnet
   prefix (they are per-MN subnet prefixes).  This is not a problem as
   long as these two MNs remain attached on the same link.  But if later
   on one of the MN moves onto a different link, they will no longer be
   able to communicate directly and this will result in a communication
   failure, although they were using global addresses whose reachability
   should be maintained.  This is not acceptable.

      Thus, the interface described in this document MUST only be used
      in deployments where the link between the MN and the MAG is point-
      to-point.  The interface MUST NOT be used in deployments where the
      link between the MN and the MAG is shared and/or multi-access.
      Future specifications MAY define interfaces for use with shared
      and/or multi-access links.











Laganier & Narayanan    Expires November 23, 2007              [Page 11]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


5.  Address Collision Considerations

   As per the DNAv6 protocol [I-D.ietf-dna-protocol], the MN will not
   execute again Duplicate Address Detection (DAD)[RFC2462] after a
   handoff in the domain.  This is because the MN will 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 executing DAD again.
   However, in NETLMM the link did changed.  Because the link is point-
   to-point the only new entity on the link is the MAG, and it is
   possible that a collision occurs between link local addresses of the
   MN and the MAG (Note that no collision are possible with global
   unicast address(es) since the subnet prefix has been uniquely
   assigned to the MN).

   One solution to this issue would be that in a given domain, each MAG
   also defends link-local addresses of other MAGs in the domain.  This
   would ensure that when the MN first attaches to the NETLMM domain and
   execute DAD it is able to pro-actively detect collision that may
   happen with any MAG of the domain.  Such a solution has however two
   drawbacks:

   o  Each MAG needs to know link-local addresses of all other MAGs in
      the domain.

   o  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 the SEND public key
      generating the CGA link-local address.

   A much simpler solution is:

      All MAGs in a NETLMM domain MUST 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 domain have the same link local address, if the
   MN executes DAD at his first attachment and concludes that there is
   no collision with the link-local address of the first MAG, a
   collision with any other MAG in the domain is impossible.










Laganier & Narayanan    Expires November 23, 2007              [Page 12]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


6.  MN_ATTACH Function

   The MN_ATTACH function is invocated by the MN whenever it attaches to
   a new MAG, and is constituted by the following sub-functions:

   o  MAG_GET_MN_ID: It provides the MAG with the identifier of the MN
      (MNID).  This identifier MUST be securely bound to the MN, and the
      corresponding binding MUST be verifiable by the MAG.  This
      triggers the MAG to authenticate the MN as the owner of this MNID.
      If authentication fails the MN_ATTACH function terminates with
      failure status, otherwise it continues.

   o  MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing
      configuration parameters, i.e.  IPv6 subnet prefix(es) or global
      address(es).  The MAG will then register the MN IPv6 subnet
      prefix(es) or address(es) with the 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 MAG).

   o  MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast
      group(s) that the MN previously joined (while attached to a
      previous MAG).  This triggers the MAG to subscribe to the
      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 identifier of
   the MN (MNID).  This identifier MUST be securely bound to the MN, and
   the corresponding binding MUST be verifiable by the MAG [RFC4832].
   This triggers the MAG to authenticate the MN as the owner of this
   MNID.  If authentication fails the 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 MN identifier authenticated by
   the network access authentication protocol is a valid MN ID it
   satisfies above constraints (freshness of authentication, verifiable
   by the MAG).

   When the mix of protocols implementing the MN_ATTACH does not include
   a network access authentication protocol, or the network access



Laganier & Narayanan    Expires November 23, 2007              [Page 13]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


   authentication protocol does not provide a suitable MN identifier, or
   does not guarantee fresh authentication of the MN, an alternative
   authentication method based on the DNAv6 protocol
   [I-D.ietf-dna-protocol] and the SEND protocol [RFC3971] MUST be used
   to authenticate the MN, as described below:

   MN      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 Layer 2 link-up event notification, the MN initiate self-
      authentication to the MAG by sending a RS from its link local
      address to the 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 CGA option, as per
      Section 5.1.1 of the SEND protocol [RFC3971].  This public key is
      used as a MN ID by the MAG.

   o  In step REQ2, after the MAG received from the MN a RS containing
      the MN ID (PK_MN) and the MN link local address, the MAG MUST
      sollicit the link-local address of the MN by sending a NS to the
      link-local address of the MN.  This NS contains a fresh nonce
      (Nonce_MN) as per Section 5.3.3. of the SEND protocol [RFC3971].

   o  In step REP2, after the MN received from the MAG a NS containing a
      fresh 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 public key (i.e. the MN ID) as per
      Section 5.2.1 of the SEND protocol [RFC3971].  The MAG will verify
      1) that the Nonce is fresh as per Section 5.3.4.1 of the SEND
      protocol [RFC3971], and 2) that the signature is valid for this
      public key as per Section 5.2.2 of the SEND protocol [RFC3971].
      If these verifications succeeds, the MAG has successfully
      authenticated the MN as the owner of the MN ID.

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





Laganier & Narayanan    Expires November 23, 2007              [Page 14]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


6.2.  MN_GET_ADDR_PARMS Sub-function

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

   o  Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the
      MN to configure both link local and global unicast address(es).

   o  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]:
      Allows the 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
      to configure link local unicast address(es).

   Whenever the MN attaches to a new MAG which is the same domain as its
   old MAG, the MN_GET_ADDR_PARMS at the new MAG MUST must not change
   the address(es) that were configured by the 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 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 be used.

6.4.  MAG_GET_MN_MCAST_GROUPS Sub-function

   The MAG acts as a multicast router for the MN.  The
   MAG_GET_MN_MCAST_GROUPS provides the MAG with the Multicast Address
   Listening state of the newly attached MN (this state might have been
   established while attached to a previous MAG).  This triggers the MAG
   to subscribe to the multicast tree(s) corresponding to the source(s)
   the MN is listening to.

   In many system architectures, this can be achieved by having, upon
   movement of the MN, the old MAG doing context transfer to the new MAG
   of the Multicast Address Listening state learned via MLDv2 [RFC3810]
   messages.

   When the deployment does not offer such context transfer, upon each



Laganier & Narayanan    Expires November 23, 2007              [Page 15]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


   new MN attachment the MAG MUST send a MLDv2 [RFC3810] General Query
   to the link-scope all-nodes multicast address as per Section 5.1.15
   and 7.1 of the MLDv2 protocol [RFC3810].  A newly attached MN will
   then reports its Multicast Address Listening state as per Section 6.2
   of the MLDv2 protocol [RFC3810], thus allowing the MAG to register to
   the appropriate multicast tree(s).













































Laganier & Narayanan    Expires November 23, 2007              [Page 16]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


7.  MN_DETACH Function

   When a MN detaches from a MAG, the MAG has to deregister this MN with
   the LMA.

   When the underlying link layer provides a reliable indication of a MN
   having detached from the MAG, the MAG MUST deregister the MN with the
   LMA upon reception of such indication.

   When the underlying link layer provides no reliable indication of a
   MN having detached from the MAG, it is necessary to allow the MAG to
   detect a MN which silently detaches, or crashes, so that it can
   deregister the MN as a consequence.  When 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 traffic to deliver to
   the MN.

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






























Laganier & Narayanan    Expires November 23, 2007              [Page 17]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


8.  Security Considerations

   The security considerations regarding the specified interface will be
   evaluated in further revisions of this document.















































Laganier & Narayanan    Expires November 23, 2007              [Page 18]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


9.  IANA Considerations

   There are no IANA considerations.
















































Laganier & Narayanan    Expires November 23, 2007              [Page 19]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


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

   Ian Chakeres contributed the reference network diagram.

   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.


































Laganier & Narayanan    Expires November 23, 2007              [Page 20]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


11.  References

11.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

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

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 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-dna-protocol]
              Kempf, J., "Detecting Network Attachment in IPv6 Networks
              (DNAv6)", draft-ietf-dna-protocol-05 (work in progress),
              March 2007.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-00 (work in progress),
              April 2007.




Laganier & Narayanan    Expires November 23, 2007              [Page 21]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


11.2.  Informative references

   [I-D.ietf-ipv6-over-ppp-v2]
              Varada, S., "IP Version 6 over PPP",
              draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
              May 2007.

   [RFC4830]  Kempf, J., "Problem Statement for Network-Based Localized
              Mobility Management (NETLMM)", RFC 4830, April 2007.

   [RFC4831]  Kempf, J., "Goals for Network-Based Localized Mobility
              Management (NETLMM)", RFC 4831, April 2007.

   [RFC4832]  Vogt, C. and J. Kempf, "Security Threats to Network-Based
              Localized Mobility Management (NETLMM)", RFC 4832,
              April 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.






























Laganier & Narayanan    Expires November 23, 2007              [Page 22]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


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




















Laganier & Narayanan    Expires November 23, 2007              [Page 23]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


Authors' Addresses

   Julien Laganier
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687
   Germany

   Phone: +49 89 56824 231
   Email: julien.ietf@laposte.net
   URI:   http://www.docomolab-euro.com/


   Sathya Narayanan
   Panasonic Digital Networking Lab
   Two Research Way, 3rd Floor
   Princeton, NJ  08536
   USA

   Phone: +1 609 734 7599
   Email: sathya@research.panasonic.com






























Laganier & Narayanan    Expires November 23, 2007              [Page 24]


Internet-Draft           NETLMM MN-MAG Interface                May 2007


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

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Laganier & Narayanan    Expires November 23, 2007              [Page 25]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/