RE: Route Information Options in Redirect Messages (updated)

[Mark Smith <[e-mail]>]

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.