<[email protected]> wrote: >> I'm seeing plenty of packets from link-local sources to global >> destinations >> ..... > >> 2) routers on the Internet do forward such packets (violating the rule >> mentioned above). >> Fixing #2 actually requires making forwarding decision based on src >> and dst (which is not happening now). > > To fix the above issue, wouldn't address scope checking be enough, rather > than the [src,dst] based routing > discussed ?
> My point is that to do verify the scope, the router need to check > *source* address while making forwarding decision. > It looks like it is not happening now but it might get changed by > [src, dst] based routing. scope checking does not need to look up any fib though whereas [src,dst] forwarding does. I think scope checking feature is standard even on switching silicons *today*. But I think I understand what you are trying to say, we just have different interpretation of the phrase [src,dst] forwarding. Thanks. On Thu, Nov 7, 2013 at 3:27 PM, Jen Linkova <[email protected]> wrote: > On Thu, Nov 7, 2013 at 7:40 PM, Hermin Anggawijaya > <[email protected]> wrote: > >> I'm seeing plenty of packets from link-local sources to global > >> destinations > >> ..... > > > >> 2) routers on the Internet do forward such packets (violating the rule > >> mentioned above). > >> Fixing #2 actually requires making forwarding decision based on src > >> and dst (which is not happening now). > > > > To fix the above issue, wouldn't address scope checking be enough, rather > > than the [src,dst] based routing > > discussed ? > > My point is that to do verify the scope, the router need to check > *source* address while making forwarding decision. > It looks like it is not happening now but it might get changed by > [src, dst] based routing. > > > On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova <[email protected]> wrote: > >> > >> On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) <[email protected]> > wrote: > >> > Examples of use cases are generally around multi-prefix campus > networks. > >> > There is a security use case that could be of value; at IETF 87, > George > >> > Michaelson of APNIC reported on ULAs seen in his darknet. The short > report > >> > is that he sees a fair bit of traffic with a ULA source address on the > >> > backbone. An interesting potential use of source/destination routing > would > >> > counter that, and perhaps mitigate the need for ISP BCP 38 if > generally > >> > deployed; in a case where a network is using a ULA and a global prefix > >> > (e.g., is not multihomed but has two prefixes, one of which is > intended to > >> > only be used within its network), the default route to the network > egress > >> > would use the global prefix as a source, and as a result traffic sent > >> > outside the network with a ULA source prefix would in effect have no > route. > >> > The network could literally only emit traffic from its correct prefix. > >> > >> Looks like we (finally) have a chance to enforce the requirement from > >> RFC4007, Section9: > >> > >> "If transmitting the packet on the chosen next-hop interface > >> would cause the packet to leave the zone of the source > >> address, i.e., > >> cross a zone boundary of the scope of the > >> source address, then the packet is discarded. " > >> > >> I'm seeing plenty of packets from link-local sources to global > >> destinations which means that: > >> 1) there are hosts with broken default address selection > >> AND > >> 2) routers on the Internet do forward such packets (violating the rule > >> mentioned above). > >> Fixing #2 actually requires making forwarding decision based on src > >> and dst (which is not happening now). > >> > >> More data (sorry, shameless plug :)) > >> https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf > >> > >> -- > >> SY, Jen Linkova aka Furry > >> _______________________________________________ > >> v6ops mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > -- > SY, Jen Linkova aka Furry >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
