Re: [v6ops] Packets with LL src and GUA dst

[Alexandre Petrescu <[e-mail]>]

Le 17/06/2016 à 06:16, Owen DeLong a écrit :
>
>> On Jun 16, 2016, at 03:00 , Alexandre Petrescu
>> <[e-mail]> wrote:
>>
>>
>>
>> Le 15/06/2016 à 21:28, Musa Stephen Honlue a écrit :
>>> This is bad behaviour both for the source device(LL should not be
>>> used for off-link destinations), and for intermediary
>>> routers(they should not forward packet sourced with LLA).
>>>
>>> It is clear enough that responses to such packets won't be able
>>> to make their way back.
>>
>> I agree - but sometimes there is no need for response - protocols
>> such as OSPF or ICMP Router Advertisements, not to mention UDP
>> video streaming, dont need responses.
>
> Um… So just to make sure I understand correctly…
>
> Other than virtual links, OSPF route announcements shouldn’t have GUA
> destinations. In the case of a virtual link, an OSPF route
> announcement shouldn’t have LL source.

Ah, no, I did not mean of virtual links.

Simply an IPv6 OSPF router must be able to send an LSA (link-state
advertisement) to a multicast group beyond the link.

And it is not for that need that it must have a GUA/ULA.

A network of OSPF routers must be able to work without any GUA/ULA nor
IPv4 on any of the routers.

Because it is easy to set up same network with static routes, without
OSPF, and without GUA/ULA on them (just the LLs).

> In the case you seem to be proposing, virtual link with LL source and
> GUA destination, you would be sending a route announcement that
> effectively sets an un-reachable next-hop to the remote router. I’m
> not sure I see any possible benefit of this action under any
> circumstances. I can, however, see several problematic outcomes
> (network singularities anyone?).

I would agree with you if I proposed virtual links.

But not in this case.

A network of routers is able to forward packets even though it has not
GUA or ULA on any of the routers.

> Similarly, an ICMP RA should have either an LL destination or a
> multicast (link scoped) destination. I cannot see any valid case for
>  sending an RA off-link.
>
> So that leaves us with only UDP video streaming as your remaining
> theoretical case.
>
> Can you please elaborate on what possible useful case of a video
> streaming source would not have a GUA or ULA and would attempt to
> transmit said video stream off-link?

In IoT infratructure-less mobility settings there can be cases where
it's hard to form and keep a GUA (I am not talking ULA) for a
Thing-class device.  For example a wifi point-of-view miniature mobile
camera attached on the windshield wiper, but without cellular modem,
may IP stream what it sees.  Other vehicles hear it, display and further
forward.

> I realize that ULA may not be able to reach the intended destination,
> but at least that packet won’t make it past the border of the network
> administrative boundary that has agreed to accept this cruft
> (hopefully) which I would argue is a very desirable property of
> whatever it is you are proposing to do here.

I think I can agree with the ULA usefulness here, because it may
be forbidden from leaking to the Internet core (although I dont quite
understand the fear of ULAs or LLs -sourced packets showing up in the
DFZ - it doesnt look at it anyways because it wants to be fast).

>> For network control (ICMP), yes there is need to have ability to
>> reply back always, but some software uses ICMP for network control
>>  and UDP for video streaming.
>>
>> One should mpt use the LL src if ICMP is expected, but one could
>> very well use LL src for UDP for video streaming (video is just an
>>  example app).
>
> Again, I do not see a valid use case for LL Source if the destination
> is not on-link.

Assuming we have a common understanding of on-link.

I suspect your assumption of 'link' is not what many people in mobility
settings think a link can be.

> This is the entire point of scoped addresses and what you are
> wanting to do discards virtually all meaning of scope.

The whole meaning of scope is new in IPv6 vs IPv4.

And it's not easy: ULAs, scoped multicast groups and networks
disconnected from the Internet are all scope complications to
implementers wondering which additional rules to add (or not) to an
otherwise very simple forwarding implementation.

It's easy to enunciate and implement that each packet must have same
scope in src and dst.

But it's harder to say which non-equal scope packets can be forwarded
between interfaces of a router.

One would not forward a src LL dst GUA because they are different
scopes.  Yet one _would_ forward a src GUA dst ULA even though they are
different scopes too.

Moreover, one _would_  forward a src ULA dst site-local multicast group
(the ULA scope is almost the same scope as the site-scope) and, worse,
an across-subnets site-local multicast group could contain only LL
addresses if the subscribers decided to use their LLs (the subscription
operation is a link-local operation - MLD).

I would also like to mention the difficulty in understanding scopes
being 'larger' than others, or scopes 'containing' scopes as they are
found in many RFCs.  'Larger' and 'containing' may be intuitive to many
readers (e.g. global scope is larger than link scope, the global scope
contains all links scopes), but can be hard to implementation (wifi
'overlapping' models dont contain each other and are sometimes
disconnected from the Internet).

> What will you want next? ff02:: packets being delivered globally?

I argued about src LL, not dst LL.  I think it is largely agreed that
dst LL packets would not be forwarded.  I can agree.

>>> Therefore, if the path of such packets can be traced, it is
>>> necessary to report a bug to various vendors concerned for them
>>> to deal with this issue in accordance with specifications as per
>>> https://tools.ietf.org/html/rfc4291#section-2.5.6.
>>
>> I am not sure we must build in a capability to always trace back to
>> originators.  This is may be way beyond pure packet data
>> communications.
>
> That’s not what he is saying. What he is saying is that in the case
> A->B->C->D->E->F->G->H->I where A sends a packet with LL src and I
> dst and I receives the packet, one should make a best effort to
> identify {H, G, F, E, D, C, B, A} and report bugs to the vendors
> responsible for the IPv6 stack implementation on each and every one
> of them because each and every one of them did something bad.
>
> He is absolutely right in saying this.

By the specs, yes, he's right.  Thanks to the WG members for having
provided the refs to the specs.

Alex

>
> Owen
>
>