DNA WG                                                          JH. Choi
Internet-Draft                                               Samsung AIT
Expires: April 16, December 23, 2006                                 DongYun. Shin
                                                     Samsung Electronics
                                                               W. Haddad
                                                       Ericsson Research
                                                        October 13, 2005
                                                           June 21, 2006

                 Fast Router Discovery with L2 support
                       draft-ietf-dna-frd-00.txt
                       draft-ietf-dna-frd-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 16, December 23, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   For efficient DNA, Detecting Network Attachment (DNA), a host should
   quickly receive an RA (Router
   Advertisement) a Router Advertisement (RA) message upon a new link-layer link-
   layer connection.  This draft presents a quick RA acquisition scheme
   with the support of a link-layer entity, PoA (Point Point of Attachment). Attachment (PoA).
   Upon a new network attachment, the PoA may either trigger an AR (Access Router) Access
   Router (AR) to immediately send an unicast RA, "RA Triggering" or
   send such an RA for itself, "RA Proxying".  We may put "RA
   Triggering" or "RA Proxying" functionality on a PoA to get the
   optimized result without IPv6 standard change.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Proposal Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1
     3.1.  RA Triggering  . . . . . . . . . . . . . . . . . . . . . .  6
     3.2
     3.2.  RA Proxying  . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  RA Triggering  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  RA Proxying  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1
     5.1.  RA Caching . . . . . . . . . . . . . . . . . . . . . . . .  9
       5.1.1
       5.1.1.  Manual Configuration . . . . . . . . . . . . . . . . .  9
       5.1.2
       5.1.2.  Scanning . . . . . . . . . . . . . . . . . . . . . . .  9
       5.1.3   MICS (Media
       5.1.3.  Media Independent Comment Service) Command Service (MICS) . . . . . . .  9
     5.2
     5.2.  RA Delivery  . . . . . . . . . . . . . . . . . . . . . . . 10
       5.2.1
       5.2.1.  802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10
       5.2.2
       5.2.2.  802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 . . 19
   Intellectual Property and Copyright Statements . . . . . . . . 19 . . 20

1.  Introduction

   Upon establishing a new link-layer connection, a host should detect
   the identity of the currently attached check
   for link change to ascertain the validity
   of the existing determine whether its IP configuration. configuration is still
   valid.  If the host is attached to a different link, it also needs to
   acquire the IP configuration for the new link [4].

   An RA (Router Advertisement) [2].

   Detecting Network Attachment (DNA) is the process by which a host
   collects the appropriate information and detects the identity of its
   currently attached link to ascertain the validity of its IP
   configuration. [2].

   A Router Advertisement (RA) message is necessary when the host has
   moved to a different link, so the number of messages needed for DNA
   can be minimized if the RA also can properly represent the link
   identity.  Moreover to quickly check for link change, the host has to
   receive the RA without delay.

   DNA solution should be able to 1) correctly check for link change
   with a single RA message and 2) quickly get a suitable RA, i.e. the RA
   RA, such as 'RA with minimum latency [5]. LinkID' or 'CompleteRA' in [4], which can
   properly indicate the link identity.  This draft presents only the
   second component, quick RA acquisition.  But the proposed method can
   work with any link identify detection identification scheme based on unsolicited RA,
   such as linkid prefix 'CPL' in [13] [3], 'LinkID prefix' or CompleteRA 'CompleteRA' in [12]. [4].

   There are several hindrances for sufficiently quick RA acquisition.
   First, Neighbor Discovery protocol [1] limits routers to a minimum
   interval of 3 seconds between sending multicast RA messages.  Second,
   it SHOULD
   a host should delay the transmission for a random amount of time before a
   host sends an initial RS (Router Solicitation)
   transmission of a Router Solicitation (RS) message.  Third, a router
   MUST delay a response to a Router Solicitation by a random amount of
   time too.

   In cellular environments, it may not be cost-effective to broadcast
   the RA over wireless link.  For DNA purpose, purposes, it's generally
   preferable to deliver the RA to the destination in unicast.

   PoA (Point

   Point of Attachment) Attachment (PoA) is the link endpoint of the link, link [7], such
   as 802.11 AP (Access Point) Access Point (AP) or 802.16 BS (Base Station). Base Station (BS).  We propose
   a scheme which uses the link-layer entity, PoA, in such a way that an
   RA is delivered to the host in unicast just after L2 connection is
   made
   established without any random delay.

   When a host makes a new link-layer connection with a PoA, the PoA
   detects the new attachment.  So at this moment, the PoA may either
   trigger an AR (Access Router) Access Router (AR) to immediately send a suitable RA or
   send such an RA for itself.  For the latter case, the PoA needs to
   cache a suitable RA, such as 'RA optimized for DNA' defined in [5] RA.

   For example, if AR and PoA are in the same box, whenever a new host
   is attached, the PoA module can deliver Link Up event notification to
   the AR module so that the AR module can immediately fire an RA.  Or,
   if AR and PoA are separated, PoA can cache a suitable RA and deliver
   it to a new host upon network attachment.

   In this draft, we design a scheme for a PoA to trigger an RA, "RA
   Triggering" and another one for a PoA to proxy an RA, "RA Proxying".
   In RA Proxying, we present a way to cache a necessary suitable RA and send the
   RA in unicast without any delay.

   IEEE 802.21 (Media Independent Handover) standard develops a
   specification [21] [13] that provides link layer intelligence and other
   related network information to upper layers to optimize handovers
   between heterogeneous media.

   Utilizing the services defined in 802.21 MIH (Media Media Independent
   Handover) Handover
   (MIH) standard, we can put 'RA Triggering' or 'RA Proxying'
   functionality on a PoA to get the optimized result for quick RA
   acquisition without IPv6 standard change.

2.  Terminology

      Access Router (AR)

      -  An Access Network Router residing on the edge of an Access
         Network and offers IP connectivity to hosts.

      Point of Attachment (PoA)

      -  The link endpoint on the link, such as 802.11 Access Point (AP)
         or 802.16 Base Station (BS), where a host may be connected.

      Link Up

      -  An event provided by the link layer that signifies a state
         change associated with the interface becoming capable of
         communicating data frames.

      Media Independent Handover Fuction (MIHF)

      -  The MIH Function provides asynchronous and synchronous services
         through well defined SAPs for lower layers and upper layers.
         The services provided include the Media Independent Event
         Service (MIES), the Media Independent Command Service (MICS),
         and the Media Independent Information Service (MIIS).

      Media Independent Handover (MIH) Protocol

      -  The Media Independent Handover protocol defines frame formats
         for exchanging messages between peer MIH Function entities.
         These messages are based on the primitives which are part of
         MIES, MICS and MIIS.  The MIHF Protocol allows peer MIH
         Function entities to interact with each other.

3.  Proposal Overview

   When a host establishes a link-layer connection, in the process, a
   link-layer entity, PoA (Point Point of Attachment), Attachment (PoA), can detect the new
   attachment and get the necessary information to deliver an unicast L2
   frame to the host, such as 802.11 MAC address or 802.16 CID
   (Connection Identifier) [19]. Connection
   Identifier (CID) [11].

   The PoA may forward the link-layer information to an AR (Access Router) Access Router
   (AR) and trigger the AR to immediately send in unicast a suitable RA, such as
   'RA optimized for DNA' defined in [5].

   Or RA.

   Alternatively, the PoA itself may cache such an RA beforehand and
   deliver the cached RA to the host in unicast as soon as the link-layer link-
   layer connection is established.

   In this draft, we refer the first scheme "RA Triggering" and the
   second "RA Proxying".

3.1

3.1.  RA Triggering

   In case PoA and AR are in the same box, when a new host is attached,
   the link-layer (PoA module) can deliver Link UP event notification [7]
   [5] to the IP layer (AR module) to generate a suitable RA and
   immediately send the RA (in an unicast L2 frame with the host's MAC
   address).

   In case PoA and AR are separated, upon a new network attachment, the
   PoA may deliver the AR the Link Up event notification to the remote AR with
   the information necessary to deliver an unicast RA.  Upon receiving
   this notification, the AR can send a suitable RA in unicast without
   delay.

   There are two ways for such a remote Link Up event notification.  We
   may use the MIES (Media Media Independent Event Service) Service (MIES) defined in IEEE
   802.21 [21] [13] or RS with TSLLAO (Tentative Source Link-Layer Address
   Option) [14].

3.2 Tentative Option [6].

3.2.  RA Proxying

   RA Proxying consists of "RA Caching" and "RA Delivery".  RA Caching
   is to get a suitable RA and store it.  RA Delivery is to immediately
   send the cached RA to a new host in unicast

   There are several ways to cache the RA in a PoA.  We  An administrator
   may manually cache the RA in the PoA or use the an RA scanning scheme.  AR (Access
   Router)s
   An Access Router (AR) periodically multicast multicasts a suitable RA, which
   goes through the PoA.  So the PoA may scan incoming L2 frames and
   cache a necessary suitable RA.  The PoA can scan L2 frames either continuously
   or periodically to update the cached RA.  Or  Alternatively, PoA and AR
   may use a special information service, such as the MICS (Media Media Independent
   Command Service) Service (MICS) defined in IEEE 802.21 [21] [13] in such a way that
   the AR can forward the PoA the information necessary to generate a
   suitable RA and permit it to
   porxy proxy the RA.

   For RA Delivery, PoA may put the cached RA into an unicast L2 frame
   with the host's MAC address (or CID for 802.16) and deliver it to the
   host in unicast immediately after link-layer connection is
   established.

4.  RA Triggering

   In case PoA and AR are in the same box, when a new host is attached,
   Link Up event notification with the information necessary to deliver
   an unicast RA, such as the host's MAC address, can be propagated
   upwards from the link-layer (PoA module) to the IP layer (AR module)
   within a local stack.  Then the IP layer (AR module) can immediately
   send a suitable RA in an unicast L2 frame with the new host's MAC
   address.

   In case PoA and AR are separated, we may use 802.21 MIES (Media Media Independent
   Event Service) [21] to Service (MIES) [13] to enable a PoA to trigger a remote AR to
   fire an immediate RA in unicast.

   MIES (Media

   Media Independent Event Service) Service (MIES) refers to the events sent from
   the lower layers to the higher layers.  Events can also be sent from
   a local MIH entity to a peer MIH entity.  Events may carry useful
   information.  For example, Link Up event can carry a new host's MAC
   address.

   When a new host is attached to a PoA, the PoA may use Link Up event
   and MIH Protocol to notify a remote AR the new attachment with the
   information necessary to deliver an unicast RA, such as the host's
   MAC address.  Then the AR can immediately send a suitable RA in an
   unicast L2 frame with the new host's MAC address.

   In some specific cases, an AR can be informed of a new attachment of
   a host even without PoA notification.

   For example, in WiMAX network [14], while establishing a new link-
   layer connection, a host performs authentication procedure and
   notifies its presence to an AR.  So even without explicit
   notification from PoA, the AR can perceive that a new host is
   attached and send a suitable RA upon completing registration.

5.  RA Proxying

   RA Proxying is used only when AR and PoA are separated.  If they are
   in the same box, we recommend to use RA Triggering instead.

5.1

5.1.  RA Caching

   We present 3 different ways to store a suitable RA in a PoA.

5.1.1

5.1.1.  Manual Configuration

   In the simplest way, we an administrator can manually configure in PoA a
   suitable RA, such as an RA with the linkid LinkID prefix in [13] or a CompleteRA
   defined in [12]. [4].  In many cases, AR and PoA are under the same
   administration and usually RA
   (Router Advertisement) Router Advertisement (RA) message doesn't
   change so often.

5.1.2

5.1.2.  Scanning

   A PoA may scan incoming L2 frame frames for a suitable RA and store it.

   First it scans L2 frame header to see whether it is a multicast
   frame.  If not, the PoA sends that frame down link and scans a the next
   L2 frame.  If so, the PoA looks IP header to check whether it
   contains a suitable RA.  If an incoming L2 frame doesn't contain a
   suitable RA, the PoA sends that frame down link and scans a next L2
   frame.  When the PoA finds a suitable RA, it stores it and sends a
   copy down link.

   A PoA can scan continuously, updating an old RA with a new RA.  Or
   Alternatively, if it costs too much for the PoA to scan every
   incoming L2 frame, we can control the scanning rate.  For example, we
   can set timer and execute scanning every T seconds.  Or we can make
   the PoA to be able to send
   RS (Router Solicitation) a Router Solicitation (RS) message.
   Periodically the PoA sends an RS and an AR will reply a suitable RA
   and the PoA caches it.  It is noted that the PoA doesn't need to have
   IP address since because it can use unspecified address as its source
   address.

   To help RA Caching, we may make it a rule recommendation that, whenever an AR
   changes its RA information, the AR advertises the new information
   several times, so that a PoA can properly update its cached RA.

5.1.3  MICS (Media

5.1.3.  Media Independent Comment Service) Command Service (MICS)

   We may use 802.21 MICS (Media Media Independent Comment Service) Command Service (MICS) and MIH
   (Media Media
   Independent Handover) Handover (MIH) Protocol [21] [13] to enable an AR to send a
   suitable RA to a PoA and delegate the PoA to proxy the RA.

   MICS (Media

   Media Independent Comment Service) Command Service (MICS) refers to the commands sent
   from the higher layers to the lower layers.  Commands can also be
   sent from a local MIH entity to a peer MIH entity.  These commands
   may carry the upper layer information to the lower layers on local
   device entity or at remote entity, and thus control the behavior of
   lower layers.  For example, a new AR may send its IP address to old
   PoA with a Remote MIH Command, "MIH Network Address Information".

   In a similar way, we may it is possible to define a new Remote MIH Command,
   "MIH Router Advertisement Information" in 802.21 in such a way that
   1) a PoA can use the command and MIP Protocol to request a suitable
   RA from an AR and permission to proxy the RA and 2) the AR can use
   the command and MIH Protocol to send a suitable RA to the PoA and
   delegate the PoA to deliver the RA to a new host upon network attachment

5.2
   attachment.  Further work is needed because this entails a change in
   802.21 standard.

5.2.  RA Delivery

   We present a way to immediately deliver an RA in unicast upon network
   attachement for 802.11 and 802.16 respectively.  The procedures
   describes
   described in here can be extended to apply to other wireless
   technologies such as 3GPP and 3GPP.2.

5.2.1

5.2.1.  802.11

   In 802.11 Wireless LAN technology, when a new host arrives at an
   AP(Access Point), it should associate with the AP.  The host sends an
   Association Request Message with its MAC address.  Then the AP sends
   an Association Response Message to grant association.

   As soon as association is made, the AP sends a cached RA to the host
   in an unicast 802.11 frame with the MAC address from the Association
   Request message.  The host receives the unicast RA just after
   association is made, which is the earliest possible time in current
   standard.

5.2.2

5.2.2.  802.16

   IEEE 802.16 spec [19] [11], [12] is rather different from Ethernet or
   802.11 and
   it's work is still unclear on-going about how to run IPv6 over 802.16.
   So we give a rough sketch of RA delivery over 802.16 and mention that
   further
   clarification work is needed.

   The 802.16 MAC is connection-oriented.  All services, including
   inherently connectionless services, are mapped to a connection.

   Connections are referenced with 16-bit connection identifiers Connection Identifiers (CIDs).

   Each 802.16 host has a standard 48-bit MAC address, but this serves
   mainly as an equipment identifier, since the primary addresses used
   during operation are the CIDs. identifier and a 802.16 frame carries only a
   CID.

   Upon entering the network, the host is assigned three management
   connections, the basic connection and the primary management
   connection and the secondary management connection.

   The secondary management connection is used for the transfer of
   standards-based management messages such as Dynamic Host
   Configuration Protocol (DHCP).  It is not decided yet but Neighbor
   Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA
   (Neighbor Advertisement) may be delivered with this connection.  If
   that's not allowed, a separate transport connection, such as Initial
   Service Flow (ISF) defined in WiMAX forum [14], can be created for
   Neighbor Discovery messages.

   To establish a link layer connection, an 802.16 host performs Ranging
   to acquire the correct timing offset and power adjustment.  The host
   sends the RNG-REQ message and the 802.16 BS (Base Station) Base Station (BS) replies
   RNG-RSP message to provide Basic and Primary Management CIDs for the
   host.

   Afterwards the host performs Registration, which is the process by
   which the host is allowed entry into the network and receives its
   Secondary Management CID.

   After Registration is completed, the 802.16 BS may send a cached RA
   to the host with the Secondary CID.  The RA will be delivered in
   unicast 802.16 frame and the host will receive it with minimum
   latency.

   We point out that it's not decided clear yet that whether the Secondary CID is can be
   used for the RA message transfer.  It's possible for RA to  In case Secondary CID can't be delivered
   used, the BS can create a transport connection such as ISF with an
   associate CID.  Afterwards the BS can send a
   different cached RA in unicast
   802.16 frame with the transport CID.

6.  IANA Considerations

   No new message formats or services are defined in this document.

7.  Security Considerations

   Because DNA is based on Neighbor Discovery, its trust models and
   threats are similar to the ones presented in RFC 3756 [10]. [9].  Nodes
   connected over wireless interfaces may be particularly susceptible to
   jamming, monitoring and packet insertion attacks.

   The threats specific to DNA are

   Note that an a DNA scheme should not result in excessive signaling.  An
   attacker might fool can make a node to
   detect attachment bogus association with an PoA to a different link when it is trigger an
   additional RA.  This may result in fact amplification attack and consumes
   wireless bandwidth.  However a PoA performs FRD procedure to generate
   an RA message only when a new host is attached to itself.  Usually
   there is an upper bound for the number of hosts (wireless stations)
   that a PoA can support at a moment.  So the number of RA messages
   from FRD procedure is also limited by this upper bound.

   The threats specific to DNA are that an attacker might fool a node to
   detect attachment to a different link when it is in fact still
   attached to the same link, and conversely, the attacker might fool a
   node to not detect attachment to a new link.

   In case PoA and AR are in the same box, there is no FRD doesn't bring forth any
   additional DNA specific security problem, because all procedures are
   executed within a local stack.  In case PoA and AR are separated, FRD
   can be performed in secure manner, manner only if there is a secure path
   between PoA and AR.  For example, MIH (Media Media Independent Handover) Handover (MIH)
   services can be made available at L2 through secure port.

   Even when there is no

   The lack of secure path between the PoA and AR, FRD doesn't AR does not introduce a new any
   additional security vulnerability.  For the worst case, a host
   may reject the proxyed RA from PoA but will not make a false
   decision. attack when using FRD.  Currently any node in a
   link can cache an RA and retransmit it. it to mislead a host to false
   decision.  But an attacker may poison a PoA's cache with a bogus RA
   to save itself from having to advertise the false information for
   itself.  Use of [9] [8] to secure Neighbor Discovery are important in
   achieving reliable detection of network attachment.  DNA schemes
   SHOULD incorporate the solutions developed in IETF SEND WG if
   available, where assessment indicates such procedures are required.

   In the presence of SEND, RA Caching may raise security concerns,
   since the PoA can be considered a man in the middle.  Especially  Especially, it
   may be difficult for RA Caching with Scanning (Sec 5.1.2) to work
   with SEND.  If a router sends an RA with a SEND Timestamp option, it
   puts upper bound on how long the RA remains valid after the router
   advertises it.  So if a PoA caches the RA too long, it will become
   invalid and a host will discard it.  However take notice that even in
   this case, the host will not make a false DNA decision.

   We may resolve this issue by including a unique 64 bit number called
   an Ownership Proof (OP) in an RA.  The 64 bit number, OP, is the hash
   of a nonce and proves to a host that the RA was indeed generated by
   the router which is listed as the source of the RA.  The router must
   keep a table associating each OP to the nonce nonce, which was used to
   generate it.  When an RA carrying an OP option is received, a host
   may ignore the SEND Timestamp option if it falls outside the
   allowable window.

   With OP, DNA procedure is as below.  A PoA caches a suitable RA
   message with an OP.  When a new host makes an attachment, the PoA immediately
   sends it immediately the cached RA message with an OP.  With this
   cached RA, RA message, the host may perform DNA regardless of its SEND
   Timestamp and at the same time send an RS message with the OP option.
   Upon receiving the RS, RS message, the access router may send an RA
   message immediately because it is solicited in unicast.  When the
   router AR
   responds with a solicited RA it includes the nonce used to generate
   the OP.  Upon receiving the RA, RA message, the host may check if the
   hash of this nonce matches the OP received in the initial cached RA
   to verify it.  If not, the host stops the DNA procedure with the RA
   and restarts it with a new RA.

   DAN scheme should not result in excessive signaling.  A PoA performs
   FRD procedures to generate an RA message only when a new host is
   attached

   In addition to itself.  Usually there is an upper bound for the number
   of hosts (wireless stations) that a PoA can support at OP procedure, a moment.  So
   the number sort of combination of the RA messages from
   triggering and proxying mechanisms may be used, in order to provide a
   secure FRD procedure is also limited by this
   upper bound.

8. without requiring any involvement from the host
   side.  Furthermore, the PoA would better avoid scanning each L2
   frame, and consequently, limit the need to refresh its cache memory
   with a new RA message as much as possible.  These requirements are
   fullfilled by having the AR generating one different one way hash
   chain (OWHC) [10] for each PoA.  In this case, each PoA needs to
   store at the beginning one RA message, i.e., the one which carries
   the tip of the corresponding OWHC.  After that, each time the PoA
   forwards the cached RA message to the MN, it sends an RS message,
   which includes the MN's MAC address in Tentative Option [6] and the
   OWHC value to the AR.  At this point, the PoA should start scanning
   incoming L2 frame from the AR for a short period of time to capture
   the AR reply.  Upon receiving the RS message from the PoA, the AR
   should send back immediately an RA message in unicast (by using the
   MN's MAC address), which discloses the correct value from the
   corresponding OWHC.  The AR should also send another multicast RA
   message (with the same disclosed value from its OWHC) to be cached by
   the PoA for future use.  In such scenario, the PoA should stop
   scanning L2 frames immediately after receiving a multicast RA
   message.

   The combination of RA triggering and proxying described above allows
   the PoA to keep the RA message, which carries the last disclosed
   value of the corresponding OWHC.  It also allows the MN to perform
   DNA with the cached RA message, autoconfigure, if needed, a new IPv6
   address and quickly pursue its ongoing session(s).  In fact, the RA
   triggering and proxying combination allows the MN to get a fresh RA
   message from the AR and validate the cached RA message almost in
   parallel with the attachment procedure.  At the same time, the
   suggested procedure eliminates the need for the PoA to refresh its
   cache memory except when a cached RA message is sent to a MN.

8.  Acknowledgment

   We gratefully acknowledge the generous assistance we received from
   Xiaoyu Liu, YounHee Han and James Kempf for notifying us the
   usability of 802.21 standard and clarifying the MIH Spec to us.  We
   show our special gratitude to HeeJin Jang, Subba Reddy and Surekha
   Biruduraju for implementing and testing FRD scheme to provide
   enlightening insights.  The authors wish to express our appreciation
   to Syam Madanapalli and Wable Ranjitsingh for valuable feedback.
   Thanks to Suresh Krishnan, Greg Daley, Brett Pentland, Nick Moore and
   YongGeun Hong for their contributions to this draft.

9.  References

9.1

9.1.  Normative References

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

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

   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

   [4]  Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
        in IPv6", RFC 4135, August 2005.

9.2

9.2.  Informative References

   [3]   Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
         list based approach", draft-ietf-dna-cpl-02 (work in progress),
         January 2006.

   [4]   Kempf, J., "Detecting Network Attachment in IPv6 Networks
         (DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
         February 2006.

   [5]   Yegin, A., "Link-layer Event Notifications for Detecting
         Network Attachments", draft-ietf-dna-link-information-03 (work
         in progress), October 2005.

   [6]   Daley, G., "Tentative Options for Link-Layer Addresses in IPv6
         Neighbour Discovery", draft-ietf-dna-tentative-00 (work in
         progress), February 2006.

   [7]   Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network
         Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.

   [8]   Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [9]   Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [10]  Haddad, W., "Secure Neighbor Discovery (SEND) Optimization and
         Adaptation for Mobility:  The OptiSEND Protocol",
         draft-haddad-mipshop-optisend-01 (work in progress),
         March 2006.

   [11]  IEEE Std 802.16-2004, "IEEE Standard for Local and
         metropolitan area networks, Part 16: Air Interface for
         Fixed Broadband Wireless Access Systems", October 2004.

   [12]  IEEE802.16e-2005, "IEEE Standard for Local and metropolitan
         area networks, Amendment for Physical and Medium Access
         Control Layers for Combined Fixed and Mobile Operation in
         Licensed Bands", 2005.

   [13]  IEEE 802.21 Working Document (Draft Standard),
         "IEEE P802.21/D01.00: Draft IEEE Standard for Local and
         Metropolitan Area Networks: Media Independent Handover
         Services," July, 2005

   [14]  WiMAX Forum Network Working Group (NWG),
         http://www.wimaxforum.org

   [15]  Choi, J. and E. Nordmark, "DNA solution framework",
         draft-ietf-dna-soln-frame-00 (work in progress), April 2005.

   [6]   Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
         list based approach", draft-ietf-dna-cpl-01 (work in progress),
         July 2005.

   [7]   Yegin, A., "Link-layer Event Notifications for Detecting
         Network Attachments", draft-ietf-dna-link-information-02 (work
         in progress), July 2005.

   [8]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [9]   Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P.
         Nikander, "SEcure Neighbor Discovery (SEND)",
         draft-ietf-send-ndopt-06 (work in progress), July 2004.

   [10]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [11]

   [16]  Pentland, B., "An Overview of Approaches to Detecting Network
         Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
         progress), February 2005.

   [12]

   [17]  Narayanan, S., "Detecting Network Attachment in IPv6 Networks
         (DNAv6)", draft-pentland-dna-protocol-01 (work in progress),
         July 2005.

   [13]

   [18]  Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier
         based approach", draft-jinchoi-dna-protocol2-01 (work in
         progress), July 2005.

   [14]  Daley, G., "Tentative Source Link-Layer Address Options for
         IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-02 (work in
         progress), July 2005.

   [15]  Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
         draft-ietf-dhc-dna-ipv4-16 (work in progress), September 2005.

   [16]

   [19]  Nordmark, E., "MIPv6: from hindsight to foresight?",
         draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
         November 2001.

   [17]  Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router
         Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
         progress), July 2004.

   [18]

   [20]  Daley, G. and J. Choi, "Movement Detection Optimization in
         Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in
         progress), May 2003.

   [19]  IEEE 802.16-2001, "IEEE Standard for Local and Metropolitan
         Area Networks - Part 16: Air Interface for Fixed Broadband
         Wireless Access Systems," Apr. 8, 2002.

   [20]  IEEE 802.16 TGe Working Document (Draft Standard), "Amendment
         for Physical and Medium Access Control Layers for Combined
         Fixed and Mobile Operation in Licensed Bands",
         IEEE 802.16e/D8, May 2005.

   [21]  IEEE 802.21 Working Document (Draft Standard),
         "IEEE P802.21/D00.01: Draft IEEE Standard for Local  Kempf, J., Khalil, M., and
         Metropolitan Area Networks: Media Independent Handover
         Services," July, 2005 B. Pentland, "IPv6 Fast Router
         Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
         progress), July 2004.

Authors' Addresses

   JinHyeock Choi
   Samsung AIT
   Communication
   Networking Technology Lab
   P.O.Box 111 Suwon 440-600
   KOREA

   Phone: +82 31 280 9233
   Email: jinchoe@samsung.com

   DongYun Shin
   Samsung Electronics
   Device Solution Group
   P.O.Box 111 Suwon 440-600
   KOREA

   Phone: +82 2 2191 4868
   Email: yun7521@samsung.com

   Wassim Haddad
   Ericsson Research
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 #2334
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   Email: Wassim.Haddad@ericsson.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2005). (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.