Re: Route Information Options in Redirect Messages (updated)

[神明達哉 <[e-mail]>]

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.

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

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

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

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

--
JINMEI, Tatuya