RE: Route Information Options in Redirect Messages (updated)

["Templin, Fred L" <[e-mail]>]

Jinmei-san,

Thank you for these comments. See below for follow-up:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
> Sent: Wednesday, February 01, 2017 1:30 PM
> To: Templin, Fred L <[e-mail]>
> Cc: IPv6 List <[e-mail]>; james woodyatt <[e-mail]>
> Subject: Re: Route Information Options in Redirect Messages (updated)
> 
> At Tue, 31 Jan 2017 23:14:59 +0000,
> "Templin, Fred L" <[e-mail]> wrote:
> 
> > An updated version of "Route Information Options in Redirect Messages" is now
> > available (see below). This version addresses 6man list comments posted in the
> > 1/9/2017 - 1/12/2017 timeframe, and re-aligns the work from intarea to 6man.
> > It also expands on several aspects of the proposal that were not covered in the
> > intarea draft. Please (re-)review and post comments to the list.
> 
> I've read the 01 version.  Here are my comments.
> 
> - general
> 
>   I'd like to understand why we need this extension.  And I'd like
>   this document to explain it.  At least from the current content of
>   the draft it's not clear to me.

Perhaps this could be addressed through the addition of a "motivation"
section. Here is a first-pass proposal:

"3.  Motivation

   One common usage scenario for RIOs is the LAN segment on residential
   networks with a single default gateway that conforms minimally to
   "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084], where
   hosts that receive DHCP prefix delegations (PD) can elect to add
   routing capability to provide hosts on the LAN segment with
   reachability to addresses numbered from the delegated prefix.

   Because common host operating systems do not, in their default
   configuration, accept RIOs in RA messages per the Type "C" behavior
   defined in [RFC4191], packets sent by such hosts to destinations on
   delegated prefixes are always forwarded via the customer edge router.
   This adds costs for retransmission on the shared LAN segment, usually
   also adding latency and jitter with queuing delay and delay
   variability.  This scenario is not materially different under the
   usage scenarios described in "IPv6 Home Networking Architecture
   Principles" [RFC7368] except that the use of an interior dynamic
   routing protocol allows for routers to coordinate when and how to
   send RIOs to hosts on home network links.

   On other link types, nodes that receive prefix delegations may
   connect an entourage of "Internet of Things" backend devices.  The
   node may therefore appear as a router from the perspective of the
   backend devices but behave as a host on the link from the perspective
   of receiving Redirects and without participating in a dynamic routing
   protocol.  Instead, the node sends initial packets with a source
   address taken from one of the node's delegated prefixes via a default
   or more-specific route with a router on the link as the next-hop.

   The router may return a Redirect message with RIOs if there is
   another node on the link that would be a better next-hop for the
   destination.  This better next-hop may itself be a holder of prefix
   delegations that behaves in a similar fashion as the source node.
   Examples of where such relationships apply include peer-to-peer
   communications in civil aviation networks, unmanned aerial vehicle
   networks and enterprise networks that host mobile user devices (e.g.,
   cell phones, tablets, laptops, etc.)."

> - Section 1
> 
>    "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861][RFC2460]
>    provides a Redirect function allowing routers to inform recipients of
>    a better next hop on the link toward the destination.
> 
>   A minor point, but I don't understand why [RFC2460] is referenced
>   here.  I actually don't see the need for it in this context.

We will remove this citation.

> - Section 3.2
> 
>    These Redirect messages may
>    be either "solicited" (i.e., an ordinary Redirect) or "unsolicited"
>    (i.e., a Redirect generated without waiting for a packet to arrive).
> 
>   If I understand RFC4861 correctly, the concept of "unsolicited
>   redirect" (whether it contains RIO or not) didn't originally exist
>   and is a new update in this document.  Am I right?

RFC4861 is silent on whether Redirects are only sent in response to
data packet arrivals, or if they may be sent independently of any data
packet arrivals. We therefore assume that both options are permissible,
and we are providing a clarifying update that names the concept and
provides additional clarifying requirements

>   If so, I think
>   it should clearly state this update in addition to the allowance of
>   the use of RIO in redirects somewhere (probably in Section 1).  And,
>   perhaps more important, I don't understand why this concept has been
>   introduced.  Some background motivation/justification would be
>   helpful.

We want to clarify how a target router uses "unsolicited" Redirect
messages to update or cancel a redirection on its own initiative, i.e.,
without having to wait for packet reception. For example, the redirection
target may wish to change the Prefix Length, Preference, and/or Route
Lifetimes that were reported for the Prefix in the initial redirection event.
(The redirection target could also set Route Lifetime to 0 to cancel an
existing route.)

> - Section 3.2
> 
>    An unsolicited Redirect message includes a Destination Address and
>    Redirected Header option that are either fabricated or derived from a
>    remembered packet that was processed at an earlier time.
>    Alternatively, the message could omit the Redirected Header option
>    and/or set the Destination Address field to "::" (the IPv6
>    unspecified address).  Such a message would still satisfy the message
>    validation checks in Section 8.1 of [RFC4861].
> 
>   I suspect a fabricated or '::' Destination Address doesn't always
>   work like a remembered one, since in that case the sending router is
>   (at least relatively) less likely to be the first-hop router for the
>   Destination Address for the receiving host.

We would like to seriously consider the use of '::' as the Destination Address
for all Redirects that include RIOs (more on that below). We would
therefore need to say that this document updates Section 8.1 of
RFC4861 by allowing Redirects that include RIOs to include a Destination
Address of "::".

> - Section 3.3
> 
>    [...] Type "D" hosts
>    process Redirect messages with RIO elements by updating
>    [...] and 3) their routing tables per any RIO
>    elements present.
> 
>   Does this mean prefixes in the RIO will be updated even if they
>   don't match the Redirect's Destination Address?

As above, we would like to consider using '::' as the Destination Address
for all Redirects that include RIOs. This would avoid the ambiguity
you are describing.

>   If so, I think it's
>   better to clarify that explicitly.  I also think that behavior may
>   be debatable (it's probably related to the general comment of
>   understanding why we need this extension).
> 
> - Section 3.3.1
> 
>   The discussion in this subsection is confusing to me.  Since a
>   "router MUST NOT update its routing table upon receipt of a
>   Redirect" (Section 8.2. of RFC4861), a straightforward
>   interpretation of the following text would be that it violates or
>   updates RFC4861:
> 
>    Such Type "D" hosts act like a host in
>    terms of processing received Redirects and act like a router in terms
>    of sending Redirects.
> 
>   But I guess it's actually talking about a hybrid host-router node,
>   acting as a host and DHCPv6 PD client on an "external interface"
>   while acting as a router for "an entourage of backend hosts" on
>   internal interface(s).  I see the existence of such a hybrid node at
>   least in practice (even if it's not officially defined in IETF
>   documents), but I don't understand why we have to bother to mention
>   it in this specification, since it doesn't seem to be specific to
>   the "type D" host.

Some of this may already be addressed by the "Motivation" section text
proposed near the beginning of this message, but we feel it is important
to establish that common node types that would use this extension would
act as a host for the purpose of receiving and processing Redirects but act
as a router for the purpose of generating Redirects. This is necessary to
satisfy the "MUST NOT" conditions at the bottom of Sections 8.2 and
8.3 of [RFC4861].

> - Section 4
> 
>    The Redirect function and RIOs are widely deployed in IPv6
>    implementations.
> 
>   This sentence could read as if the proposed extension is already
>   widely deployed in implementations.  If the intent is to say that
>   - the redirect function is widely deployed, and
>   - RIOs are (also) widely deployed (which I'm not so sure about, but
>     is probably true given Windows has implemented it).
>   then I'd suggest making it clearer.  I don't have a specific
>   suggestion, but perhaps stating these separately in separate
>   sentences is an easy way to do it.

Here is a proposal:

"The Redirect function as specified in Section 8 of RFC4861 is widely deployed
in all standard-compliant IPv6 implementations. The Route Information
Option specified in Section 3 of RFC4191 is widely deployed in some major
vendor and open system implementations."

> - Section 6
> 
>    "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a
>    layer-2 filtering technique intended for network operators to use in
>    [...]
> 
>   I don't understand the purpose of this paragraph, especially in the
>   context of the Security Considerations section.  Does this sentence
>   try to say that we could use the proposed extension in an
>   environment where a legitimate router can't send an RA due to
>   (perhaps misconfigured) RA guard?  That's probably true, but in that
>   case we should solve this problem operationally, i.e., fix the
>   configuration of RA guard rather than tweaking the protocol.  And
>   that doesn't seem to be a topic of security considerations anyway.
>   Or does this paragraph try to say something else?  In that case I
>   totally misunderstand it, and I guess it will have to be fully
>   rewritten unless I'm the only dumb person to understand it...

An earlier comment on the list asked us to investigate interactions with
RFC6105 under Security Considerations. We have analyzed the potential
interactions and documented them here to the best of our understanding.
But, we would be happy to consider any text change suggestions.

Fred and James

> --
> JINMEI, Tatuya