Subject: RE: Redirect ICMP and TAHI test?

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Feb 2001 08:25:44 -0800

Yes, the Redirect TAHI tests fail on the MS implementation, for the same
reason. I think the test is broken.

Rich

> -----Original Message-----
> From: Markku Savela [mailto:[email-masked]]
> Sent: Monday, February 19, 2001 4:38 AM
> To: [email-masked]
> Subject: Redirect ICMP and TAHI test?
> 
> 
> In RFC-2461 "8.1 Validation of Redirect Messages" there is
> 
> "- The IP source address of the Redirect is the same as the current
>    first-hop router for the specified ICMP Destination Address."
> 
> In TAHI Neighbor Discovery test 62, it introduces two routers, then
> sends a redirect from "one" of them, and expects the redirect to have
> an effect...
> 
> ...and in my code it doesn't, because I currently coded the validation
> literally in respect to the above entry. I take the destination
> address and check from the routing table which router would actually
> be getting this destination. And, as it happens, I pick the "other"
> and validation declares the redirect as invalid (e.g. I get a redirect
> from router, to wich I would not have sent the packet in question...)
> 
> So, I assume I have to loosen the test, and accept redirects from any
> router, which potentially might be valid for the destination (for
> example, any of the default routers), even if it is not my "current
> first-hop router for the destination"?
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Feb 2001 08:25:44 -0800

Rich

---

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Feb 2001 11:08:57 -0800

> > You're supposed to accept Redirects even if there is no Destination
> > Cache entry...
> 
> Where does it say so?

In RFC 2461:

8.3.  Host Specification

   A host receiving a valid redirect SHOULD update its Destination Cache
   accordingly so that subsequent traffic goes to the specified target.
   If no Destination Cache entry exists for the destination, an
   implementation SHOULD create such an entry.

Rich

---

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Feb 2001 08:25:44 -0800

> The idea behind the validity test is that a node should only accept
> a redirect from router R1 if the node very recently sent a packet
> to R1 that was for the destination.
> 
> In your implementation do you have something similar to a 
> "destination cache"
> which retains the next hop where you last sent packet?
> Or do you always do a lookup and find the default route(s)?

Rich

---

From: "Richard Draves" <[email-masked]>
Date: Tue, 20 Feb 2001 14:05:24 -0800

> But the above is a SHOULD and the validity checks in section 8.1
> say MUST discard when this fails:
> 
>       - The IP source address of the Redirect is the same as 
> the current
>         first-hop router for the specified ICMP Destination Address.
> 
> If there is only one default route pointing at the link
> from which the redirect was received
> (or for implementations with a richer routing table, 
> the lookup of the destination address only finds one routing
> table entry that points at that link), then the redirect can
> be safely used to create a destination cache entry.
> 
> But when the lookup finds more than one possible next hops 
> that might have
> been used to send the original packet, it seems a bit dangerous to
> accept the redirect.

The "current first-hop router for a destination" is a well-defined
concept in our implementation, even if there are multiple default
routers and no current destination cache entry.  I don't see the danger
in accepting the redirect under those circumstances.

Rich