Re: [v6ops] [homenet] Tsinghua work on source/destination routing

<hermin.anggawijaya@gmail.com> 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 <furry13@gmail.com> wrote:

> On Thu, Nov 7, 2013 at 7:40 PM, Hermin Anggawijaya
> <hermin.anggawijaya@gmail.com> 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 <furry13@gmail.com> wrote:
> >>
> >> On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) <fred@cisco.com>
> 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
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
>
>
>
> --
> SY, Jen Linkova aka Furry
>