RE: Route Information Options in Redirect Messages (updated)

[Mark Smith <[e-mail]>]

Hi Fred,

On 8 Feb. 2017 06:54, "Templin, Fred L" <[e-mail]> wrote:

Hi Mark,



> Ø  I think you need to be careful of not effectively reinventing a dynamic routing protocol



> No, there is no reinvention going on here. The behavior parallels redirects

> for singleton destination addresses, where Redirects are accepted from the

> current first-hop router, be it a default or non-default.


So in my proposed case of a stub router receiving and accepting a
prefix redirect, that is where there would be more of behaviour
change, as, per RFC4861,

A router MUST NOT update its routing tables upon receipt of aRedirect.

For these stub routers, accepting a prefix redirect from more than
just a default router is where I think it starts encroaching on the
functionality of a dynamic routing protocol. It starts being possible
to have all the stub routers in the set sending each other prefix
redirects (perhaps maliciously) and ending up with a variety of
different, possibly random paths across the link, with some of those
paths creating forwarding loops. Dynamic routing protocols would
resolve this situation to a single best path as well as eliminating
forwarding loops. That is the sort of functionality that would be (and
should be to keep it simple) missing from a simple prefix redirect
mechanism.

I think limiting the problem space to that of providing a better entry
point into the "proper" routing system/forwarding domain for stub
routers, by only accepting them from default routers learned via RAs
or static configuration, avoids the possibility of encountering and
having to mitigate these more complex issues.

Perhaps that means there needs to be two different validation rules
for the two different types of devices:

- for hosts, accept prefix redirects from current first-hop router for
a destination covered by the prefix

- for stub routers, only accept prefix redirects from default routers

with the fundamental distinguisher between the device types being
whether they forward non-local packets or not, and whether a stub
router accepts them or not being dependent on whether there is a
dynamic routing protocol enabled on the prefix redirect receiving
interface.


Regards,
Mark.








Thanks - Fred



From: Mark Smith [mailto:[e-mail]]
Sent: Tuesday, February 07, 2017 11:38 AM


To: Templin, Fred L <[e-mail]>
Cc: 6man WG <[e-mail]>; james woodyatt <[e-mail]>; 神明達哉
<[e-mail]>
Subject: RE: Route Information Options in Redirect Messages (updated)







On 8 Feb. 2017 05:43, "Templin, Fred L" <[e-mail]> wrote:

Hi Jinmei-san,

<snip>
>
> Hmm, maybe I'm so dumb but I'm afraid I still don't understand intent
> clearly.  Do you mean an operational assumption of this proposal is to
> use it in a link where RA guard isn't deployed?  If so, it's far
> better (at least to me) to just say so.
>
> BTW, if this proposal keeps the concept of "unsolicited redirect" and
> also allows the destination address of '::' to bypass the host's
> validity check of whether it's really the first hop router for the
> destination,

No, that is not what we want to have happen. The document doesn't
say this currently, but we want to retain a revised version of the validity
check. The revised version of the check would say:

OLD:
      - The IP source address of the Redirect is the same as the current

        first-hop router for the specified ICMP Destination Address.

NEW:
      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address, or
        (when the ICMP Destination Address is '::') the same as the current
        first-hop router for the specified RIOs

Would welcome better wording than this, but we definitely do want
to retain the validity check. Comments?



I think you need to be careful of not effectively reinventing a
dynamic routing protocol that ends up missing the necessary
capabilities required of one to keep this method simple.



When I've thought about this sort of capability, I've thought of it as
a hint from the routing system to the users of the forwarding domain -
hosts and stub routers (default and connected route only routers,
possibly with other static routes) - of a better entry point for their
packets into the forwarding domain.



In the case of a stub router, if it needs or would benefit from more
dynamic network information than just a prefix redirect hint, then I
think that is really saying that the stub router shouldn't be a stub
router - it needs to be a full and proper participant in the routing
system (running dynamic routing protocol, discovering and conveying
network topology information etc.), rather than a user of it via
default route to the forwarding domain.



That's why I thought the validation should be that these prefix
redirects are only accepted from a default router learned via an RA or
static default router configuration, as a default router has the role
of offering an entry point into the forwarding domain. It would
enforce the existing boundary between the devices that are users of
the forwarding domain, and the devices that are participants in the
routing system that decide the paths through the forwarding domain.



Regards,

Mark.