RE: Route Information Options in Redirect Messages (updated)

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

Jinmei-san - see below for responses:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
> Sent: Friday, February 03, 2017 11:52 AM
> To: Templin, Fred L <[e-mail]>
> Cc: james woodyatt <[e-mail]>; IPv6 List <[e-mail]>
> Subject: Re: Route Information Options in Redirect Messages (updated)
> 
> At Fri, 3 Feb 2017 00:02:10 +0000,
> "Templin, Fred L" <[e-mail]> wrote:
> 
> >    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.
> 
> So, an intended use case is something like this?
> 
>            Customer Edge Router
>                 |
>                 |
>     ----+-------+--------+---   <=== same single LAN
>             |                |
>           Node-A           Node-B
>           ||||||           ||||||
>          IoT devs          IoT devs
> 
> where both Node-A and Node-B get prefixes via DHCP-PD, act as a host
> on the LAN-facing interfaces while acting as a router for the "IoT
> devices" behind it.  When an IoT device behind Node-A ('IoT-A') sends
> a packet to an IoT device behind Node-B ('IoT-B'), Node-A first
> forwards the packet to the customer edge router.  The router knows the
> prefix for Node-B can be directly reachable from Node-A, so it sends a
> Redirect with RIO for that prefix.  Subsequent packets from IoT
> devices behind Node-A to devices behind Node-B will be directly
> forwarded to Node-B.

Yes. Although, instead of "LAN" we would prefer to see your figure
use the word "Link". Reason is that LANs are often understood to be
limited in expanse, where "Link" is a more generic term that could
apply to a facility that extends to vast connected network regions.

> > > - 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.
> 
> Hmm...although RFC4861 doesn't explicitly ban "unsolicited" redirects,
> the following text of Section 8.2
> 
>    A router SHOULD send a redirect message, subject to rate limiting,
>    whenever it forwards a packet that is not explicitly addressed to
>    itself (i.e., a packet that is not source routed through the router)
> 
> looks to me that it pretty clearly assumes sending that redirects are
> only "reactive".

We could argue as to how to interpret RFC4861's silence on unsolicited
Redirects, but rather than argue can we simply agree that an update to
RFC4861 could allow them?

> > 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 we want to be sure about the original intent we might ask the very
> original authors of RFC1970, but in any case it would be clearer to
> at least say this something not explicitly documented in the original
> ND spec.

OK.

> > >   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.)
> 
> Hmm...so the intent is to allow 'Node-B' in the above example to send
> redirects?  That sounds like 'Node-B' is actually a "router" that just
> doesn't speak routing protocols (note also that a "host" MUST NOT send
> redirect per RFC48610.)  So, to this end, it rather seems to make
> sense to allow it to send an RA with RIO instead of tweaking the
> redirect spec further.

There are several considerations here. First RA with RIO might be blocked by
RA Guard. Second, RA message validation does not require a source address
check in the way that Redirects do, meaning that 'Node-A' would accept RAs
coming from any node on the link, and not just 'Node-B'. Third, Redirects
include a Target address whereas RA messages do not; for example, 'Node-B'
could send a Redirect with Target address of 'Node-C' for some other node
on the link that is now a better next hop.
 
> Then we won't have to worry about the tricky
> questions on Sections 3.2 and 3.3 (but see also below).
> 
> > > - Section 3.3.1
> > >
> > >   The discussion in this subsection is confusing to me.
> >
> > 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].
> 
> Okay, now I think I'm getting what you're trying to do.  IMO this will
> lead to a more profound discussion of the definition of router and
> host, rather than a mere extension to the redirect message.  I'd
> consider revising this proposal as such, i.e, first redefining hosts
> and routers as an update to prior IPv6 protocol specs and then
> proposing the redirect extension on top of the update.

This is not the first time documents have been published that talk
about nodes that act a little bit like a host and a little bit like a router.
See for example RFC7084 that speaks about CPE routers sending
RS messages; presumably to receive and process RAs.

> > > - 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."
> 
> Yes, this one is much better.

OK.

> > > - 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.
> 
> I can't suggest anything at this moment as I don't understand what it
> actually tries to state...for example, I don't know whether it tries
> to say "the RA Guard function defined in [RFC6105] does not filter ND
> Redirect messages" is considered an issue to be resolved/mitigated or
> a good effect of this proposal.

Still not sure what if anything to do about this, but we are still open
to suggestions.

Fred and James

> --
> JINMEI, Tatuya