[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

6lo                                                      P. Thubert, Ed.
Internet-Draft                                          E. Levy-Abegnoli
Updates: 8505 (if approved)                                Cisco Systems
Intended status: Standards Track                        January 25, 2019
Expires: July 29, 2019


                 IPv6 Neighbor Discovery Unicast Lookup
                  draft-thubert-6lo-unicast-lookup-00

Abstract

   This document updates RFC 8505 in order to enable unicast address
   lookup from a 6LoWPAN Border Router acting as an Address Registrar.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on July 29, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 1]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  References  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  New Terms . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Acronym Definitions . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Extended Neighbor Discovery Options and Messages  . . . .   7
       4.1.1.  Extending the Capability Indication Option  . . . . .   8
       4.1.2.  New Code Prefix for Address Mapping Messages  . . . .   8
       4.1.3.  New ARO Status  . . . . . . . . . . . . . . . . . . .   8
     4.2.  Address Mapping Messages  . . . . . . . . . . . . . . . .   9
     4.3.  IPv6 ND-based Address Lookup  . . . . . . . . . . . . . .  10
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  ICMP Codes  . . . . . . . . . . . . . . . . . . . . . . .  11
     7.2.  New ARO Status values . . . . . . . . . . . . . . . . . .  11
     7.3.  New 6LoWPAN Capability Bits . . . . . . . . . . . . . . .  12
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   [RFC8505] defines the Routing Registrar and extends [RFC6775] to use
   a 6LoWPAN Border Router (6LBR) as a central service for Address
   Registration and duplicate detection amongst Routing Registrars and
   possibly individual Nodes that access it directly.

   [I-D.ietf-6lo-backbone-router] introduces the Backbone Router (6BBR)
   as a Routing Registrar that performs IPv6 ND [RFC4861] [RFC4862]
   proxy operation between IPv6 Nodes on a federating Backbone Link and
   Registering Nodes attached to a LowPower Lossy Networks (LLNs) that
   register their addresses to the 6BBR.  The federated links form a
   Multilink Subnet (MLSN).

   The 6BBRs may exchange Extended Duplicate Address Messages (EDAR and
   EDAC) [RFC8505] to register the proxied addresses on behalf of the
   Registering Nodes to the 6LBR.  The Registration Ownership Verifier
   (ROVR) field in the EDAR and EDAC messages is used to correlate
   attempts to register the same address and to detect duplications.
   The ROVR can also be used as a proof-of-ownership (see



Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 2]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   [I-D.ietf-6lo-ap-nd]) to protect the Registered address against theft
   and impersonation attacks (more in [I-D.bi-savi-wlan]).  Conflicting
   registrations to different 6BBRs for the same Registered address are
   resolved using the TID field, which creates a temporal order and
   enables to recognize the freshest registration.

   With [I-D.ietf-6lo-backbone-router], the Link Layer address (LLA)
   that the 6BBR advertises for a Registered address on behalf of the
   Registered Node over the Backbone can belong to the Registering Node;
   in that case, the 6BBR acts as a Bridging Proxy and bridges the
   unicast packets.  Alternatively, the LLA can be that of the 6BBR on
   the Backbone interface, in which case the 6BBR acts as a Routing
   Proxy, that receives the unicast packets at Layer-3 and routes them.
   The 6BBR signals that LLA in a Source LLA Option (SLLAO) in the EDAR
   messages to the 6LBR, and the 6LBR responds with a Target LLA Option
   (TLLAO) that indicates the LLA associated to the current
   registration.

   It results that the 6LBR is capable of providing the LLA mapping for
   any address that was proactively registered with an SLLAO.  This
   draft defines the protocol elements and the operations to try a
   unicast lookup with the 6LBR.  This may save a reactive IPv6 ND
   Neighbor Solicitation (NS) message, which is based on multicast and
   may be problematic in extensive wireless domains (see
   [I-D.ietf-mboned-ieee802-mcast-problems]) as well as in large
   switched fabrics.

   The registration and lookup services that the 6LBR provides do not
   have to be limited to 6BBRs and are available to any node that
   supports [RFC8505] and [I-D.ietf-6lo-backbone-router] to register an
   address, and / or this specification to resolve a mapping.  The
   services are available on-link using an IPv6 NDP NS and off-link
   using a new variation of the Extended Duplicate Address messages
   called Address Mapping Messages.  The policy and security settings
   that allow the access to the 6LBR are out of scope.

2.  Terminology

2.1.  BCP 14

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.






Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 3]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


2.2.  References

   This document uses terms and concepts that are discussed in:

   o  "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6
      Stateless address Autoconfiguration" [RFC4862],

   o  Neighbor Discovery Optimization for Low-Power and Lossy Networks
      [RFC6775], as well as

   o  "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
      and "IPv6 Backbone Router" [I-D.ietf-6lo-backbone-router].

2.3.  New Terms

   This document introduces the following terminology:

   Address Mapping Request

         An ICMP message with an ICMP type of 157 (DAR) and a Code
         Prefix of 1.

   Address Mapping Confirm

         An ICMP message with an ICMP type of 158 (DAC) and a Code
         Prefix of 1.

   Address Registrar

         The Address Registrar is an abstract database that is
         maintained by the 6LBR to store the state associated with its
         registrations.

   Address Registration

         An Address Registration is an abstract state associated to one
         registration, in other words one entry in the Address
         Registrar.

2.4.  Acronym Definitions

   This document uses the following acronyms:

   6BBR: 6LoWPAN Backbone Router

   6LBR: 6LoWPAN Border Router

   6LR:  6LoWPAN Router



Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 4]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   6CIO: Capability Indication Option

   AMC:  Address Mapping Confirmation

   AMR:  Address Mapping Request

   ARO:  Address Registration Option

   DAC:  Duplicate Address Confirmation

   DAD:  Duplicate Address Detection

   DAR:  Duplicate Address Request

   EDAC: Extended Duplicate Address Confirmation

   EDAR: Extended Duplicate Address Request

   DODAG:  Destination-Oriented Directed Acyclic Graph

   LLN:  Low-Power and Lossy Network

   NA:   Neighbor Advertisement

   NCE:  Neighbor Cache Entry

   ND:   Neighbor Discovery

   NS:   Neighbor Solicitation

   ROVR: Registration Ownership Verifier

   RA:   Router Advertisement

   RS:   Router Solicitation

   TID:  Transaction ID

3.  Overview

   Figure 1 illustrates a Backbone Link that federates a collection of
   LLNs as a single IPv6 Subnet, with a number of 6BBRs providing proxy-
   ND services to their attached LLNs.

   A collection of IPv6 Nodes are present on the Backbone and use IPv6
   ND [RFC4861][RFC4862] procedures for DAD and Lookup.





Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 5]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   The LLN may be a hub-and-spoke access link such as (Low-Power) IEEE
   STD. 802.11 (Wi-Fi) [IEEEstd80211] and IEEE STD. 802.15.1 (Bluetooth)
   [IEEEstd802151], or a Mesh-Under or a Route-Over network [RFC8505].

                    |
                 +-----+               +-----+       +-----+
       (default) |     |          6LBR |     |       |     | IPv6
          Router |     |               |     |       |     | Node
                 +-----+               +-----+       +-----+
                    |  Backbone side      |             |
        ----+-------+-----------------+---+-------------+----+-----
            |                         |                      |
         +------+                 +------+                +------+
         | 6BBR |                 | 6BBR |                | 6BBR |
         |      |                 |      |                |      |
         +------+                 +------+                +------+
            o     Wireless side   o   o  o                  o o
        o o   o  o            o o   o  o  o             o  o  o  o o
       o  o o  o o            o   o  o  o  o            o  o  o o o
       o   o  o  o               o    o  o               o  o   o
         o   o o                    o  o                     o o

         LLN                        LLN                      LLN

                     Figure 1: Backbone Link and 6LBR

   A 6LBR provides registration services for the purpose of proactive
   IPv6 ND and maintains a registry of the active registrations as an
   abstract data structure called an Address Registrar.  An entry in the
   Address Registrar is called an "Address Registration".

   The Address Registration retains:

   o  the value for the ROVR associated to the registration, the current
      value of the TID, and the remaining Lifetime.

   o  a list of LLAs that are associated with the IPv6 address and can
      be used in a TLLAO as a response to a lookup.

   Examples where more than one address may be available include the
   case of an anycast address and the case of an LLN address that is
   proxied by more than one 6BBR.

   Unless otherwise configured, a 6LBR does the following:

   o  The 6LBR maintains an entry in the Address Registrar for any type
      of unicast and anycast addresses including those with link-local
      scope.



Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 6]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   o  Based on that entry, it provides duplicate avoidance services
      within the scope of its Address Registrar.

   o  The 6LBR also provides address lookup services for the Registered
      Address using unicast ICMPv6 DAR and DAC-based Address Mapping
      messages.

   The Address Mapping messages can be exchanged using global unicast
   addresses as source and destination addresses, so they can be used
   for both on-link and off-link queries.  NS and NA messages may also
   be used, but in that case the unicast source and destination
   addresses are link-local addresses and the 6LBR must be on-link.

   The 6LBR proactive operations may coexist on the Backbone with
   reactive IPv6 ND [RFC4861][RFC4862] that rely on multicast for
   Duplicate Address Detection (DAD) and Address Lookup.  Nodes that
   support this specification operate with the 6LBR before attempting
   the reactive operation, which may be avoided if the 6LBR is
   conclusive, either detecting a duplication or returning a mapping.

4.  Updating RFC 8505

   This specification leverages the capability to insert IPv6 ND options
   in the EDAR and EDAC messages that was introduced in
   [I-D.ietf-6lo-backbone-router].

   It extends DAR and DAR ICMP messages for address lookup in
   Section 4.1.2 that use the same ICMP types as EDAR and EDAC but a
   different Code Prefix.

   It also adds a new Status "Not Found" in Section 4.1.3) that
   indicates that the address being searched is not present in the
   Address Registrar.

   A 6LBR signals itself by setting the "B" bit in the 6CIO of the RA
   messages that it generates [RFC8505].  This specification adds a new
   "A" bit in the 6CIO to indicate support of address mapping (see
   Section 4.1.1).

4.1.  Extended Neighbor Discovery Options and Messages

   This specification does not introduce new options; it modifies
   existing options and updates the associated behaviors.








Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 7]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


4.1.1.  Extending the Capability Indication Option

   This specification defines a new capability bit for use in the 6CIO,
   as defined by [RFC7400] and extended in[RFC8505] for use in IPv6 ND
   messages.

   The new "A" bit indicates that the 6LBR provides address mapping
   services per this specification.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length = 1  |     Reserved    |A|D|L|B|P|E|G|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: New Capability Bits in the 6CIO

   Option Fields:

   Type:  36

   A: The 6LBR provides address mapping services.

4.1.2.  New Code Prefix for Address Mapping Messages

   The Extended Duplicate Address messages share a common base format
   defined in section 4.2 of [RFC8505], with the ICMP type respectively
   set to 157 and 158 that is inherited from the DAR and DAC messages
   defined in section 4.4 of [RFC6775].  The ICMP Code is split in two
   4-bit fields, the Code Prefix and the Code Suffix, and the only Code
   Prefix defined in [RFC8505] is 0, signaling a DAD.

   The Address Mapping messages use the same values for the ICMP Type as
   the corresponding Extended Duplicate Address messages.  This
   specification adds the Code Prefix of 1 to signal Address Mapping.
   ICMP messages with the ICMP type set to 157 or 158, and a Code Prefix
   of 1 are thus respectively an Address Mapping Request (AMR) and an
   Address Mapping Confirm (AMC).

4.1.3.  New ARO Status

   The Extended Address Registration Option (EARO) is defined in section
   4.1 of [RFC8505].  It contains a Status field that is common with
   with the EDAR and EDAC messages defined in section 4.2 of [RFC8505].




Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 8]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   This specification defines a new Status "Not Found" as indicated in
   Table 1

   +-------+-----------------------------------------------------------+
   | Value | Description                                               |
   +-------+-----------------------------------------------------------+
   | 0..10 | As defined in [RFC6775] and [RFC8505].                    |
   |   11  | Not Found: The address is not present in the Address      |
   |       | Registrar (value to be confirmed by IANA)                 |
   +-------+-----------------------------------------------------------+

                           Table 1: EARO Status

   The Status of "Not Found" can be used in an NA(EARO) and in an AMC
   messages as a response to an address lookup operation.

4.2.  Address Mapping Messages

   A 6LBR signals that support by setting the "B" bit in the 6CIO of the
   RA messages that it generates.  A 6LBR that supports this
   specification MUST also set the "A" bit, indicating support of the
   Address Mapping messages for address lookup.

   In the Address Mapping flow, the querier IPv6 Node uses an AMR
   message, which is characterized by an ICMPv6 Type of 157 and a Code
   Prefix of 1.  When used on-link, the AMR message SHOULD carry a SLLAO
   indicating the LLA of the querier.  The Code Suffix MUST be set to 0
   indicating a ROVR Length of 64 bits.  The ROVR, TID and Lifetime
   fields MUST be set to 0 and ignored by the receiver.

   The 6LBR MUST respond with an AMC message, which is characterized by
   an ICMPv6 Type of 158 and a Code Prefix of 1.

   o  If the address is not present in the Address Registrar then the
      6LBR MUST set the status to "Not Found".  The Code Suffix MUST be
      set to 0 indicating a ROVR Length of 64 bits.  The ROVR, TID and
      Lifetime fields MUST be set to 0 and ignored by the receiver.

   o  Else if the address is present in the Address Registrar then the
      AMC fields MUST be set from the ROVR, TID and remaining Lifetime
      values in the Address Registration and the Status MUST be set to
      0.

   o  If at least one LLA is found in the Address Registration, then the
      6LBR MUST place one in a TLLAO option in the AMC message.

   The AMC is sent unicast the 6LBR to the querier.




Thubert & Levy-Abegnoli   Expires July 29, 2019                 [Page 9]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


4.3.  IPv6 ND-based Address Lookup

   A 6LBR that is deployed on-link SHOULD provide NS/NA-based services.
   It signals that support by setting the "L" bit in the 6CIO of the RA
   messages that it generates, indicating that it is a 6LR [RFC8505].

   A 6LBR thus typically sets the "A", the "B", and the "L" bits when
   attached to a Backbone Link that it serves, as illustrated in
   Figure 1.  In that case, the IPv6 Nodes and 6BBRs can use an NS/NA
   exchange with the 6LBR for both duplicate detection and lookup
   services.

   The NS(Lookup) is sent unicast from link-local address of the querier
   to the link-local address of the 6LBR.  It carries a SLLAO [RFC4861]
   and it MUST NOT carry an EARO option to avoid the confusion with a
   registration.

   The 6LBR MUST respond with an NA message that contains an EARO.

   o  If the address is not present in the Address Registrar then the
      6LBR MUST set the status to "Not Found".  The ROVR, TID and
      Lifetime fields MUST be set to 0 and ignored by the receiver.

   o  Else if the address is present in the Address Registrar then the
      EARO fields MUST be set from the ROVR, TID and remaining Lifetime
      values in the Address Registration and the Status MUST be set to
      0.

   o  If at least one LLA is found in the Address Registration, then the
      6LBR MUST place one in a TLLAO option in the NA message.

   The NA is sent unicast from link-local address of the 6LBR to the
   link-local address of the querier.

5.  Backward Compatibility

6.  Security Considerations

   This specification extends [RFC8505], and the security section of
   that document also applies to this document.  In particular, the link
   layer SHOULD be sufficiently protected to prevent rogue access.

7.  IANA Considerations

      Note to RFC Editor, to be removed: please replace "This RFC"
      throughout this document by the RFC number for this specification
      once it is allocated.




Thubert & Levy-Abegnoli   Expires July 29, 2019                [Page 10]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   IANA is requested to make a number of changes under the "Internet
   Control Message Protocol version 6 (ICMPv6) Parameters" registry, as
   follows.

7.1.  ICMP Codes

   IANA is requested to create 2 new subregistries of the ICMPv6 "Code"
   Fields registry, which itself is a subregistry of the Internet
   Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP
   codes.

   The new subregistries relate to the ICMP type 157, Duplicate Address
   Request (shown in Table 2), and 158, Duplicate Address Confirmation
   (shown in Table 3), respectively.  For those two ICMP types, the ICMP
   Code field is split into 2 subfields, the "Code Prefix" and the "Code
   Prefix".  The new subregistries relate to the "Code Prefix" portion
   of the ICMP Code.  The range of "Code Prefix" is 0..15 in all cases.
   The policy is "IETF Review" or "IESG Approval" [RFC8126] for both
   subregistries.

   The new subregistries are to be initialized as follows:

        +--------------+-----------------------------+------------+
        | Code Prefix  | Meaning                     | Reference  |
        +--------------+-----------------------------+------------+
        | 0            | Duplicate Address Detection | RFC 6775   |
        | 1            | Address Mapping             | This RFC   |
        | 2...15       | Unassigned                  |            |
        +--------------+-----------------------------+------------+

         Table 2: New Code Prefixes for ICMP type 157 DAR message

        +--------------+-----------------------------+------------+
        | Code Prefix  | Meaning                     | Reference  |
        +--------------+-----------------------------+------------+
        | 0            | Duplicate Address Detection | RFC 6775   |
        | 1            | Address Mapping             | This RFC   |
        | 2...15       | Unassigned                  |            |
        +--------------+-----------------------------+------------+

         Table 3: New Code Prefixes for ICMP type 158 DAC message

7.2.  New ARO Status values

   IANA is requested to make additions to the Address Registration
   Option Status Values Registry as follows:





Thubert & Levy-Abegnoli   Expires July 29, 2019                [Page 11]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


                +-------------+--------------+-----------+
                |  ARO Status | Description  | Document  |
                +-------------+--------------+-----------+
                |      11     | Not Found    | This RFC  |
                +-------------+--------------+-----------+

                      Table 4: New ARO Status values

7.3.  New 6LoWPAN Capability Bits

   IANA is requested to make additions to the Subregistry for "6LoWPAN
   Capability Bits" as follows:

           +-----------------+---------------------+-----------+
           |  Capability Bit | Description         | Document  |
           +-----------------+---------------------+-----------+
           |        9        | AM  Support (A bit) | This RFC  |
           +-----------------+---------------------+-----------+

                   Table 5: New 6LoWPAN Capability Bits

8.  Acknowledgments

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.




Thubert & Levy-Abegnoli   Expires July 29, 2019                [Page 12]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
              2014, <https://www.rfc-editor.org/info/rfc7400>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

9.2.  Informative References

   [I-D.bi-savi-wlan]
              Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
              WLAN", draft-bi-savi-wlan-16 (work in progress), November
              2018.

   [I-D.ietf-6lo-ap-nd]
              Thubert, P., Sethi, M., Struik, R., and B. Sarikaya,
              "Address Protected Neighbor Discovery for Low-power and
              Lossy Networks", draft-ietf-6lo-ap-nd-09 (work in
              progress), December 2018.

   [I-D.ietf-6lo-backbone-router]
              Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
              Backbone Router", draft-ietf-6lo-backbone-router-10 (work
              in progress), January 2019.

   [I-D.ietf-mboned-ieee802-mcast-problems]
              Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
              Zuniga, "Multicast Considerations over IEEE 802 Wireless
              Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
              in progress), November 2018.








Thubert & Levy-Abegnoli   Expires July 29, 2019                [Page 13]


Internet-Draft   IPv6 Neighbor Discovery Unicast Lookup     January 2019


   [IEEEstd80211]
              IEEE standard for Information Technology, "IEEE Standard
              for Information technology -- Telecommunications and
              information exchange between systems Local and
              metropolitan area networks-- Specific requirements Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications".

   [IEEEstd802151]
              IEEE standard for Information Technology, "IEEE Standard
              for Information Technology - Telecommunications and
              Information Exchange Between Systems - Local and
              Metropolitan Area Networks - Specific Requirements. - Part
              15.1: Wireless Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications for Wireless Personal Area
              Networks (WPANs)".

Authors' Addresses

   Pascal Thubert (editor)
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   FRANCE

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com


   Eric Levy-Abegnoli
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   FRANCE

   Phone: +33 497 23 26 20
   Email: elevyabe@cisco.com












Thubert & Levy-Abegnoli   Expires July 29, 2019                [Page 14]


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