RE: Route Information Options in Redirect Messages (updated)

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

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.

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]<mailto:[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.