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

Versions: 00 01 02 03 04

Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: rfc4191 (if approved)                               J. Woodyatt
Intended status: Standards Track                                  Google
Expires: February 17, 2018                               August 16, 2017


          Route Information Options in IPv6 Neighbor Discovery
                 draft-templin-6man-rio-redirect-04.txt

Abstract

   The IPv6 Neighbor Discovery (ND) protocol allows nodes to discover
   neighbors on the same link.  Router Advertisement (RA) messages can
   also convey routing information by including 1) a non-zero (default)
   Router Lifetime, and/or 2) Route Information Options (RIOs).  This
   document specifies backward-compatible extensions that permit nodes
   to include RIOs in other IPv6 ND messages to support the discovery of
   more-specific routes.

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 http://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 February 17, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://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



Templin & Woodyatt      Expires February 17, 2018               [Page 1]


Internet-Draft              RIOs in Redirects                August 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Route Information Options (RIOs) in IPv6 Neighbor Discovery
       Messages  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  RIO Update  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  RIO Requirements  . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Classic Redirection Scenario  . . . . . . . . . . . . . .   8
     4.4.  RIO Redirection Scenario  . . . . . . . . . . . . . . . .   9
       4.4.1.  Router Specification  . . . . . . . . . . . . . . . .  10
       4.4.2.  Source Specification  . . . . . . . . . . . . . . . .  10
       4.4.3.  Target Specification  . . . . . . . . . . . . . . . .  11
     4.5.  Operation Without Redirects . . . . . . . . . . . . . . .  12
     4.6.  Multiple RIOs . . . . . . . . . . . . . . . . . . . . . .  12
     4.7.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.8.  Backward Compatibility  . . . . . . . . . . . . . . . . .  13
     4.9.  Why NS/NA?  . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Implementation Status . . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Link-layer Address Changes . . . . . . . . . . . . .  17
   Appendix B.  Interfaces with Multiple Link-Layer Addresses  . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] (IPv6 ND)
   provides a Router Solicitation (RS) function allowing nodes to
   solicit a Router Advertisement (RA) response from an on-link router,
   a Neighbor Solicitation (NS) function allowing nodes to solicit a
   Neighbor Advertisement (NA) response from an on-link neighbor, and a
   Redirect function allowing routers to inform nodes of a better next
   hop neighbor on the link toward the destination.  Further guidance
   for processing Redirect messages is given in "First-Hop Router
   Selection by Hosts in a Multi-Prefix Network" [RFC8028].

   "Default Router Preferences and More-Specific Routes" [RFC4191]
   specifies a Route Information Option (RIO) that routers can include



Templin & Woodyatt      Expires February 17, 2018               [Page 2]


Internet-Draft              RIOs in Redirects                August 2017


   in RA messages to inform recipients of more-specific routes (section
   1 of that document provides rationale for the use of RA messages
   instead of an adjunct routing protocol).  This document specifies a
   backward-compatible and incrementally-deployable extension to allow
   nodes to include RIOs in other IPv6 ND messages to support the
   dynamic discovery of more-specific routes.  This allows nodes to
   discover a better neighbor for more-specific routes to both increase
   performance and reduce the workload on default routers.

   This approach applies to any link type on which there may be many
   nodes that are holders of more-specific routes and do not act as
   default routers.  These nodes can either be routers that forward
   packets on behalf of their downstream-attached networks, or hosts
   that use a delegated prefix for their own multi-addressing purposes
   [RFC7934].

   This work benefits from the experience of [RFC6706] - an experimental
   protocol that uses UDP-based "pseudo-ND" messages instead of actual
   ICMPv6 message codes.  That experience has shown that using
   synthesized UDP messages in conjunction with the IPv6 ND messaging
   already present on the link is inefficient.  Furthermore, the UDP
   approach is neither backward-compatible nor incrementally-deployable,
   since sending UDP messages blindly to a node that does not have the
   port open can trigger excessive "Port Unreachable" messages and
   (worse) could be mis-interpreted as indications of a UDP port scan
   attack.  This specification avoids these issues by using the already-
   present and natural IPv6 ND messaging available on the link, as
   specified in this document.

2.  Terminology

   The terminology in the normative references applies.

   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].  Lower case
   uses of these words are not to be interpreted as carrying RFC2119
   significance.

3.  Motivation

   An example of a good application for RIO is the local-area subnets
   served by the routers described in "Basic Requirements for IPv6
   Customer Edge Routers" [RFC7084].  While many customer edge routers
   are capable of operating in a mode with a dynamic routing protocol
   operating in the local-area network, the default mode of operation is
   typically designed for unmanaged operation without any dynamic
   routing protocol.  On these networks, the only means for any node to



Templin & Woodyatt      Expires February 17, 2018               [Page 3]


Internet-Draft              RIOs in Redirects                August 2017


   learn about routers on the link is by using the Router Discovery
   protocol described in [RFC4861].

   Nevertheless, hosts on unmanaged home subnets may use "IPv6 Prefix
   Options for DHCPv6" [RFC3633] (DHCPv6 PD) to receive IPv6 routing
   prefixes for additional subnets allocated from the space provided by
   the service provider, and operate as routers for other links where
   hosts in delegated subnets are attached.  Hosts may even learn about
   more specific routes than the default route by processing RIOs in RA
   messages as described in [RFC4191].

   However, due to perceptions of the security considerations for hosts
   in processing RIOs on unmanaged networks, the default configuration
   for common host IPv6 implementations is to ignore RIOs.  Accordingly,
   on typical home networks the forwarding path from hosts on one subnet
   to destinations on every off-link local subnet always passes through
   the customer edge router, even when a shorter path would otherwise be
   available through an on-link router.  This adds costs for
   retransmission on shared LAN media, often adding latency and jitter
   with queuing delay and delay variability.  This is not materially
   different under the scenarios described in "IPv6 Home Networking
   Architecture Principles" [RFC7368] except that routers may use an
   interior dynamic routing protocol to coordinate sending of RIOs in RA
   messages, which as explained above, are not processed by typical
   hosts.

   In increasingly common practice, a node that receives a prefix
   delegation can use the prefix for its own multi-addressing purposes
   or can connect an entourage of "Internet of Things" back end devices
   (an approach sometimes known as "tethering" [RFC7934]).  On many link
   types, the number of such nodes may be quite large which would make
   running a dynamic routing protocol between the nodes impractical.
   Example use cases include:

   o  IETF conference, airport, and hotel WiFi networks, where large
      numbers of nodes on the link could receive IPv6 prefix
      delegations.  Using the extensions described in this document, the
      nodes could dynamically discover more-specific routes to enable
      direct neighbor-to-neighbor communications.

   o  Mobile enterprise devices that connect into a corporate network
      via VPN links.  Using the extensions described in this document,
      mobile devices could dynamically establish pair-wise VPN links
      between themselves without having to use the enterprise network as
      transit.

   o  Civil aviation networks where an aircraft holds an IPv6 prefix
      derived from the identification value assigned to it by the



Templin & Woodyatt      Expires February 17, 2018               [Page 4]


Internet-Draft              RIOs in Redirects                August 2017


      International Civil Aviation Organization (ICAO).  Using the
      extensions described in this document, direct paths between the
      aircraft and Air Traffic Control (ATC) can be established to
      provide a more direct route for communications.

   By using RIOs in IPv6 ND messages, the forwarding path between
   subnets can be shortened while accepting a much narrower opening of
   attack surfaces on general purpose hosts related to the Router
   Discovery protocol.  The basic idea is simple: hosts normally send
   packets for off-link destinations to their default router unless they
   receive ND Redirect messages designating another on-link node as the
   target.  This document allows ND Redirects additionally to suggest
   another on-link node as the target for one or more routing prefixes,
   including one with the destination.  Hosts that receive RIOs in ND
   Redirect messages then send NS messages to the target containing
   those RIOs, and process the NA messages the target sends in reply.
   If hosts only process RIOs in NA messages when they have previously
   sent them in NS messages to the targets of received ND Redirect
   messages, then hosts only process RIO at the initiative of routers
   they already accept as authoritative.

4.  Route Information Options (RIOs) in IPv6 Neighbor Discovery Messages

   The RIO is specified for inclusion in RA messages in Section 2.3 of
   [RFC4191], while the neighbor discovery functions are specified in
   [RFC4861].  This specification permits routers to include RIOs in
   other IPv6 ND messages so that recipients can discover a better next
   hop for a destination *prefix* instead of just a specific destination
   address.  This specification therefore updates [RFC4191] as discussed
   in the following sections.

4.1.  RIO Update

   The RIO format given in Section 2.3 of [RFC4191] is updated by this
   specification as shown in Figure 1:
















Templin & Woodyatt      Expires February 17, 2018               [Page 5]


Internet-Draft              RIOs in Redirects                August 2017


        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     | Prefix Length |Ver|S|Prf|Resvd|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Route Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Attributes ...
       +-+-+-+-+-+-+-+-+-+-+-+-

                       Figure 1: Updated RIO Format

   This format introduces a new Ver field, a new S flag and variable-
   length Attributes.  The fields of the main body of the RIO are set as
   follows:

   o  Type, Prefix Length, Prf, Route Lifetime and Prefix are set
      exactly as specified in Section 2.3 of [RFC4191].

   o  Length MUST be initialized to exactly 1 when Prefix Length is 0,
      to exactly 2 when Prefix Length is between 1 and 64, and to
      exactly 3 when Prefix Length is greater than 64; Length is then
      incremented by the length of all included Attributes in units of
      8-octets (see below).

   o  Ver is set to '01' to indicate that this is Version 1 of the RIO
      format ([RFC4191] is considered as the Version 0 format).

   o  S is set to '1' to "Solicit" route information or to '0' (i.e.,
      the default value) to "Assert" route information.

   o  Resvd is reserved and MUST be set to '0'.

   Attributes MAY be included as ancillary route information.  Each
   Attribute is formatted in the same manner as specified for IPv6 ND
   options in Section 4.6 of [RFC4861] and as shown in Figure 2:











Templin & Woodyatt      Expires February 17, 2018               [Page 6]


Internet-Draft              RIOs in Redirects                August 2017


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

                      Figure 2: RIO Attribute Format

   This document defines the NULL Attribute with Type '0'.  Other
   Attribute Types are assigned through IANA action.

   When Type is '0', Length MUST be set to the total number of 8-octet
   blocks in the Attribute, and the Attribute body MUST include a
   corresponding number of '0' octets.  For example, for Lengths of 1,
   2, 3, etc., the Attribute body includes 6, 14, 22, etc. '0' octets,
   respectively.

   Receivers ignore any NULL, unknown or malformed Attributes and
   continue to process any other Attributes in the RIO that follow.

4.2.  RIO Requirements

   This specification updates [RFC4191] by allowing RIOs to appear in
   any IPv6 ND messages with the following requirements:

   o  The RIOs of all IPv6 ND messages that conform to this
      specification MUST set Ver to '01'.  Any RIOs with Ver set to '00'
      in RA messages are accepted as legacy RIOs that MUST conform to
      the specification in [RFC4191].  Any RIOs in IPv6 ND messages that
      encode any other value in the Ver field MUST be silently ignored.

   o  Redirect, NA and RA messages MUST NOT include RIOs with the S flag
      set to '1'; any RIOs received in Redirect, NA and RA messages with
      S set to '1' MUST be silently ignored.

   o  NS and RS messages MAY include some RIOs with S set to '1' and
      others with S set to '0'.

   o  NA/RA responses to RIOs in NS/RS messages with S set to '1' MUST
      include RIOs with the solicited route information and with S set
      to '0'.  (If the route information solicited by the NS/RS message
      is incorrect or unrecognized, however, the RIO MUST be silently
      ignored.)

   o  Asserted route information in any RIOs received with S set to '0'
      SHOULD be considered as "unconfirmed" until the assertion can be



Templin & Woodyatt      Expires February 17, 2018               [Page 7]


Internet-Draft              RIOs in Redirects                August 2017


      verified.  Assertion verification can be through a trust anchor
      such as a trusted on-link router, through a static routing table,
      or through some other means outside the scope of this document.
      Any route information that cannot be verified SHOULD be rejected.

   The following sections present the classic redirection scenario
   illustrating an exchange where a trusted on-link router is used to
   verify RIO assertions.  Other IPv6 ND messaging scenarios that can
   employ some other means of verifying RIO assertions are also
   acceptable.

4.3.  Classic Redirection Scenario

   In the classical redirection scenario there are three actors, namely
   the Source, Router and Target as shown in Figure 3:

                         +-------------------+
                         |                   |
                         |       Router      |
                         |                   |
                         +---------+---------+
                                   |
                                   |
        X---------+----------------+---------------+---------X
                  |              Link              |
                  |                                |
        +---------+---------+           +----------+--------+
        |                   |           |                   |
        |       Source      |           |       Target      |
        |                   |           |                   |
        +-------------------+           +---------+---------+
                                                  |
                                            2001:db8::/N
                                                  |
                                        X-+----+--+-------+-X
                                          |    |          |
                                        +--+  +--+      +--+
                                        |H1|  |H2| .... |Hn|
                                        +--+  +--+      +--+

                 Figure 3: Classical Redirection Scenario

   In addition, the Target may be a router that connects an arbitrarily-
   complex set of IPv6 networks (e.g., as depicted by 2001:db8::/N in
   the figure) with hosts H(i).

   In this scenario, the Source initially has no route for 2001:db8::/N
   and must send initial packets destined to correspondents H(i) via a



Templin & Woodyatt      Expires February 17, 2018               [Page 8]


Internet-Draft              RIOs in Redirects                August 2017


   first-hop Router.  Upon receiving the packets, the Router forwards
   the packets to the Target and may also send a Redirect message back
   to the Source with the Destination Address field set to the
   destination of the packet that triggered the Redirect, the Target
   Address field set to the target link-local address and with a Target
   Link Layer Address Option (TLLAO) that includes the target link-layer
   address.  After receiving the message, the Source may begin sending
   packets destined to H(i) directly to the Target, which will then
   forward them to its connected networks.

   This specification augments the classical Redirection scenario by
   allowing the Router to include entire prefixes (e.g., 2001:db8::/N)
   in RIOs in the Redirect message, and thereafter allowing the Source
   to include RIOs in an NS message and the Target to include RIOs in
   its NA response.  The following sections present this "augmented" RIO
   redirection scenario.

4.4.  RIO Redirection Scenario

   In the RIO redirection scenario, the Source sends initial packets via
   the Router the same as in the classical scenario.  When the Router
   receives the packets, it searches its routing tables for a route that
   is assigned to the Target and that covers the destination address of
   the packet.  The Router then includes the route in an RIO in a
   Redirect message to send back to the Source.  The Router sets the S
   flag in the RIO to '0' to indicate that a prefix is being asserted.

   When the Source receives the Redirect message, it prepares an NS
   message that includes the route information received in the RIO from
   the Redirect message and with S set to '1 to indicate that route
   information is being solicited.  At the same time, if the Source
   needs to assert any route information to the Target, it includes the
   information in RIOs with S set to '0'.  The Source then sends the NS
   message to the Target.

   When the Target receives the NS message, it records any route
   information in RIOs with S set to '0' as unconfirmed route
   information for the Source pending verification.  At the same time,
   it determines whether the route information included in any RIOs with
   S set to '1' matches one of its own routes.  If so, the Target
   includes the route information in an RIO with S set to '0' to return
   in an NA message reply to the Source.

   When the Source receives the NA message it can install any RIO
   information that matches the Redirect RIOs in its routing table.  The
   following sections present more detailed specifications for the
   Router, Source and Target.




Templin & Woodyatt      Expires February 17, 2018               [Page 9]


Internet-Draft              RIOs in Redirects                August 2017


4.4.1.  Router Specification

   When the Router receives a packet from the Source it searches its
   routing table for a prefix that covers the destination address (e.g.,
   2001:db8::/N as depicted in Figure 1), where prefix could be
   populated in the routing table during DHCPv6 Prefix Delegation
   [RFC3633], via manual configuration, etc.  If the next hop for the
   prefix is on-link (i.e., a "Target" in the terms of [RFC4861]), the
   Router then prepares a Redirect message with the Destination Address
   field set to the packet's IPv6 destination address, with the Target
   Address field set to the link-local address of the Target, with a
   TLLAO set to the link-layer address of the Target, and with an RIO
   that includes route information for the prefix with Route Lifetime,
   Prf, and S set to 0.  The Router then sends the Redirect message to
   the Source (subject to rate limiting).

4.4.2.  Source Specification

   According to [RFC4861], a Source that receives a valid Redirect
   message updates its destination cache per the Destination Address and
   its neighbor cache per the Target Address.  According to [RFC4191],
   Sources can be classified as Type "A", "B" or "C" based on how they
   process RIOs, where a Type "C" Source updates its routing table per
   any RIO elements included in an RA message.  Finally, according to
   [RFC8028], a Type "C" Source operating on a Multi-Prefix Network with
   multiple default routes can make source address selection decisions
   based on information in its routing table decorated with information
   derived from the source of the RIO element.

   In light of these considerations, this document introduces a new Type
   "D" behavior for Sources with the same behavior as a Type "C" Source,
   but which also process RIO elements in other IPv6 ND messages.  Type
   "D" Sources process Redirect messages with RIO elements by first
   verifying that the Prefix in the first RIO matches the Destination
   Address.  If the Destination Address does not match the Prefix, the
   Source discards the Redirect message.  Otherwise, the Source updates
   its neighbor cache per the Target Address and its destination cache
   per the Destination Address the same as for classical redirection.
   Next, the Source MAY send an NS message to the Target containing an
   RIO with the Prefix and Prefix Length and with S set to '1' to elicit
   an NA response (at the same time, the Source MAY include RIOs with S
   set to '0' if it needs to assert any route information to the
   Target).

   When the Type 'D' Source receives the solicited NA message from the
   Target, if the NA includes an RIO with S set to '0' and with a Prefix
   corresponding to the one received in the Redirect message, the Source
   installs the route information in its routing table with the Target's



Templin & Woodyatt      Expires February 17, 2018              [Page 10]


Internet-Draft              RIOs in Redirects                August 2017


   address as the next hop.  (Note that the Prefix Length received in
   the NA message MAY be different than the Prefix Length received in
   the Redirect message.  If the Prefix Length in the NA is the same or
   longer, the Source accepts the Prefix as verified by the Router; if
   the Prefix Length is shorter, the Source considers the Prefix as
   unconfirmed.)

   After the Source installs the route information in its routing table,
   it MAY begin sending packets with destination addresses that match
   the Prefix directly to the Target Instead of sending them to the
   Router.  The Source SHOULD decrement the Route Lifetime and MAY send
   new NS messages to receive a fresh Route Lifetime (if the Route
   Lifetime decrements to 0, the Source instead deletes the route
   information from its routing table).  The Source MAY furthermore
   delete the route information at any time and again allow packets to
   flow through the Router which may send a fresh Redirect.  The Source
   SHOULD then again test the route by performing an NS/NA exchange with
   the Target the same as described above.

   After updating its routing table, the Source MAY receive an
   unsolicited NA message from the Target with an RIO with new route
   information.  If the RIO Prefix is in its routing table, and if the
   RIO Route Lifetime value is 0, the Source deletes the corresponding
   route.

   After updating its routing table, the Source MAY subsequently receive
   a Destination Unreachable message from the Target with Code '0' ("no
   route to destination").  If so, the Source again deletes the
   corresponding route information from its routing table.

4.4.3.  Target Specification

   When the Target receives an NS message from the Source containing an
   RIO with S set to '1', it examines the Prefix and Prefix Length to
   see if it matches one of the prefixes in its routing table.  If so,
   the Target prepares an NA message with an RIO including a Prefix and
   Prefix Length, any necessary route information, and with S set to
   '0'.  The Target then sends the NA message back to the Source.

   If the NS included any RIO options with S set to '0', the Target
   SHOULD employ a suitable means to verify the asserted route
   information, and SHOULD reject any route information that cannot be
   verified.

   At some later time, the Target may either alter or deprecate one of
   its routes.  If the Target has asserted route information in RIOs to
   one or more Sources, the Target SHOULD send (unsolicited) NA messages
   with RIOs that assert new route information to alter the route (where



Templin & Woodyatt      Expires February 17, 2018              [Page 11]


Internet-Draft              RIOs in Redirects                August 2017


   a new Route Lifetime value of '0' deprecates the route).  If the
   Target receives a packet with a destination addresses for which there
   is no matching route for one of its downstream-attached networks, the
   Target sends a Destination Unreachable message to the Source with
   Code '0' ("no route to destination"), subject to rate limiting.

4.5.  Operation Without Redirects

   If the Source has some way to determine the Target's link-local
   address without receiving a Redirect message from the Router, the
   Source MAY send an NS message with an RIO directly to the Target with
   S set to 1, Prefix set to the destination address of an IPv6 packet,
   Prefix Length set to 128 and all other route information is set to 0.

   When the Target receives the NS message, it prepares an NA response
   with an RIO that includes route information for one of its prefixes
   that covers the destination address.  The Target then sends the NA
   message to the Source.

   When the Source receives the NA message, it SHOULD consider the route
   information asserted in the RIO as unconfirmed until it can verify
   the Target's claim (i.e., as described in Section 4.2).

   Any node may also assert route information at any time by sending
   unsolicited IPv6 ND messages with RIOs with S set to 0.  Recipients
   of such messages SHOULD consider the route information as unconfirmed
   until the information can be verified.

4.6.  Multiple RIOs

   If a Redirect includes multiple RIOs, the Source only checks the
   destination address for a match against the Prefix in the first RIO.

   If an NS/RS message includes multiple RIOs with S set to '1', the
   neighbor only responds to those RIOs which match entries in its
   routing table.

   If an NS/NA/RS/RA message includes multiple RIOs with S set to '0',
   the neighbor considers all of the route information as unconfirmed
   until the information can be verified.

4.7.  Multicast

   Nodes MAY send IPv6 ND messages with RIOs to link-scoped multicast
   destination addresses including All Nodes, All Routers, and
   Solicited-Node multicast (see: [RFC4291].  As an example, a node
   could send unsolicited NA messages to the All Nodes multicast address




Templin & Woodyatt      Expires February 17, 2018              [Page 12]


Internet-Draft              RIOs in Redirects                August 2017


   to alter or deprecate a route it had previously asserted to one or
   more neighbors.

   Nodes MUST be conservative in their use of multicast IPv6 ND
   messaging to avoid unnecessarily disturbing other nodes on the link.

4.8.  Backward Compatibility

   [RFC4191] only allows RIOs to appear in RA messages, and requires
   that the bits corresponding to the Ver field in this specification be
   set to '00'.  In cases where legacy Type 'C' hosts may be on the
   link, implementation of this protocol SHOULD only send multicast RAs
   with RIOs formatted per [RFC4191].  RA responses to RS messages with
   RIOs formatted per this specificaiton SHOULD be sent as unicast and
   SHOULD include RIOs formatted per this specifcation.

4.9.  Why NS/NA?

   Since [RFC4191] already specifies the inclusion of RIOs in RA
   messages, a natural question is why use NS/NA instead of RS/RA?

   First, NS/NA exchanges used by the IPv6 Neighbor Unreachability
   Detection (NUD) procedure are unicast-based whereas RA responses to
   RS messages are typically sent as multicast.  Since this mechanism
   must support unicast operation, the use of unicast exchanges is
   required.

   Second, the IPv6 ND specification places restrictions on minimum
   delays between RA messages.  Since this mechanism expects an
   immediate advertisement from the Target in response to the Source's
   solicitation, only the NS/NA exchange can satisfy this property.

   Third, the RA message is the "swiss army knife" of the IPv6 ND
   protocol.  RA messages carry numerous configuration parameters for
   the link, including Cur Hop Limit, M/O flags, Router Lifetime,
   Reachable Time, Retrans Time, Prefix Information Options, MTU
   options, etc.  The Target must not advertise any of this information
   to the soliciting Source.

   Fourth, RIOs in legacy RA messages cannot encode attributes and
   therefore may be limited in the route information they can carry.

   Finally, operators are deeply concerned about the security of RA
   messages - so much so that they deploy link security mechanisms that
   drop RA messages originating from nodes claiming to be an
   authoritative router for the link [RFC6105].





Templin & Woodyatt      Expires February 17, 2018              [Page 13]


Internet-Draft              RIOs in Redirects                August 2017


5.  Implementation Status

   The IPv6 ND functions and RIOs are widely deployed in IPv6
   implementations, however these implementations do not currently
   include RIOs in IPv6 ND messages other than RAs.

   An experimental implementation of [RFC6706] exists, and demonstrates
   how the Redirect function can be used to carry route information.

6.  IANA Considerations

   IANA is instructed to create a registry for "RIO Attributes" as
   discussed in Section 4.1.  The registry includes the following
   initial entry:

      0 - the NULL Attribute [draft-templin-6man-rio-redirect]

   Other Attribute types are defined through standards action or expert
   review.

7.  Security Considerations

   The Redirect message validation rules in Section 8.1 of [RFC4861]
   require recipients to verify that the IP source address of the
   Redirect is the same as the current first-hop router for the
   specified ICMP Destination Address.  Recipients therefore naturally
   reject any Redirect message with an incorrect source address.

   Other security considerations for IPv6 ND messages that include RIOs
   are the same as specified in Section 11 of [RFC4861].  Namely, the
   protocol must take measures to secure IPv6 ND messages on links where
   spoofing attacks are possible.

   A spoofed ND message containing no RIOs could cause corruption in the
   recipient's destination cache, while a spoofed ND message containing
   RIOs could corrupt the host's routing tables.  While the latter would
   seem to be a more onerous result, the possibility for corruption is
   unacceptable in either case.

   "IPv6 ND Trust Models and Threats" [RFC3756] discusses spoofing
   attacks, and states that: "This attack is not a concern if access to
   the link is restricted to trusted nodes".  "SEcure Neighbor Discovery
   (SEND)" [RFC3971] provides one possible mitigation for other cases.
   In some scenarios, it may be sufficient to include only the Timestamp
   and Nonce options defined for SEND without implementing other aspects
   of the protocol.





Templin & Woodyatt      Expires February 17, 2018              [Page 14]


Internet-Draft              RIOs in Redirects                August 2017


   "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a
   layer-2 filtering technique intended for network operators to use in
   protecting hosts from receiving RA messages sent by nodes that are
   not among the set of routers regarded as legitimate by the network
   operator.

   Nodes must have some form of trust basis for knowing that the sender
   of an ND message is authoritative for the prefixes it asserts in
   RIOs.  For example, when an NS/NA exchange is triggered by the
   receipt of a Redirect, the soliciting node can verify that the RIOs
   in the NA message match the ones it received in the Redirect message
   (which originally came from a trusted router).

8.  Acknowledgements

   Joe Touch suggested a standalone draft to document this approach in
   discussions on the intarea list.  The work was subsequently
   transferred to the 6man list, where the following individuals
   provided valuable feedback: Mikael Abrahamsson, Zied Bouziri, Brian
   Carpenter, Steinar Haug, Christian Huitema, Tatuya Jinmei, Tomoyuki
   Sahara.

   Discussion with colleagues during the "bits-and-bites" session at
   IETF98 helped shape this document.  Those colleagues are gratefully
   acknowledged for their contributions.

   This work was sponsored through several ongoing initiatives,
   including 1) the NASA Safe Autonomous Systems Operation (SASO)
   program under NASA contract number NNA16BD84C, 2) the FAA SE2025
   contract number DTFAWA-15-D-00030, 3) the Boeing Information
   Technology (BIT) MobileNet program, and 4) the Boeing Research &
   Technology (BR&T) enterprise autonomy program.

9.  References

9.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <http://www.rfc-editor.org/info/rfc791>.

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






Templin & Woodyatt      Expires February 17, 2018              [Page 15]


Internet-Draft              RIOs in Redirects                August 2017


   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <http://www.rfc-editor.org/info/rfc4191>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <http://www.rfc-editor.org/info/rfc4443>.

   [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,
              <http://www.rfc-editor.org/info/rfc4861>.

9.2.  Informative References

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
              Neighbor Discovery (ND) Trust Models and Threats",
              RFC 3756, DOI 10.17487/RFC3756, May 2004,
              <http://www.rfc-editor.org/info/rfc3756>.

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,
              <http://www.rfc-editor.org/info/rfc3971>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
              Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
              DOI 10.17487/RFC6105, February 2011,
              <http://www.rfc-editor.org/info/rfc6105>.

   [RFC6706]  Templin, F., Ed., "Asymmetric Extended Route Optimization
              (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012,
              <http://www.rfc-editor.org/info/rfc6706>.



Templin & Woodyatt      Expires February 17, 2018              [Page 16]


Internet-Draft              RIOs in Redirects                August 2017


   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <http://www.rfc-editor.org/info/rfc7084>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <http://www.rfc-editor.org/info/rfc7368>.

   [RFC7934]  Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
              "Host Address Availability Recommendations", BCP 204,
              RFC 7934, DOI 10.17487/RFC7934, July 2016,
              <http://www.rfc-editor.org/info/rfc7934>.

   [RFC8028]  Baker, F. and B. Carpenter, "First-Hop Router Selection by
              Hosts in a Multi-Prefix Network", RFC 8028,
              DOI 10.17487/RFC8028, November 2016,
              <http://www.rfc-editor.org/info/rfc8028>.

Appendix A.  Link-layer Address Changes

   Type "D" hosts send unsolicited NAs to announce link-layer address
   changes per standard neighbor discovery [RFC4861].  Link-layer
   address changes may be due to localized factors such as hot-swap of
   an interface card, but could also occur during movement to a new
   point of attachment on the same link.

Appendix B.  Interfaces with Multiple Link-Layer Addresses

   Type "D" host interfaces may have multiple connections to the link;
   each with its own link-layer address.  Type "D" nodes can therefore
   include multiple link-layer address options in IPv6 ND messages.
   Neighbors that receive these messages can cache and select link-layer
   addresses in a manner outside the scope of this specification.

Authors' Addresses

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org






Templin & Woodyatt      Expires February 17, 2018              [Page 17]


Internet-Draft              RIOs in Redirects                August 2017


   James Woodyatt
   Google
   3400 Hillview Ave
   Palo Alto, CA  94304
   USA

   Email: jhw@google.com












































Templin & Woodyatt      Expires February 17, 2018              [Page 18]


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