> But what do you do when the routers will NOT supply this message? Well, if you are trying to implement a multihomed solution and this solution involves multiple elements, i guess that you need all of them working properly. I mean, when you adopt this solution in a multihomed site, you have to make sure that both the router part and the host part of the solution is working.
> > In general, I think only few routers would report this, as it would > require an entirely new kind of logical "interface" between ingress > filtering and ICMP in the implementation (when generating the ICMP > message, look up the ingress filtering table in a new way, again) -- > especially the products which do not generate these messages on > software would unlikely be upgraded. > OTOH, which routers do you think that will send a ICMP error back to the source?. My understanding is that edge routers are likely to send this message but core routers don't. So i don't expect that core routers will implement this but it is not needed for the multihoming solution, since for this multihoming solution to work, it only requires exit routers to support this. the bottom line is that, if we end up building a solution that is optimized with this message, i would expect that routers will implement it, becuase it would be useful. That is why, i think that a MAY would be OK > Note that you have to add different code in the hosts for the major > case when this supplemental information is NOT supplied as well. > This would be just an optimization, and an unnecessary one for a > dual-homed network (if it fails, just try the other address :), which > is probably (unless you subscribe to ohta-san's DFZ model :) the > common case. I fully agree with you. But the major case (as you call it) would be addressed by simply picking a random source address (different from the one included in the icmp error) So this would be an optimiztion, but imho a powerful one in some cases. For instance, consider a multihoming solution for medium size sites that have multiple providers and that run bgp with their isps. In this case, the internal routing system knows which path is available towards the selected destination, but the source address may be incompatible with the exit isp. In this case you need a mechanism to communicate the correct source address to the the host. If multiple prefixes are available at the site, the retrial process may be take a ling time. So this optimization would enable a much better performance. > > So this would seem to be an optimization for the case that: > > - routers in fact do supply the information, As i mentioned, if this is part of your multihoming solution, i guess you could assume this > - just one prefix is used per router, Well, the site exit router can connect with more than one provider implying more than one prefix, and there is no problem here, just choose one of the accepted prefixes > - the site/host is multihomed to at least 3 providers. Yes. While i agree that dual homing would be the most common case, i guess that there will be lots of site that multihome to more than 2 isp, so it is case that has to be considered also. regards, marcelo > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
