Re: [homenet] Redirect and source-specific routing
Hello Juliusz, Indeed, RFC 4861 is pretty clear and Redirects seem to have a flow when used with sadr. gratuitous-ad-for-own-draft Updating RFC 4861 is one way to do it, we could also make hosts sadr-aware. /gratuitous-ad-for-own-draft Brian is going to lead a discussion in 6man about the whole hostssadr problem. One interesting fact though is that Open-Source does not wait for IETF to fix IETF’s bugs. http://lxr.free-electrons.com/source/net/ipv6/route.c#L1285 It looks like Linux looks at the IPv6 header within the redirect and only applies the redirect to the given source+dest pair. - Pierre Le 13 juil. 2015 à 09:23, Ole Troan otr...@employees.org a écrit : Juliusz, I'm wondering if there isn't some interaction between Redirect messages and source-specific routing that we're overlooking. RFC 4861 Section 8.3 says the following: Redirect messages apply to all flows that are being sent to a given destination. That is, upon receipt of a Redirect for a Destination Address, all Destination Cache entries to that address should be updated to use the specified next-hop, regardless of the contents of the Flow Label field that appears in the Redirected Header option. It does not speak of the source address, so I assume that this applies to all sources. Consider the following topology: A ---+--- B | H If A and B advertise non-overlapping source-specific default routes and H is multiplexing its traffic over source addresses in both source prefixes (say, it's using MP-TCP), its Destination Cache entry will flap between A and B. If I'm right, that argues in favour of an update to RFC 4861. you are right. these issues are currently being discussed in 6man. see http://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-07 we haven’t reached a conclusion if a source aware redirect is needed or not (if that’s what you had in mind). by the way, there is also ICMP unreachable code 5 (Source address failed ingress/egress policy), which I would think the router should send, rather than the redirect in this case. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Redirect and source-specific routing
On 13/07/2015 02:30, Juliusz Chroboczek wrote: I'm wondering if there isn't some interaction between Redirect messages and source-specific routing that we're overlooking. RFC 4861 Section 8.3 says the following: Redirect messages apply to all flows that are being sent to a given destination. That is, upon receipt of a Redirect for a Destination Address, all Destination Cache entries to that address should be updated to use the specified next-hop, regardless of the contents of the Flow Label field that appears in the Redirected Header option. It does not speak of the source address, so I assume that this applies to all sources. It definitely should not, since in some topologies that might send packets directly to a BCP38 filter. I think that's a 6man issue. I might even have to modify my slides for 6man. Brian Consider the following topology: A ---+--- B | H If A and B advertise non-overlapping source-specific default routes and H is multiplexing its traffic over source addresses in both source prefixes (say, it's using MP-TCP), its Destination Cache entry will flap between A and B. If I'm right, that argues in favour of an update to RFC 4861. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Redirect and source-specific routing
I'm wondering if there isn't some interaction between Redirect messages
and source-specific routing that we're overlooking. RFC 4861 Section 8.3
says the following:
Redirect messages apply to all flows that are being sent to a given
destination. That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
It does not speak of the source address, so I assume that this applies to
all sources. Consider the following topology:
A ---+--- B
|
H
If A and B advertise non-overlapping source-specific default routes and
H is multiplexing its traffic over source addresses in both source
prefixes (say, it's using MP-TCP), its Destination Cache entry will flap
between A and B.
If I'm right, that argues in favour of an update to RFC 4861.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
