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

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 3 Jun 2016 08:11:51 +0200 (CEST)

Hi,

I'm getting reports of people getting packets "over the Internet" with LL 
source address and GUA dst address. This seems to be a direct violation of 
https://tools.ietf.org/html/rfc4291#section-2.5.6 ?

Is there some other RFC somewhere that contradicts this or should we all 
start opening bug cases with our vendors if we see these types of packets 
forwarded to us from outside the link?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Jun 2016 15:18:45 +0900

IIRC it's invalid behaviour. That said, I wouldn't be surprised if some
vendor said "we can do this but on these platforms it will cut IPv6 peak
performance by 2x because it requires 2x the TCAM lookups" :-)

On Fri, Jun 3, 2016 at 3:11 PM, Mikael Abrahamsson <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 3 Jun 2016 08:30:43 +0200

Hi,

> forwarded to us from outside the link?

I'm one of those seeing the packets...  (as a consequence of filtering
stuff that "should not be there anyway" on my uplinks, and logging to
see what might be there nevertheless)

Jun  3 07:53:15 ipv6_acl_daemon[289]: %ACL-IPV6_ACL-6-IPACCESSLOGP : access-list internet-ipv6-in (140) deny tcp fe80::baac:6fff:fe98:c24a(51114) (TenGigE0/0/2/3)-> 2001:608:2:84::130(25), 4 packets  
Jun  3 07:58:38 ipv6_acl_daemon[289]: %ACL-IPV6_ACL-6-IPACCESSLOGP : access-list internet-ipv6-in (260) deny udp fe80::7a2b:cbff:fe6a:85d4(46437) (TenGigE0/0/1/3)-> 2001:608:e02:487::4(53), 1 packet  
Jun  3 08:00:13 ipv6_acl_daemon[289]: %ACL-IPV6_ACL-6-IPACCESSLOGNP : access-list internet-ipv6-in (260) deny 58 fe80::21c:42ff:feb4:846d (TenGigE0/0/1/2.406)-> 2001:608:1:151::17, 3 packets  

one is an IXP link, the two others are uplinks to two of our ISPs - one is
using Juniper gear, the other one I'm not sure.

Trying to reproduce this by sending packets across one of our 6500/sup720,
I can't make it happen - so at least the sup720 properly drops LLA->off-link
packets (though it has other warts, like its netflow never mentioning LLA 
sourced at all).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Jun 2016 15:39:24 +0900

Also see Jen's stats here:
https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf

---

From: Philip Homburg <[email-masked]>
Date: Fri, 03 Jun 2016 10:31:37 +0200

>forwarded to us from outside the link?

A couple of years ago I looked into this and then it was Juniper forwarding
such packets. It is really weird if you have such an address in a traceroute
many hops away from the source.

Of course, the only way to see such packets at a host is if your own router
has this bug.

I guess that on other routers it is just a statistic among all other
dropped traffic.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 3 Jun 2016 12:11:32 +0200

>> https://tools.ietf.org/html/rfc4291#section-2.5.6 ?

Yes, I believe it is.

>> Is there some other RFC somewhere that contradicts this

I'm not aware of any such RFC. I think vendors just do not care.

There are 3 problems there:
1) hosts (router) send packets for global offlink destination using
LLA. Unless the sender does not have any GUA, it looks like badly
broken default address selection
2) routers forward those packets, violating
https://tools.ietf.org/html/rfc4007#section-9 and
https://tools.ietf.org/html/rfc4291#section-2.5.6
3) people do not filter them

> or should we all

We should indeed. (The problem usually is that it all depends on the
kindness of strangers: when I see ICMPv6 Packet Too Big coming to my
network with LLA source from somewhere in the Internet, I can only
kindly ask my peer to check why their router forwards such packet....)

-- 
SY, Jen Linkova aka Furry

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Jun 2016 10:30:25 +0000

Quote one of the basic rules in IPv6 SAS (Source Address Selection) - see RFC 6724.  Specifically, see section 5, Rule 2 included below.  

Rule 2: Prefer appropriate scope.
   If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
   otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
   Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.

Hemant

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Friday, June 03, 2016 2:12 AM
To: [email-masked]
Subject: [v6ops] Packets with LL src and GUA dst

Hi,

I'm getting reports of people getting packets "over the Internet" with LL source address and GUA dst address. This seems to be a direct violation of
https://tools.ietf.org/html/rfc4291#section-2.5.6 ?

Is there some other RFC somewhere that contradicts this or should we all start opening bug cases with our vendors if we see these types of packets forwarded to us from outside the link?

---

From: Jen Linkova <[email-masked]>
Date: Fri, 3 Jun 2016 13:23:30 +0200

>    Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.

One of the case when it might happen w/o violating RFC6724 is when the
outgoing interface has LLA only and the particular implementation does
not include loopback address or GUA assigned to any other interfaces
(Section 4 says 'MAY').

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Jun 2016 13:24:52 +0200

Hi,

Le 03/06/2016 à 08:11, Mikael Abrahamsson a écrit :
>
> Hi,
>
> I'm getting reports of people getting packets "over the Internet"
> with LL source address and GUA dst address. This seems to be a
> direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6
> ?

Yes, but.

A message of best-effort "beacon" semantics is sent by a device to
members of a global multicast group address.  Due to peer-to-peer
absence of authority it may be hard for the device to configure and keep
a GUA, and hard to inject a GUA in the routing system too - hence it
would use its LL as src.

I dont think there is any other IP mechanism for such a device to beacon
its message across subnets, but to src==LL and dst==global-mcast.

Given that, while I would agree to a common practice of same-scoped src
and dst fields in same IPv6 header I would consider the exceptions too.

(if there were something to definitely prohibit, it would be a src field
to contain a multicast address - it makes little sense).

> Is there some other RFC somewhere that contradicts this

The Code 2 ICMPv6 Parameter Problem is defined in RFC4443 pp. 9 3rd par
https://tools.ietf.org/html/rfc4443#page-9 reads:
> If the reason for the failure to deliver is that the destination is
> beyond the scope of the source address, the Code field is set to 2.
> This condition can occur only when the scope of the source address
> is smaller than the scope of the destination address (e.g., when a
> packet has a link-local source address and a global-scope
> destination address) and the packet cannot be delivered to the
> destination without leaving the scope of the source address.

Mikael said:
> or should we all start opening bug cases with our vendors if we see
> these types of packets forwarded to us from outside the link?

For the router vendor: does the router implement Code ICMPv6 Parameter
Problem? Does it send it?

For the OS vendor: what does a Host when it receives a Code 2 ICMP
Parameter Problem?  Does it print on screen, or does it change the scopes?

Alex

---

From: Enno Rey <[email-masked]>
Date: Fri, 3 Jun 2016 14:26:59 +0200

Hi,

I'm aware that this is not rly a productive contribution to the thread, but I'd like to point out that my belief (based on observations in the field) is that less than 50% of IPv6 implementations "mostly follow RFC 3484 or 6724". They do sth else, with "sth" being close to "sth random".

best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Erik Kline <[email-masked]>
Date: Fri, 3 Jun 2016 23:07:11 +0900

I wonder what the distribution of the hoplimits in the receive LL
src'd packets is.  If it looks like a count down from 255 that's a
protocol violation.  If they look more like count down from, say, 64,
then that sounds more like a corner case bug.

---

From: Gert Doering <[email-masked]>
Date: Fri, 3 Jun 2016 16:38:02 +0200

Hi,

> a GUA, and hard to inject a GUA in the routing system too - hence it

We're not talking multicast and convoluted configurations.  The packets
I've seen are bog standard unicast ping or UDP 53 (DNS request) packets.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Jun 2016 00:28:06 +0900

> not include loopback address or GUA assigned to any other interfaces

There are plenty of home gateways that announce a default route but don't
assign global addresses, or that only assign addresses via DHCPv6 and have
clients behind them that don't support DHCPv6.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 3 Jun 2016 09:12:46 -0700

Open bugs.

A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived.

Owen

> On Jun 2, 2016, at 23:11 , Mikael Abrahamsson <[email-masked]> wrote:
> 
> 
> Hi,
> 
> I'm getting reports of people getting packets "over the Internet" with LL source address and GUA dst address. This seems to be a direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 ?
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 3 Jun 2016 09:35:22 -0700

> On Jun 3, 2016, at 04:24 , Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 

This is unacceptable behavior. It would be better for such a device to
cobble together its own ULA for this purpose than to use its LL as source.
(And you know how much I hate ULA).

No multicast packet with a scope greater than LINK should be sourced from
an LL address.

I don’t know if the RFCs clearly state that, but I would argue that if they
don’t say that yet, they certainly should.

> and dst fields in same IPv6 header I would consider the exceptions too.

Making an exception here is silly. It invites mischief and the use case
you describe is better handled using other mechanisms. ULA is a really
bad choice too, but it’s still slightly better than LL.

> Problem? Does it send it?

While it is ideal that the router does this, even if it does not, it should
at least drop the LL sourced packet rather than forward it to an interface
other than the arrival interface. Any router which fails to drop these
packets is misbehaving and a bug should be filed when the behavior is
detected.

> Parameter Problem?  Does it print on screen, or does it change the scopes?

Presumably if changing scopes was an option, it would have selected more
compatible scopes in the first place. I see three possibilities:

	1.	The user/application specifically selected the incomaptible
		scopes in which case reporting an error back to the user
		is appropriate behavior.

	2.	Automatic source address selection is not working correctly
		on the host in which case reporting an error back to the user
		is appropriate behavior. (The user should then file a bug).

	3.	The system (or possibly just the outbound interface, depending
		on implementation) doesn’t have a valid source address with
		a compatible scope in which case reporting an error back to
		the user is appropriate behavior.

Therefore, once it gets to this point, I believe reporting an error back
to the user is correct behavior in all three scenarios. If you can think
of a scenario not covered by those three possibilities, then it may require
separate analysis with a different conclusion.

Owen

---

From: Jen Linkova <[email-masked]>
Date: Fri, 3 Jun 2016 18:57:25 +0200

> a GUA, and hard to inject a GUA in the routing system too - hence it

Sending a packet with LLA src means 'sending a packet with source
address which is meaningless outside of that link'.
Basically it is more or less the same (or even worse) than sending a
packet with source address set to '::'.

> its message across subnets, but to src==LL and dst==global-mcast.

Is it OK to send a packet with undefined address to Internet? Shall
routers route it between interfaces?

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Jun 2016 20:50:23 +0200

Le 03/06/2016 à 16:38, Gert Doering a écrit :
>> absence of authority it may be hard for the device to configure and
>> keep a GUA, and hard to inject a GUA in the routing system too -
>> hence it would use its LL as src.
>
> We're not talking multicast and convoluted configurations.

Ok but please dont call that convoluted.  There is a strong use-case for
it and that's the potential solution.  If you can think of other 
solution in which a "beacon" is sent to many receivers away from the 
subnet, and which cant configure a GUA for itself, then I am interested 
to hear.

> The packets I've seen are bog standard unicast ping or UDP 53 (DNS
> request) packets.

Ok, so that makes wonder what DNS client is it, and what router was its 
first hop.

Alex

>
> Gert Doering -- NetMaster
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 3 Jun 2016 22:27:38 +0200

Hi,

> subnet, and which cant configure a GUA for itself, then I am interested 

If you want to communicate with off-net machines and have no GUA, that
situation *is* convoluted.  Or one could say I would be surprised if
it works at all, given that multicast routing usually relies on 
reverse-path-trees which totally break for LLA sources.

> Ok, so that makes wonder what DNS client is it, and what router was its 

Hard to say, since I only have a link-local address as a source...

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jun 2016 08:56:02 +1200

> I'm aware that this is not rly a productive contribution to the thread, but I'd like to point out that my belief (based on observations in the field) is that less than 50% of IPv6 implementations "…

It seems clear to me that whatever we write in RFCs, there will sometimes be situations,
possibly transitory, where a host will not have any GUA but will decide to send
a packet to a GUA. So it will send it with a LL source address.

That cannot be excluded, so the rule that forwarding nodes MUST NOT forward such
a packet off link needs to be enforced. We don't have an IPv6 Router Requirements
RFC, so I can understand how vendors can miss it in RFC4291. But it's a bug.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Fri, 3 Jun 2016 17:11:47 -0700

> On Jun 3, 2016, at 11:50 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> it and that's the potential solution.  If you can think of other solution in which a "beacon" is sent to many receivers away from the subnet, and which cant configure a GUA for itself, then I am interested to hear.

I would argue that in that case, it is better to send with source of :: (Unknown) than with LL.

It’s ugly, it will probably get dropped, but at least the RFC’s don’t require it to get dropped as they do with LL.

Frankly, I’m trying to understand the use case for such a beacon and how/why you have a device that can’t get a global address but has internet connectivity and it is escaping me. Perhaps with more detail about the nature of the thing that is beaconing and/or the environment in which it operates, other solutions could be proposed.

> Ok, so that makes wonder what DNS client is it, and what router was its first hop.

Every router between the source and point where the packet was dropped is wrong (as well as the origin host).

Not just the first hop, though if the first hop was right, the rest being wrong would be undetectable in this scenario.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Jun 2016 15:55:54 +0200

Le 03/06/2016 à 18:35, Owen DeLong a écrit :
>>> I'm getting reports of people getting packets "over the
>>> Internet" with LL source address and GUA dst address. This seems
>>> to be a direct violation of
> This is unacceptable behavior. It would be better for such a device
> to cobble together its own ULA for this purpose than to use its LL as
> source.

But that would create a packet with src ULA and dst GUA.  Would that be
more acceptable than src LL and dst GUA?

> No multicast packet with a scope greater than LINK should be sourced
> from an LL address.
>
> I don’t know if the RFCs clearly state that, but I would argue that
> if they don’t say that yet, they certainly should.

I would argue they shouldn't.

There should be a possibility for a device which can't configure a GUA
or a ULA to still send packets to a group of interested parties.

>
>> I dont think there is any other IP mechanism for such a device to
>> beacon its message across subnets, but to src==LL and
>> dst==global-mcast.
>>
>> Given that, while I would agree to a common practice of same-scoped
>> src and dst fields in same IPv6 header I would consider the
>> exceptions too.
>
> Making an exception here is silly. It invites mischief and the use
> case you describe is better handled using other mechanisms.

Which ones?

[...]
> Presumably if changing scopes was an option, it would have selected
> more compatible scopes in the first place. I see three
> possibilities:
>
> 1.	The user/application specifically selected the incomaptible scopes
> in which case reporting an error back to the user is appropriate
> behavior.
>
> 2.	Automatic source address selection is not working correctly on the
> host in which case reporting an error back to the user is appropriate
> behavior. (The user should then file a bug).
>
> 3.	The system (or possibly just the outbound interface, depending on
> implementation) doesn’t have a valid source address with a compatible
> scope in which case reporting an error back to the user is
> appropriate behavior.
>
> Therefore, once it gets to this point, I believe reporting an error
> back to the user is correct behavior in all three scenarios. If you
> can think of a scenario not covered by those three possibilities,
> then it may require separate analysis with a different conclusion.

I think it can be a sensible option: report to the user.

But I also think the different-scoped packets should not be qualified as 
an error in all cases.

Because we talk multiple cases:
- src LL dst GUA
- src LL dsr mcast-global
- src ULA dst GUA

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Jun 2016 15:57:57 +0200

> packet with source address set to '::'.

Well thank you for your interpretation.

I can live with it, but my interpretation is a bit different: packets 
with src :: should be allowed to traverse the Internet, if some admins 
so decide.  It would have some privacy advantages.

> routers route it between interfaces?

It should not be forbidden.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Jun 2016 16:06:44 +0200

> reverse-path-trees which totally break for LLA sources.

I think the reverse-path-trees are guided by the GUAs of the routers not 
of the end-user consumer of the content.  So yes, it should work.

> Hard to say, since I only have a link-local address as a source...

I see.  I can understand the wory.

But if there are too many of them you can set a firewall rule to block 
them, right?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Jun 2016 16:12:26 +0200

Le 04/06/2016 à 02:11, Owen DeLong a écrit :
>>>> A message of best-effort "beacon" semantics is sent by a device
>>>> to members of a global multicast group address.  Due to
>>>> peer-to-peer absence of authority it may be hard for the device
>>>> to configure and keep a GUA, and hard to inject a GUA in the
>>>> routing system too - hence it would use its LL as src.
>>>
>> Ok but please dont call that convoluted.  There is a strong
>> use-case for it and that's the potential solution.  If you can
>> think of other solution in which a "beacon" is sent to many
>> receivers away from the subnet, and which cant configure a GUA for
>> itself, then I am interested to hear.
>
> It’s ugly, it will probably get dropped, but at least the RFC’s don’t
> require it to get dropped as they do with LL.
>
> Frankly, I’m trying to understand the use case for such a beacon and
> how/why you have a device that can’t get a global address but has
> internet connectivity and it is escaping me. Perhaps with more detail
> about the nature of the thing that is beaconing and/or the
> environment in which it operates, other solutions could be proposed.

I guess yes.

The idea is for moving objects like cars approaching to other cars or 
moving together for a while.  They need to signal their presence 
somehow, and in some cases setting up networking first can take too much 
time.

Currently there are WSMP messages on top of a vehicle-specific WiFi 
(i.e. w/o IP) which achieve that: they broadcast their position 
everybody to everybody else.  It has some advantages but some 
inconvenients in terms of too much noise, scalability.

My idea would be to have IP Router Advertisements source with LL or :: 
and delivered to an IP multicast group with any scope.

>>> The packets I've seen are bog standard unicast ping or UDP 53
>>> (DNS request) packets.
>>
> Every router between the source and point where the packet was
> dropped is wrong (as well as the origin host).
>
> Not just the first hop, though if the first hop was right, the rest
> being wrong would be undetectable in this scenario.

Read.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Mon, 6 Jun 2016 08:03:00 -0700

At Fri, 3 Jun 2016 17:11:47 -0700,

> It’s ugly, it will probably get dropped, but at least the RFC’s don’t require it to get dropped as they do with LL.

(in case no one has pointed this out) I'd interpret the following text
of RFC4291 (or rfc4291bis for that matter) as "drop":

   An IPv6 packet with a
   source address of unspecified must never be forwarded by an IPv6
   router.

--
JINMEI, Tatuya

---

From: Owen DeLong <[email-masked]>
Date: Mon, 6 Jun 2016 09:46:15 -0700

> On Jun 6, 2016, at 06:55 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Much more acceptable. ULA can be routed among consenting parties. LL can not.

I’d still drop it at all my borders, so your packet wouldn’t see the light of
day if it tried to transit my network either way, but at least the ULA isn’t
a clear RFC violation and some people might forward it.

> or a ULA to still send packets to a group of interested parties.

There’s no such thing as a device which can’t configure a ULA.

A device which has only an LL address should, by definition, only be able
to communicate on-link and therefore should not generate a packet with a
scope greater than link.

>> case you describe is better handled using other mechanisms.

ULA, Fixing whatever is wrong with the device that it can’t get an address,
etc.

> But I also think the different-scoped packets should not be qualified as an error in all cases.
> 
		This is valid so long as the packet is not forwarded by a router to an interface
		other than the one on which it was received.

		Any attempt to leave the confines of the link is, in fact, an error.

> - src LL dsr mcast-global

		This packet should not be forwarded off link. Any attempt to do so is an error.

> - src ULA dst GUA

		There’s no real semantic difference between ULA and GUA other than some theoretical
		idea that most people should (and may well) block ULA by default at their borders.

		This is one of the reasons I really think ULA was a horrible idea from the start.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 6 Jun 2016 09:53:48 -0700

> On Jun 6, 2016, at 07:12 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> The idea is for moving objects like cars approaching to other cars or moving together for a while.  They need to signal their presence somehow, and in some cases setting up networking first can take too much time.

If setting up networking first takes too much time, then they must be on the same link, right? In that case, they can talk to each other within link scope.

> Currently there are WSMP messages on top of a vehicle-specific WiFi (i.e. w/o IP) which achieve that: they broadcast their position everybody to everybody else.  It has some advantages but some inconvenients in terms of too much noise, scalability.

Not to mention the security implications since implicit in what you describe is an almost total lack of meaningful authentication.

> My idea would be to have IP Router Advertisements source with LL or :: and delivered to an IP multicast group with any scope.

RAs by definition MUST be link scoped. An RA is only valid for the given link on which it is advertised.

RAs should always be LL sourced.

There is a standard multicast group for RAs to be sent to.

Cars not on the same link will need to depend on some router to forward the packets and if they’ve received an RA from a router on their link, then they have everything they need in order to set up an address very quickly. I think it’s far better for what you are describing to risk beaconing without completing DAD if you really need the beacon to reach another link (the need for this still escapes me in the scenario you describe), than to send out a packet with misaligned scopes expecting it to be routed based on the most permissive scope.

In short, IMHO, a router should process a packet based on the most restrictive scope of the {SRC,DST} address tuple. Therefore any packet with a LL address in either field should not be forwarded off-link.

ULA and GUA are both global scope addresses even though ULA has silly semantics overloaded on top of it by likely default policies in some routers.

>> being wrong would be undetectable in this scenario.

Not sure if this is an acknowledgement that you read what I wrote or an instruction that I should read your reply.

In either case, I have read your reply, I have rebutted it above. My opinion on the matter is unchanged.

Owen

---

From: Gert Doering <[email-masked]>
Date: Mon, 6 Jun 2016 19:45:41 +0200

Hi,

> of the end-user consumer of the content.  So yes, it should work.

Don't "think".  Try to understand what "reverse-path" is supposed to
mean: the path where a packet destined to the source of the packet in
question will be sent to.

Note there is no path for LLAs.

Guess what?

Right.

[..]
> But if there are too many of them you can set a firewall rule to block 

Totally missing the point.  This thread happens *because* some of us use
firewall rules to block stuff at our borders that is not supposed to show
up there, and we found that it *does* show up.

So there *is* a firewall rule, and it demonstrates misbehaviour of hosts and
routers.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jun 2016 12:17:05 +0200

Le 06/06/2016 à 18:46, Owen DeLong a écrit :
>
>> On Jun 6, 2016, at 06:55 , Alexandre Petrescu
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>> On Jun 3, 2016, at 04:24 , Alexandre Petrescu
>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> Internet" with LL source address and GUA dst address. This
>>>>> seems to be a direct violation of
>>>> A message of best-effort "beacon" semantics is sent by a
>>>> device to members of a global multicast group address.  Due to
>>>> peer-to-peer absence of authority it may be hard for the
>>>> device to configure and keep a GUA, and hard to inject a GUA in
>>>> the routing system too - hence it would use its LL as src.
>>>
>>> This is unacceptable behavior. It would be better for such a
>>> device to cobble together its own ULA for this purpose than to
>>> use its LL as source.
>>
>> But that would create a packet with src ULA and dst GUA.  Would
>> that be more acceptable than src LL and dst GUA?
>

Noted.

>
> I’d still drop it at all my borders, so your packet wouldn’t see the
>  light of day if it tried to transit my network either way, but at
> least the ULA isn’t a clear RFC violation and some people might
> forward it.
>
>>> No multicast packet with a scope greater than LINK should be
>>> sourced from an LL address.
>>>
>>> I don’t know if the RFCs clearly state that, but I would argue
>>> that if they don’t say that yet, they certainly should.
>>
>> There should be a possibility for a device which can't configure a
>> GUA or a ULA to still send packets to a group of interested
>> parties.
>

I agree.

But the problem is two different devices meeting and each configuring an
ULA within the same prefix.  Each device may make its own random ULA but
there will be little chance they have the same prefix.  So they couldnt
communicate using these ULAs.

The ULAs may be needed (rather than link-local address) because devices
need to send packets through multiple IP subnets formed by these pairs
of devices.

On another hand, if only the LL-address was used and the dst was a
multicast group with any scope (global or LL) then there would be no
need to form ULAs at all.

> A device which has only an LL address should, by definition, only be
> able to communicate on-link and therefore should not generate a
> packet with a scope greater than link.

I think I could agree - it can make sense, but that is a definition that
is not present in some document.

>>>> I dont think there is any other IP mechanism for such a device
>>>> to beacon its message across subnets, but to src==LL and
>>>> dst==global-mcast.
>>>>
>>>> Given that, while I would agree to a common practice of
>>>> same-scoped src and dst fields in same IPv6 header I would
>>>> consider the exceptions too.
>>>
>>> Making an exception here is silly. It invites mischief and the
>>> use case you describe is better handled using other mechanisms.
>>
>> Which ones?
>
> ULA, Fixing whatever is wrong with the device that it can’t get an
> address, etc.

Absent the authority of fixed infrastructure it can be very difficult to
make mobile devices get an address.

[...]

>> Because we talk multiple cases: - src LL dst GUA
>
> This is valid so long as the packet is not forwarded by a router to
> an interface other than the one on which it was received.
>

It sounds like the forwarding operation should look at the src address 
in order to avoid that error - but typical forwarding operations only 
consider the dst, not the src of a packet.

Ingress filtering is something applied by some operator networks, but 
it's an exception.

>> - src ULA dst GUA
>
> There’s no real semantic difference between ULA and GUA other than
> some theoretical idea that most people should (and may well) block
> ULA by default at their borders.
>

Noted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jun 2016 12:18:55 +0200

Le 06/06/2016 à 17:03, 神明達哉 a écrit :
> At Fri, 3 Jun 2016 17:11:47 -0700, Owen DeLong <[email-masked]>
> wrote:
>
>>> receivers away from the subnet, and which cant configure a GUA
>>> for itself, then I am interested to hear.
>>
>> It’s ugly, it will probably get dropped, but at least the RFC’s
>> don’t require it to get dropped as they do with LL.
>
> (in case no one has pointed this out) I'd interpret the following
> text of RFC4291 (or rfc4291bis for that matter) as "drop":
>
> An IPv6 packet with a source address of unspecified must never be
> forwarded by an IPv6 router.

I wonder why so.  Is this maybe to solve a security issue?

I think it is not good to set this in stone, because there can be 
applications taking advantage of sending packets w/o specifying their 
src address.

Alex

> -- JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jun 2016 12:25:35 +0200

Le 06/06/2016 à 18:53, Owen DeLong a écrit :
>
>> On Jun 6, 2016, at 07:12 , Alexandre Petrescu
>>>> On Jun 3, 2016, at 11:50 , Alexandre Petrescu
>>>>>> device to members of a global multicast group address.
>>>>>> Due to peer-to-peer absence of authority it may be hard for
>>>>>> the device to configure and keep a GUA, and hard to inject
>>>>>> a GUA in the routing system too - hence it would use its
>>>>>> LL as src.
>>>>>
>>> Frankly, I’m trying to understand the use case for such a beacon
>>> and how/why you have a device that can’t get a global address
>>> but has internet connectivity and it is escaping me. Perhaps
>>> with more detail about the nature of the thing that is beaconing
>>> and/or the environment in which it operates, other solutions
>>> could be proposed.
>>
>> I guess yes.
>>
>> The idea is for moving objects like cars approaching to other cars
>> or moving together for a while.  They need to signal their presence
>> somehow, and in some cases setting up networking first can take too
>> much time.
>
> If setting up networking first takes too much time, then they must
> be on the same link, right? In that case, they can talk to each
> other within link scope.

Yes, pairs of cars can talk to each other easily within their respective
link scopes.  But sending an IP message across an entire traffic jam
(w/o going to infrastructure), can be difficult if the cars dont forward.

> Not to mention the security implications since implicit in what you
> describe is an almost total lack of meaningful authentication.

Yes, I agree.

>
>> My idea would be to have IP Router Advertisements source with LL
>> or :: and delivered to an IP multicast group with any scope.
>
> Cars not on the same link will need to depend on some router to
> forward the packets and if they’ve received an RA from a router on
> their link, then they have everything they need in order to set up
> an address very quickly.

Sounds easy, but consider this: should a car configure an address from a
received RA?  Or should it advertise an RA to the other car so the
_other_ car configures an address from its RA?

> I think it’s far better for what you are describing to risk beaconing
> without completing DAD if you really need the beacon to reach another
> link (the need for this still escapes me in the scenario you
> describe), than to send out a packet with misaligned scopes expecting
> it to be routed based on the most permissive scope.

I can agree, provided there can be a notion of 'authorized' car when two 
cars meet.  Typically it's hard to decide which one is more authorized 
than the other to.

With two cars arriving at an intersection there is this notion of 
priority, or 'give way', so we could decide which car derives an address 
from which prefix.

But two cars following each other it's hard to say who sends the RA and 
who configures an address.

> In short, IMHO, a router should process a packet based on the most
> restrictive scope of the {SRC,DST} address tuple. Therefore any
> packet with a LL address in either field should not be forwarded
> off-link.

Noted.

> ULA and GUA are both global scope addresses even though ULA has silly
> semantics overloaded on top of it by likely default policies in some
> routers.

Noted.

>>> Not just the first hop, though if the first hop was right, the
>>> rest being wrong would be undetectable in this scenario.
>>
>> Read.
>
> Not sure if this is an acknowledgement that you read what I wrote or
> an instruction that I should read your reply.

It's an ack: I read, past tense.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jun 2016 12:36:21 +0200

Le 06/06/2016 à 19:45, Gert Doering a écrit :
>>> If you want to communicate with off-net machines and have no GUA,
>>> that situation *is* convoluted.  Or one could say I would be
>>> surprised if it works at all, given that multicast routing
>>> usually relies on reverse-path-trees which totally break for LLA
>>> sources.
>>
>> I think the reverse-path-trees are guided by the GUAs of the
>> routers not of the end-user consumer of the content.  So yes, it
>> should work.
>
> mean: the path where a packet destined to the source of the packet
> in question will be sent to.

It's hard to parse: a packet is not sent to a path, but to a
destination.  What do you mean?

I still think it's possible to have multicast trees with neighboring
routers using only link-local addresses, and through different IP
subnets.  Neighboring routers in a multicast tree can identify each
other only by their respective link-local address.

The dynamic construction of a multicast tree can happen without need of
GUAs or ULAs (LLs are sufficient), provided the protocol uses
link-scoped advertisements containing distance vectors.

(of course assuming the LL addresses are globally unique like when
derived from IEEE MAC addresses, or from random numbers).

Alex

>> But if there are too many of them you can set a firewall rule to
>> block them, right?
>
> Totally missing the point.  This thread happens *because* some of us
> use firewall rules to block stuff at our borders that is not supposed
> to show up there, and we found that it *does* show up.
>
> So there *is* a firewall rule, and it demonstrates misbehaviour of
> hosts and routers.
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Jun 2016 21:13:49 +0200

> then that sounds more like a corner case bug.

Why so? If anything, that'd only be a bug if the node was employing
GSTM. Besides strictly speaking there's no default Hop Limit -- so 255
might be employd as the default,  and hence receiving something that
"was decremented from 255" could be the rule rather than the exception.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Jun 2016 21:15:58 +0200

> A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived.

Actually, it shouldn't forward such packets no matter what.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Jun 2016 09:31:18 -0700

At Wed, 8 Jun 2016 12:18:55 +0200,

> applications taking advantage of sending packets w/o specifying their

I don't remember why.  It was first introduced in RFC3513, so if you
want to overturn it, you might want to delve into the discussion at
that time to figure out the "why" and write a new draft proposing an
update on top of the understanding.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Jun 2016 10:12:49 -0700

At Tue, 7 Jun 2016 21:15:58 +0200,

> Actually, it shouldn't forward such packets no matter what.

Do you mean in your opinion, or per the protocol specification?  If
you meant the latter, it's not really correct.  See, for example, the
following part of Section 9 of RFC4007:

   [...] if a
   router receives a packet with a link-local destination address that
   is not one of the router's own link-local addresses on the arrival
   link, the router is expected to try to forward the packet to the
   destination on that link (subject to successful determination of the
   destination's link-layer address via the Neighbor Discovery protocol
   [9]).  The forwarded packet may be transmitted back through the
   arrival interface, or through any other interface attached to the
   same link.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Jun 2016 08:53:04 +1200

> Actually, it shouldn't forward such packets no matter what.

Surely there could be NBMA links where a router needs to forward LL
packets among neighbors?

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Jun 2016 23:00:22 +0000

Hi Brian,

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, June 08, 2016 1:53 PM
> To: Fernando Gont <[email-masked]>; Owen DeLong <[email-masked]>; Mikael Abrahamsson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [v6ops] Packets with LL src and GUA dst
> 

Yes, that happens on AERO links. But, the hop-limit is not decremented.

Thanks - Fred
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jun 2016 10:43:32 +1000

> Yes, that happens on AERO links. But, the hop-limit is not decremented.

RFC4007,

"Thus, if a
   same link."

I'd expect the hop-limit to be decremented.

I'm pretty sure that the ND packets which start with HL of 255, and
would be dropped if the HL doesn't arrive as 255, would not be
impacted because they're specifically not to be forwarded, even back
onto the same link.

(The above is what would allow "Indicating Link-Local Unicast
Destinations are Off-Link" (draft-smith-6man-link-locals-off-link) to
work.)

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Jun 2016 09:25:08 +0200

> Actually, it shouldn't forward such packets no matter what.

I dont know how would that be implemented other than by looking at the 
src address.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Jun 2016 09:26:53 +0200

> update on top of the understanding.

Tatuya,

Thanks for the suggestion.

I did not know RFC 3513 was the place where this was first specified.

I will think about writing a draft.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Jun 2016 10:19:05 +0200

>update on top of the understanding.

I wonder how (forwarding of packets with LL or unspecified source across
admin boundaries) would interact with BCP38.

An exception for packet-to-big error ICMPs is easy enough to specify,
but may be very costly to enforce at a border routers.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jun 2016 14:45:48 +0000

Hi Mark,

> From: Mark Smith [mailto:[email-masked]]
> Sent: Wednesday, June 08, 2016 5:44 PM
> To: Templin, Fred L <[email-masked]>
> Cc: Brian E Carpenter <[email-masked]>; Fernando Gont <[email-masked]>; Owen DeLong
> <[email-masked]>; Mikael Abrahamsson <[email-masked]>; [email-masked]

The key text in the above passages is "may be transmitted back through
the arrival interface, or through any other interface attached to the same
link". This means that the packet with LL source address never really leave
the link they arrived on. Instead, they are "hairpinned" either at the IP
or sub-IP layers. So, the hop-limit should not be decremented.

This leaves the question as to what to do about loops, since a packet with
a non-decrementing hop-limit could potentially loop forever. The only
answer that makes sense is to engineer the link so that no loops will
ever be possible such as in AERO.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Jun 2016 10:24:43 -0700

At Thu, 9 Jun 2016 14:45:48 +0000,

> or sub-IP layers. So, the hop-limit should not be decremented.

I'm pretty sure that the original intent of this text is to mean this
"forwarding" to be just like other normal cases, i.e., forwarding a
packet received on one interface to one link to another interface to
another link.  Or, just like the case where a default router is not
the best path to an off-link destination and the best next hop is in
the same link as the receiving link (in that case the receiving router
will transmit the packet back through the arrival interface, possibly
sending a neighbor discovery redirect).  So I'm pretty sure that the
hop-limit is assumed to be decremented.  Saying "should not be
decremented" based on this RFC text is most likely to be a
misinterpretation.

Whether such a behavior is justified for some special cases can be a
different question, but that shouldn't automatically apply to the
general case described in this RFC.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jun 2016 18:09:04 +0000

Hi,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Thursday, June 09, 2016 10:25 AM
> Cc: Mark Smith <[email-masked]>; [email-masked]; Fernando Gont <[email-masked]>

This got started in response to Brian Carpenter's statement that:

  "Surely there could be NBMA links where a router needs to forward LL
   packets among neighbors?"

where Brian was referring to neighbors *on the same link*. I responded
that that is exactly the case for AERO.

It seems to me that forwarding LL packets between neighbors on the
same link is a sub-IP activity that *should not* result in decrementing
the hop-count. On the other hand, forwarding packets between
nodes on different links is an IP activity that *should* result in
decrementing the hop (or maybe there are other considerations
for entities like ND Proxys).

Thanks - Fred

---

From: Owen DeLong <[email-masked]>
Date: Thu, 9 Jun 2016 14:14:38 -0400

> On Jun 8, 2016, at 16:53, Brian E Carpenter <[email-masked]> wrote:
> 

Yes... That's why there's an exemption for "on the same link". 

Owen

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Jun 2016 11:23:25 -0700

At Thu, 9 Jun 2016 18:09:04 +0000,

[...]
> for entities like ND Proxys).

I don't know if there's any RFC that justifies this interpretation,
but my main point is that it's not appropriate to try to justify it by
referring to RFC 4007 (such as by citing the text "may be
transmitted..."  and interpreting it in favor of your preferred
behavior).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Jun 2016 22:09:32 +0200

> general case described in this RFC.

To clarify my position: the _general_ case is that a router forwards 
without looking at the source address at all.

The rest are particular cases.

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Jun 2016 06:41:49 +1000

Hi Fred,

> or sub-IP layers. So, the hop-limit should not be decremented.

I should have realised the place to look. RFC2460/RFC2460bis says for
the Hop Limit field that it is "Decremented by 1 by each node that
forwards the packet."

The above RFC4007 text is from a section titled to "Forwarding", so I
think the HL should be decremented per RFC2460, even when being
forwarded back onto the same link.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jun 2016 21:19:22 +0000

Hi Mark,

> the Hop Limit field that it is "Decremented by 1 by each node that

It depends on what you mean by "forwarding". The RFC2460 text is referring
to forwarding *at the IP layer*. In response to Brian's question, I answered
that AERO (and probably other NBMA link types) forward LL packets *at the
sub-IP layer*. Meaning, the packets never leave the interface they are received
on and get hairpinned out to the next hop without ever popping up to the IP
 layer. In that case, since the IP layer never handles them, the hop-limit is
unchanged. I should have left it at that and not tried to extrapolate to the
case of the packet popping up to the IP layer, but thanks for the clarification.

Fred

> Sent: Thursday, June 09, 2016 1:42 PM

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Jun 2016 11:21:29 +1000

On 10 Jun 2016 7:19 AM, "Templin, Fred L" <[email-masked]> wrote:
> to forwarding *at the IP layer*.

Right. People were saying that LL addressed packets should never be
forwarded, and I think they were talking about layer 3 forwarding of them.
I was pointing out that they can be as per-RFC4007, limited to back on to
the link they came from.

Regards,
Mark.

>In response to Brian's question, I answered
> sub-IP layer*.
Meaning, the packets never leave the interface they are received
> > >> >> To: Fernando Gont <[email-masked]>; Owen DeLong <
[email-masked]>; Mikael Abrahamsson
> > <[email-masked]>
> > >> >> >> A device should not forward a packet with LL source or
destination address to any port other than the port on which it
> > arrived.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Jun 2016 10:13:46 -0700

At Fri, 10 Jun 2016 11:21:29 +1000,

> I was pointing out that they can be as per-RFC4007, limited to back on to

As far as I understand it RFC4007 only talks about "layer 3
forwarding".  We can freely discuss whether there's such a concept as
"forwarding sub-IP layer" and/or whether the hop limit should be
decremented in that case, but RFC4007 should be independent from that
discussion.

--
JINMEI, Tatuya

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jun 2016 10:41:58 -0700

On 6/10/2016 10:13 AM, 神明達哉 wrote:
> forwarding". 
In IETF terminology, I have always understood "forwarding" to be the
more common term used only for layer-3 relaying.

>  We can freely discuss whether there's such a concept as
> "forwarding sub-IP layer" 

In IETF terminology, I have always understood that to be more commonly
called "switching".

> and/or whether the hop limit should be

The hop should be decremented only at the layer where relaying occurs,
be that application (web proxying), transport, network, or link (where
that layer has a hop count to decrement, of course).

Any other decrement ends up defeating the purpose of layering, to
isolate one layer's properties from another.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jun 2016 18:32:41 +0000

Hi Joe,

> From: v6ops [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Friday, June 10, 2016 10:42 AM
> To: 神明達哉 <[email-masked]>; Mark Smith <[email-masked]>
> Cc: [email-masked]; Fernando Gont <[email-masked]>

The term "switching" does not fit well with my observations of how sub-IP
layer forwarding works on AERO links. The LL packet comes into the AERO
interface and a sub-IP layer forwarding table directs that it be sent on to a
different neighbor instead of being passed up to the IP layer. "Sub-IP
layer forwarding" is the terminology that I think best conveys the concept
as I have observed it.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jun 2016 11:50:42 -0700

> layer forwarding" is the terminology that I think best conveys the concept

The trouble is that we have too many terms:

    switching
    relaying
    forwarding

All of these could generically be used to describe nearly any case.
Switching just means there's a decision of multiple outputs, which may
or may not occur (e.g., you can forward to different nodes on a LAN but
still use only one output port to that LAN). Both relaying and
forwarding refer to transiting a message.

All of them can use tables to govern the decisions made.

Again, my view is that *typically* when the term "forwarding" is used
without additional clarification, it refers to the IP layer, and when
"switching" is used it refers to the link layer.

It's always best to be more specific when there are ambiguities, though.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jun 2016 19:01:41 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, June 10, 2016 11:51 AM
> To: Templin, Fred L <[email-masked]>; 神明達哉 <[email-masked]>; Mark Smith <[email-masked]>

What happens with AERO is that a tunneled packet comes in from an
underlying network interface and gets sucked up by an application that
also configures a TUNTAP interface. The application peeks at information
inside the encapsulated packet and decides whether to pass it up to the
local IP layer via the TUNTAP interface, or send it back out an underlying
network interface to another neighbor without disturbing the local IP layer.

This latter behavior is what I am seeking to name. In my mind, "switching"
does not sound right. "Sub-IP layer forwarding" sounds right, but to a
certain extent so does "relaying".

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jun 2016 12:28:05 -0700

On 6/10/2016 12:01 PM, Templin, Fred L wrote:
> also configures a TUNTAP interface.
It's largely an implementation artifact as to whether this happens
inside a driver, elsewhere in the OS, or at the application layer using
TUNTAP.

> The application peeks at information

You're using IP to make decisions. That's IP forwarding.

The fact that you don't disturb the layers in which IP is encapsulated
is an implementation artifact - you could easily strip off those headers
and put them back as needed.

I.e., when an ethernet switch decides where a packet goes by it's IP
payload address, I call that forwarding, not "ethernet switching with DPI".

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jun 2016 19:44:50 +0000

Hi Joe,

> Sent: Friday, June 10, 2016 12:28 PM

It is an implementation artifact, yes, and it can also be done inside a network
driver true. The driver sits between the physical layer and the IP layer. In
what I described with my app using TUNTAP, the app itself is behaving as
if it is a network driver.

> You're using IP to make decisions. That's IP forwarding.

I am sitting inside the network driver and peeking at information inside
the next layer header, true. That information includes IP addresses,
true. But, the network driver never passing the packet up to the IP layer.
Instead, the network driver pushes it back down to the physical media
where it will be conveyed to a different AERO interface neighbor.

> and put them back as needed.

AERO has a notion of "re-encapsulation" (which I think is the same as
what the LISP guys call it). In "re-encapsulation", the L2 header is replaced
with a different L2 header but the IP header remains unchanged (i.e., and
not even the hop-limit/TTL gets decremented).

In the process, however, the L2 header hop-limit/TTL gets decremented;
otherwise, we could hit an interminable loop. But, the IP hop-limit/TTL is
unchanged.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jun 2016 13:28:43 -0700

On 6/10/2016 12:44 PM, Templin, Fred L wrote:

...
> true. But, the network driver never passing the packet up to the IP layer.
The IP layer is whatever layer looks at IP and makes decisions.

I think you're trying to differentiate your mechanism from that in the
OS, but that too is just an implementation choice.

Here's an example where the packets stay on the network card and just
the headers get passed around to figure out what happens - it's still IP
forwarding, though:

S. Walton, A. Hutton, and J. Touch, “High-Speed Data Paths in Host-Based
Routers <http://www.isi.edu/touch/pubs/computer-peer98.pdf>,” /IEEE
Computer/, Nov. 1998, pp. 46-52.

...
> otherwise, we could hit an interminable loop. But, the IP hop-limit/TTL is

If you change L2 headers without affecting the IP header, you're trying
to make two different "subnets" (as RFC 3819) act like one logical
subnet to IP:

   This document defines a subnetwork as a layer 2 network, which is a
   network that does not rely upon the services of IP routers to forward
   packets between parts of the subnetwork.  However, IP routers may
   bridge frames at Layer 2 between parts of a subnetwork.  Sometimes,
   it is convenient to aggregate a group of such subnetworks into a
   single logical subnetwork. 

The fact that you use L3 to make decisions is - I suspect - an
optimization at that point. You probably could have used just L2 to make
these decisions if you wanted.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jun 2016 20:40:57 +0000

Hi Joe,

>    However, IP routers may

AERO is a segmented link that is patched together by forwarding nodes into
a single logical link. So, the above text rings true to what is happening with
AERO, yes.

Thanks - Fred

Sent: Friday, June 10, 2016 1:29 PM

...

I think you're trying to differentiate your mechanism from that in the OS, but that too is just an implementation choice.

Here's an example where the packets stay on the network card and just the headers get passed around to figure out what happens - it's still IP forwarding, though:

S. Walton, A. Hutton, and J. Touch, “High-Speed Data Paths in Host-Based Routers,” IEEE Computer, Nov. 1998, pp. 46-52. 

...

If you change L2 headers without affecting the IP header, you're trying to make two different "subnets" (as RFC 3819) act like one logical subnet to IP:

The fact that you use L3 to make decisions is - I suspect - an optimization at that point. You probably could have used just L2 to make these decisions if you wanted.

Joe

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Jun 2016 10:50:06 +1000

> decremented in that case, but RFC4007 should be independent from that

So how can it not be layer 3 forwarding if the device is looking at layer 3
addresses and acting on them?

This seems to have wandered off topic - it was about whether a packet with
a LL src and a GUA dst should be (layer 3) forwarded by a router.

I think the should be able to be, as long as the LL src and GUA dst are on
the same (rfc2460) link, meaning the packet is forwarded back onto the link
it came from (via same or different attached interface). It should be
dropped otherwise.

Same with LL dst. - forwarded back onto same link as per RFC4007.

These forwarding checks may be hard/expensive or impossible to implement on
fast forwarding hardware, which is why these packets are leaking.

I think LL src. and GUA dst. are currently technically legitimate packets.
The origin host has somehow got a GUA dst (probably AAAA lookup over IPv4),
doesn't have anything but a LL address to use as a source because LLs are
autoconfigured and it has no other IPv6 addresses to use as a src.

In theory, the host shouldn't send unless the GUA is known to be on-link,
however the host doesn't know, has a default router somehow (e.g. RA with
no PIOs), so assumes that the default router will know better as per
RFC5942 (all dsts are off-link by default except LLs).

In these cases the router(s) along the path are not doing any source
address validation, which is how packets with LL src. are making it to the
GUA dst.

Other than the router(s) not performing a source address check for LL
sources and dropping if the dst is not on the same link it came from, I
think all other behavior that is allowing this to happen is legitimate and
has some valid use cases so shouldn't be changed.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jun 2016 18:07:13 -0700

On 6/10/2016 5:50 PM, Mark Smith wrote:
>
> So how can it not be layer 3 forwarding if the device is looking at
> layer 3 addresses and acting on them?
>

The key is whether:

a) looking at L3 addresses is strictly required, or simply a convenience
to avoid maintaining a larger set of L2 tables

b) whether the goal is to appear to L3 as a subnet or not

You can always deliberately try to act like a single IP subnet *if you
want to*.

Joe

---

From: Owen DeLong <[email-masked]>
Date: Sun, 12 Jun 2016 16:31:53 -0700

> On Jun 9, 2016, at 13:09 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> To clarify my position: the _general_ case is that a router forwards without looking at the source address at all.

Inappropriate behavior in IPv6, as the router is required not to forward packets with LL Source Addresses to interfaces that are not on the same link as the arriving interface.

Owen

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Owen DeLong <[email-masked]>
Date: Sun, 12 Jun 2016 16:33:43 -0700

Fred,

FWIW, I think that the consequences of not decrementing the hop limit when doing in-link
forwarding at a router are too great to justify your proposed interpretation.

Such a router is very unlikely to forward BPDUs on the same path and therefore, you may
end up with a hybridized loop where your “sub-layer 3” forwarding is taking place along
a path that doesn’t do “layer 2” forwarding. This would be, IMHO, bad.

The behavior should be consistent at each layer.

Owen

> On Jun 9, 2016, at 14:19 , Templin, Fred L <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jun 2016 15:11:34 +0000

Hi Owen,

Thanks - Fred

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Sunday, June 12, 2016 4:34 PM
> Cc: Mark Smith <[email-masked]>; Brian E Carpenter <[email-masked]>; Fernando Gont
> <[email-masked]>; Mikael Abrahamsson <[email-masked]>; [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Jun 2016 08:37:59 -0700

Hi, all,

To be clear on my text:

Bridging different L2 subnets into a single logical subnet isn't a
required *router* function.

A device operating in that way is acting as an L2 switch/bridge, not an
L3 router. Yes, some L3 routers include L2 capabilities, though. Some
such devices use L3 headers to help determine which L2 addresses are
part of the same logical subnet, but that's a convenience and shouldn't
be a requirement either.

Joe

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Jun 2016 12:02:01 -0700

At Sat, 11 Jun 2016 10:50:06 +1000,

> addresses and acting on them?

It can't.  I believe we're on the same page on that point.  I just
wanted to make it clear that text in RFC4007 can't be used to justify
some odd behavior unrelated to layer 3 (e.g., "skip decrementing hop
limit because it's 'sub-layer3 forwarding' - no part of the RFC4007
text talks about such things).

> a LL src and a GUA dst should be (layer 3) forwarded by a router.

Right, whether/how packets whose dest is LL was completely off topic
of the original thread (I don't think it was me who introduced this
distraction, though:-).

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jun 2016 19:22:17 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of ????
> Sent: Monday, June 13, 2016 12:02 PM
> To: Mark Smith <[email-masked]>
> Cc: v6ops list <[email-masked]>; Fernando Gont <[email-masked]>

Yes it can, per Joe's explanation. This has nothing to do with RFC4007,
which I never cited.

> of the original thread (I don't think it was me who introduced this

Brian asked about NBMA links; AERO is NBMA.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Jun 2016 13:13:10 -0700

On 6/13/2016 12:02 PM, 神明達哉 wrote:
> It can't. 
A device can look at whatever it wants (or at least has access to).

What matters is how it behaves.

A device that deliberately doesn't decrement the IP hopcount is
intending to make two subnets act like one to IP. It doesn't matter what
it looks at or whether it preserves L2 headers. To *IP*, the result is
(or ought to be) indistinguishable from a single L2 subnet.

The rest is irrelevant - i.e., how it decides which to subnets to
combine, etc.

However - that behavior ends up making the device look like it's an L2
switch, not an IP router. That behavior is not what is expected of an IP
router, but those devices do a lot of things that they're neither
expected nor desired to do.

Joe

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Jun 2016 13:15:32 -0700

At Mon, 13 Jun 2016 19:22:17 +0000,

> Yes it can, per Joe's explanation. This has nothing to do with RFC4007,

Regarding the (ir)relevance of RFC4007, I specifically meant this
comment:
http://www.ietf.org/mail-archive/web/v6ops/current/msg24765.html

>> or sub-IP layers. So, the hop-limit should not be decremented.

To me, this could read as if you cited RFC4007 (the double-quoted
part) and used that text to justify skipping decrementing the hop
limit.  All I've been trying to do is to clarify that RFC4007
shouldn't be interpreted that way.  If, in this comment, you didn't
actually intend to cite RFC4007 or didn't mean to use it as a
justification for the sub-IP layer things, that's fine (although in
that case you might not copy the RFC4007 text with the
double-quotations).  I just wanted to make it very clear it's not
misunderstood.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jun 2016 20:32:38 +0000

Hi,

> Sent: Monday, June 13, 2016 1:16 PM
> Cc: Mark Smith <[email-masked]>; v6ops list <[email-masked]>; Fernando Gont <[email-masked]>

OK, I understand now. Yes, per the message you quoted above it could read
as if I was citing RFC4007. But, very soon after that message Mark Smith posted
a correction and I acknowledged and thanked him for the clarification:

https://www.ietf.org/mail-archive/web/v6ops/current/msg24773.html
https://www.ietf.org/mail-archive/web/v6ops/current/msg24774.html

Since then, none of my posts have been intended in the spirit of the
RFC4007 text. Sorry for any confusion.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Jun 2016 10:32:11 +0200

Le 13/06/2016 à 01:31, Owen DeLong a écrit :
>
>> On Jun 9, 2016, at 13:09 , Alexandre Petrescu
>>> At Thu, 9 Jun 2016 14:45:48 +0000, "Templin, Fred L"
>>> <[email-masked] <mailto:[email-masked]>>
>>> wrote:
>>>
>>>>> RFC4007,
>>>>>
>>>>>
>>>>> "Thus, if a router receives a packet with a link-local
>>>>> destination address that is not one of the router's own
>>>>> link-local addresses on the arrival link, the router is
>>>>> expected to try to forward the packet to the destination on
>>>>> that link (subject to successful determination of the
>>>>> destination's link-layer address via the Neighbor Discovery
>>>>> protocol [9]).  The forwarded packet may be transmitted back
>>>>>  through the arrival interface, or through any other
>>>>> interface attached to the same link."
>>>>>
>>>> The key text in the above passages is "may be transmitted back
>>>>  through the arrival interface, or through any other interface
>>>>  attached to the same link". This means that the packet with LL
>>>>  source address never really leave the link they arrived on.
>>>> Instead, they are "hairpinned" either at the IP or sub-IP
>>>> layers. So, the hop-limit should not be decremented.
>>>
>>> I'm pretty sure that the original intent of this text is to mean
>>>  this "forwarding" to be just like other normal cases, i.e.,
>>> forwarding a packet received on one interface to one link to
>>> another interface to another link.  Or, just like the case where
>>>  a default router is not the best path to an off-link destination
>>>  and the best next hop is in the same link as the receiving link
>>>  (in that case the receiving router will transmit the packet back
>>>  through the arrival interface, possibly sending a neighbor
>>> discovery redirect).  So I'm pretty sure that the hop-limit is
>>> assumed to be decremented.  Saying "should not be decremented"
>>> based on this RFC text is most likely to be a misinterpretation.
>>>
>>> Whether such a behavior is justified for some special cases can
>>> be a different question, but that shouldn't automatically apply
>>> to the general case described in this RFC.
>>
>> To clarify my position: the _general_ case is that a router
>> forwards without looking at the source address at all.
>
> Inappropriate behavior in IPv6, as the router is required not to
> forward packets with LL Source Addresses to interfaces that are not
> on the same link as the arriving interface.

In IPv6 this restriction is put on a router receiving a packet with LL
src address.

In IPv4 RFC3927 LLs this restriction is put on a Host wishing to send
such a packet - it should not send it to a router for forwarding (use
directly ARP search instead of rt table search first).

In IPv4 that spec is silent about a _router_ sending packets with LL src
address.  So one can easily  assume that an IPv4 router is allowed to
send a packet with LL src address to another router.

IPv4 behaviour is allowed to act this way and IPv6 should be the same if
it wanted to be an easy migration target.

Alex

>>> _______________________________________________ v6ops mailing
>>> list [email-masked] <mailto:[email-masked]>
>> _______________________________________________ v6ops mailing list

---

From: Gert Doering <[email-masked]>
Date: Wed, 15 Jun 2016 11:40:24 +0200

Hi,

> send a packet with LL src address to another router.

BCP38

Gert Doering
        -- NetMaster

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Jun 2016 12:25:52 +0200

> send a packet with LL src address to another router.

https://tools.ietf.org/html/rfc3927#page-25
"

Router Considerations

   A router MUST NOT forward a packet with an IPv4 Link-Local source or
   destination address, irrespective of the router's default route
   configuration or routes obtained from dynamic routing protocols.

   A router which receives a packet with an IPv4 Link-Local source or
   destination address MUST NOT forward the packet.  This prevents
   forwarding of packets back onto the network segment from which they
   originated, or to any other segment."

> it wanted to be an easy migration target.

Doing the wrong things in IPv6 only because 'it worked like that in
IPv4' does not sound like a very good idea to me.

In general, packets must have source address which makes sense and
allows identifying a path back to the packet sender. (The only
exception is a packet with undefined address but there is at least L2
address, and such packets are not allowed outside of the link -
exactly for that reason). That's why multicast sources are not
allowed. Allowing packets with unidentifiable sources is a very
slippery slope -
from various perspective, including (but not limited to) security concerns.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Jun 2016 13:03:39 +0200

Le 15/06/2016 à 12:25, Jen Linkova a écrit :
>> In IPv6 this restriction is put on a router receiving a packet
>> with LL src address.
>>
>> In IPv4 RFC3927 LLs this restriction is put on a Host wishing to
>> send such a packet - it should not send it to a router for
>> forwarding (use directly ARP search instead of rt table search
>> first).
>>
>> In IPv4 that spec is silent about a _router_ sending packets with
>> LL src address.  So one can easily  assume that an IPv4 router is
>> allowed to send a packet with LL src address to another router.
>
> https://tools.ietf.org/html/rfc3927#page-25 "
>
> Router Considerations
>

Ah right, I did not see it.  So IPv4 does not stand as a reason -
it's the same in IPv4 and IPv6.

>> IPv4 behaviour is allowed to act this way and IPv6 should be the
>> same if it wanted to be an easy migration target.
>
> allows identifying a path back to the packet sender.
>
> (The only exception is a packet with undefined address but there is
> at least L2 address, and such packets are not allowed outside of the
> link - exactly for that reason). That's why multicast sources are not
> slippery slope - from various perspective, including (but not
> limited to) security concerns.

I read.

You know I disagree it's a slippery slope.

I will come back later on this need.

Alex

---

From: Musa Stephen Honlue <[email-masked]>
Date: Wed, 15 Jun 2016 23:28:28 +0400

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.

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.

Stephen.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jun 2016 08:20:22 +1000

On 16 June 2016 at 05:28, Musa Stephen Honlue <[email-masked]> wrote:
> off-link destinations),

This actually contradicts the IPv6 subnet model, described in RFC5942.

With exception to Link-Local destinations, hosts are not to assume a
destination is on-link, unless they've been informed that the prefix
is on-link, by receiving a RA PIO covering the destination with the
on-link/L-bit set.

This makes sense, it supports a hub-and-spoke rather than a direct
node-to-node forwarding model within the subnet, with the router(s) on
the link being the first hop for all (non-LL) destinations, rather
than direct sending to other hosts attached to the link and using a
router to reach off-link destinations.

Terminology might be a bit confusing, "dumb" hosts consider all
destinations (excepting LLs) "off-link", so they use a router to reach
them, where as the "smarter" router knows that some of the
destinations are on-link, and forwards to them. The router would not
issue redirects for those on-link destinations to the sending hosts.

(Too late to change it now, however "on-link" and "off-link" might
have better been something like "directly-reachable" and
"router-reachable")

Regards,
Mark.

> and for intermediary routers(they should not forward
> packet sourced with LLA).
>
> 2016-06-15 15:03 GMT+04:00 Alexandre Petrescu
> <[email-masked]>:
>>
>>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Jun 2016 12:00:43 +0200

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

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.

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).

> report a bug to various vendors concerned for them to deal with this
> issue in accordance with specifications as per

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.

Alex

> <[email-masked] <mailto:[email-masked]>>:
>
>
>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 16 Jun 2016 21:16:05 -0700

> On Jun 16, 2016, at 03:00 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> 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.

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?).

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?

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.

> 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. This is the entire point of scoped addresses and what you are wanting to do discards virtually all meaning of scope.

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

> 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.

Owen

---

From: Mark Smith <[email-masked]>
Date: Fri, 17 Jun 2016 16:59:04 +1000

> it wanted to be an easy migration target.

IPv6 is specifically different because doing otherwise requires a router to
perform proxy ND for hosts that are on the same link but are not directly
reachable. This behaviour better suits NBMA links or restricted forwarding
broadcast links such as "private VLANs".

With the effort involved to deploy a new Internet protocol, it would have
been a wasted opportunity to just change the size of the addresses and not
make other useful improvements as well, even if they mean people can't just
consider IPv6 to be IPv4 with bigger addresses.

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 17 Jun 2016 10:56:02 +0200

On Thu, Jun 16, 2016 at 12:00 PM, Alexandre Petrescu
<[email-masked]> wrote:
> 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.
>
> 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).

It means that there is no way to signal any errors back to the sender, right?

> originators.  This is may be way beyond pure packet data communications.

The idea of communication protocol which does not allow (by design)
any errors being signaled back sounds like a very bad idea to me...

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Jun 2016 11:32:45 +0200

Le 17/06/2016 à 10:56, Jen Linkova a écrit :
>> 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.
>>
>> 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).
>

Right, an _intermediary_ node may not be able to send errors back to the
sender of a packet that that intermediary forwards.  And that's ok.  The
end nodes may signal each other errors by using appropriate addresses if
available.

This same ability makes it that the network may not be able to always
identify who is the real originator of some packet it forwards.  It is
good too.

Some of the positive effects of this ability (not be able to trace to
the originators) is: VPN proxies exist which allow to access
country-specific content; in emergency situations it is possible to be
connected to Internet _around_ areas forbidding connections identified
by src, even though not able to make phone calls to the forbidden areas.

Be able to send packets and be heard, even though one does not have a GUA.

>> 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.
>

In general I can agree if the same-scope-src/dst issue was bound to a
particular protocol.  But it applies to many protocols - addressing
architecture design.

A bidirectional channel is not always necessary: unidirectional is
sufficient to take action in some settings.  It's known with UDLR
protocol for example.

Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Jun 2016 14:44:00 +0200

Hi,

On Fri, Jun 17, 2016 at 11:32:45AM +0200, Alexandre Petrescu wrote:
> sender of a packet that that intermediary forwards.  And that's ok.  

Please go home and try to understand how the IP protocol suite works,
and do not come back before you have succeeded.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Jun 2016 14:53:55 +0200

Le 17/06/2016 à 06:16, Owen DeLong 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.
>>
> 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.
>
> 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).

> 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
> 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.
>

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

Alex

---

From: Brian Haberman <[email-masked]>
Date: Fri, 17 Jun 2016 09:22:15 -0400

>    arrival interface, or through any other interface attached to the

More important to this particular issue is the rule in section 9 of 4007
that says:

   o  After the next-hop interface is chosen, the zone of the source
      address is considered.  As with the destination address, the zone
      of the source address is determined by the scope of the address
      and arrival interface of the packet.  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.
      Additionally, if the packet's destination address is a unicast
      address, an ICMP Destination Unreachable message [4] with Code 2
      ("beyond scope of source address") is sent to the source of the
      original packet.  Note that Code 2 is currently left as unassigned
      in [4], but the IANA will re-assign the value for the new purpose,
      and [4] will be revised with this change.

The router should be checking the source address of the packet and the
zone of the ingress interface as a part of the forwarding decision.

Regards,
Brian

---

From: Owen DeLong <[email-masked]>
Date: Sun, 19 Jun 2016 12:45:57 -0700

> On Jun 17, 2016, at 05:53 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Outside of Virtual Links, this is not correct. An OSPF router should never
send an LSA beyond a directly connected link except in the case of a virtual
link.

In the case of a virtual link, the routers must use GUA or ULA on both sides,
LL is not permitted.

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

That need does not exist.

> IPv4 on any of the routers.

Correct, but it does this entirely with LINK SCOPED multicast packets using
IPv6 Link Local addresses.

Of course without ULA or GUA, it doesn’t have anything to advertise in the LSAs,
but it cat at least establish neighborship and DR status.

> OSPF, and without GUA/ULA on them (just the LLs).

I’m not sure what prefix a static route would provide next hop information for if
not GUA or ULA. You are making less and less sense with each iteration of this
conversation.

> I would agree with you if I proposed virtual links.

Outside of that case, your proposal is utterly and completely nonsensical and
is not supported by any of the OSPF RFCs.

> GUA or ULA on any of the routers.

This simply is not true. At least not in any valid configuration.

I’m not saying you can’t somehow force it to work on some platforms, though
I certainly wouldn’t expect you to be able to do so and any platform that
allows it is pretty much broken by definition.

> may IP stream what it sees.  Other vehicles hear it, display and further

You keep saying this without actually substantiating it.

Where would it stream that to? By what mechanism would it be doing so?
Sure, there’s no wireless modem, but it’s got to have some sort of association
with an AP or it has to be creating an ad-hoc network. If it’s creating an
ad-hoc network, then how do the other cars decide to connect to it?

Again, your description of the application is nonsensical on multiple levels,
so it is difficult to understand your expectations.

> DFZ - it doesnt look at it anyways because it wants to be fast).

It’s not fear, it’s a desire not to have this bizarre anonymous cruft running
around the internet because of the potential for it’s use by miscreants.

You’re making a number of invalid assumptions. You’re then compounding them
with multiple impractical ideas and expressing the sum of these as an assertion
of how the protocol should behave which turns out to be exactly the opposite
of any sanely desirable behavior.

> settings think a link can be.

A link is the set of all things which can be reached from a given interface without
having to traverse a router. That is the IPv6 definition of a link. Since we are
talking about IPv6 here, the idea of people in mobility settings if it is different
is simply wrong for the context of IPv6.

If you are attempting to impose a different definition, you are also wrong.

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

Yes.

> otherwise very simple forwarding implementation.

It’s very easy. Quite simple, actually.

There are, essentially two scopes that really matter and a host of scopes
for multicast which can be administratively defined.

The two that matter have exactly the same meaning for unicast and multicast.

They are:

	1.	Link Local
		No packet containing a  Link Local Scope or Link Local Scoped Address
		should traverse a router such that it is forwarded to an interface which
		is not on the same link as the arrival interface.

		(In other words, for the definition of link that applies to IPv6, as
		noted above, the packet cannot be forwarded off of that link no matter what.)

	2.	Global
		Packets which are global in Scope or contain only global scoped addresses
		may be forwarded anywhere on the internet as permitted by local policies to reach their
		destination.

> It's easy to enunciate and implement that each packet must have same

This is not a requirement.

> between interfaces of a router.

No, it isn’t. You simply apply the most restrictive scope of the {src,dst} scope attributes.

> scopes.  Yet one _would_ forward a src GUA dst ULA even though they are

In the first case, the packets are different scopes. But GUA and ULA are both global scope. Perhaps this is where you are getting confused. ULA is NOT A SCOPE. ULA is a convention. It’s one of the reasons I argued that ULA was a terrible idea… I figured this confusion about global scoped “local” addresses would be inevitable. Sure enough, you are here to prove my point.

ULA packets are the same scope as GUA. GLOBAL SCOPE.

Any locality in ULA is strictly a matter of administrative convention. If Parties A, B, C, D, E, F, G, H, and I all agree to manage their ULA space so as to avoid conflicts and to route it, then they can form whatever conglomeration of networks they wish and route their ULA around as far as they like. It’s global scoped.

Link Local, OTOH, is _NOT_ global scoped.

One would _NOT_ forward a src GUA dst LL packet any more than one would forward a src LL dst GUA.

> operation is a link-local operation - MLD).

Again, you are incorrect here. The ULA scope is GLOBAL. Yes, one would forward the packet, because the scopes overlap, but one would not forward it outside of the site (whatever administrator has defined as site for multicast purposes).

Sure, technically the subscriptions can be LL, but nobody can send a packet to the group with their LL source and expect it to get forwarded off of the local link.

You should NOT forward a packet with src LL and dst Site-Local Multicast group to a different link.

> disconnected from the Internet).

In reality, address SCOPES and Multicast Group SCOPES are completely separate entities and attempting to conflate them will only lead to pain.

Once you understand that, then you need to understand that address SCOPES only come in two varieties…
Link Local and Global.

There’s no issue in terms of address scopes with overlap or containing.

Multicast scopes are stranger because they have a lot of flexibility. Thus an administrator can actually in some cases define scopes which overlap but are not strictly hierarchical. For example, a site may have elements of multiple organizations, but not contain the entirety of any or all of those organizations.

Let’s consider, for example, a fictitious site ZZYZX which contains all of company A, a branch office of company B, and a research lab for company C.

The multicast scopes at that site would include:

	Multicast Scope		Company			Scope Name
	Organization		A			Org-A
	Site			A, B, C			Site-ZZYZX
	Organization		B			Org-B
	Organization		C			Org-C

Site-ZZYZX would technically contain Org-A and overlap, but not contain Org-B and Org-C.

The difficulty of implementing this conceptually in your software doesn’t matter because each router has to be configured as to what Organization boundaries apply and what site boundaries apply if one intends to use those group definitions.

Just send the packet to the appropriate (ideally user configured) scope and trust that the routing system will do the right thing.

> provided the refs to the specs.

OK, so is there anything else left to discuss?

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Jun 2016 15:29:45 +0200

Owen,

There seem to be some misunderstanding that I would like to clarify.

Le 19/06/2016 à 21:45, Owen DeLong a écrit :
>
>> On Jun 17, 2016, at 05:53 , Alexandre Petrescu
>>>> On Jun 16, 2016, at 03:00 , Alexandre Petrescu
>>>>> This is bad behaviour both for the source device(LL should
>>>>> not be used for off-link destinations), and for intermediary
>>>>> 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.
>>>
>>> Other than virtual links, OSPF route announcements shouldn’t have
>>> GUA destinations. In the case of a virtual link, an OSPF route
> Outside of Virtual Links, this is not correct. An OSPF router should
> never send an LSA beyond a directly connected link except in the case
> of a virtual link.

I may have misunderstood this, I was wrongly under the impression that
OSPF sends the LSAs to all routers in the domain, not only the directly
connected.

> In the case of a virtual link, the routers must use GUA or ULA on
> both sides, LL is not permitted.
>
>> A network of OSPF routers must be able to work without any GUA/ULA
>> nor IPv4 on any of the routers.
>
> Correct, but it does this entirely with LINK SCOPED multicast packets
> using IPv6 Link Local addresses.
>

(sure it has: the prefixes in the LSAs can be globally reachable, or ULA
prefixes, even if the associated next-hop addresses are addresses with
scope link-local only.)

>> Because it is easy to set up same network with static routes,
>> without OSPF, and without GUA/ULA on them (just the LLs).
>
> I’m not sure what prefix a static route would provide next hop
> information for if not GUA or ULA.

I think one should be sure that the next hop information can very well
be an address with link scope even if the associated prefix is of a
global scope (or ULA).

  You are making less and less sense with each iteration
> of this conversation.
>
>>> 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?).
>>
> Outside of that case, your proposal is utterly and completely
> nonsensical and is not supported by any of the OSPF RFCs.

I looked at the OSPF RFC and I tend to agree.

I wonder though whether IPv4 OSPF routers do send LSAs over to other
OSPF routers across links, or not.

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

I think we completely disagree - I claim the exact opposite: routers do
forward for global prefixes even though the next-hops are link-local
addresses.  You can have arbitrarily large IP networks with global
prefixes only at thin edges, and in the core only link-local addresses.

> I’m not saying you can’t somehow force it to work on some platforms,
> though I certainly wouldn’t expect you to be able to do so and any
> platform that allows it is pretty much broken by definition.

I read but I do not comment, because I said it above.

>>> multicast (link scoped) destination. I cannot see any valid case
>>> for sending an RA off-link.
>>>
>>> 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 am not substantiating it simply because it is difficult to
substantiate.  Nobody has done this before so I dont want to say
something stupid.

In all cases, the need is there: in some widespread vehicular
communications there is no unicast nature of communication semantics (a
car can't unicast a packet to another car) - it is all 'broadcast'.
Each car broadcasts data every 1/30th seconds (30Hz) and each other car
hears everybody else.  The ESSID and the dst MAC address is
ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's address.

In addition to being broadcast-only, there is no request-response kind
of messages.  Although the 'broadcast' nature allows each car to
independently decide how far it is from other cars (and take some action
like braking), there is no possibility to effectively authorize each
other, or to ask other useful things in a more peer-to-peer manner.

Not to mention that the broadcast-only way of communicating between many
entities has obvious scalability issues: not too many cars can be around
without generating much noise.

In this situation, one would like to make IP work.  This is difficult to
substantiate.

> Sure, there’s no wireless modem, but it’s got to have some sort of
> association with an AP or it has to be creating an ad-hoc network. If
> it’s creating an ad-hoc network, then how do the other cars decide to
> connect to it?

For clarification, in many vehicular networks there is no AP and no
ad-hoc mode either: the mode it's called Outside the Context of a BSSID,
which works by supprssing all WiFi management frames (and hence no AP no
ad-hoc mode).

In some other vehicular networks there are some APs along the road, or
some cars are the AP (in some platooning the lead car can be AP, but not
all platoons).

> Again, your description of the application is nonsensical on
> multiple levels, so it is difficult to understand your expectations.
>
>>> 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).
>
> It’s not fear, it’s a desire not to have this bizarre anonymous
> cruft running around the internet because of the potential for it’s
> use by miscreants.
>
> You’re making a number of invalid assumptions. You’re then
> compounding them with multiple impractical ideas and expressing the
> sum of these as an assertion of how the protocol should behave which
> turns out to be exactly the opposite of any sanely desirable
> behavior.

You may come up with better idea about how IP should run in vehicular 
networks which are currently broadcast-only.  How?

>>>> 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.
>>
>> I suspect your assumption of 'link' is not what many people in
>> mobility settings think a link can be.
>
> A link is the set of all things which can be reached from a given
> interface without having to traverse a router. That is the IPv6
> definition of a link. Since we are talking about IPv6 here, the idea
> of people in mobility settings if it is different is simply wrong for
> the context of IPv6.

No no, we should think that IPv6 should be applied in as many settings 
as possible, including wireless (mobility).

The IPv6 idea of a link as 'all things which can be reached from a given 
interface' carries the wire Ethernet baggage along: the furthest who can 
be 'reached' from one interface can no longer reach anyone further - 
it's the 'furthest', end of cable limit.  This idea does not reflect 
what's happening in wireless: one who can be reached on an interface can 
further reach others which are invisible to the first - there is no 
cable limit.

The IPv6 idea is that somebody can 'reached' because there is a cable. 
To reach further there is a need of a router at a precise point: the end 
of the cable.

In wireless there is no fixed cable and it's hard to decide where to 
place the routers.

>> implementers wondering which additional rules to add (or not) to
>> an otherwise very simple forwarding implementation.
>
> There are, essentially two scopes that really matter and a host of
> scopes for multicast which can be administratively defined.
>
> 1.Link Local No packet containing a  Link Local Scope or Link Local
> Scoped Address should traverse a router such that it is forwarded to
> an interface which is not on the same link as the arrival interface.
>
> 2.Global Packets which are global in Scope or contain only global
> scoped addresses may be forwarded anywhere on the internet as
> permitted by local policies to reach their destination.

It's hard to define link-local scope in a setting where it's hard to 
define a link altogether.

WiFi with AP indulges us into believing the link is everybody in that ESSID.

But there is no link in WiFi w/o AP and OCB (outsid the...)

>> 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.
>

If it were that simple then src-based routing were already there.

>> scopes.  Yet one _would_ forward a src GUA dst ULA even though they
>> are different scopes too.
>
> In the first case, the packets are different scopes. But GUA and ULA
> are both global scope. Perhaps this is where you are getting
> confused. ULA is NOT A SCOPE. ULA is a convention. It’s one of the
> reasons I argued that ULA was a terrible idea… I figured this
> confusion about global scoped “local” addresses would be inevitable.
> Sure enough, you are here to prove my point.
>

Yet it's strange to call 'L' in ULA Global scope...

> Any locality in ULA is strictly a matter of administrative
> convention. If Parties A, B, C, D, E, F, G, H, and I all agree to
> manage their ULA space so as to avoid conflicts and to route it, then
> they can form whatever conglomeration of networks they wish and route
> their ULA around as far as they like. It’s global scoped.
>

But one would not forward by looking at src, unless the operation were 
called "rewind".

>> 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).
>
> Again, you are incorrect here. The ULA scope is GLOBAL. Yes, one
> would forward the packet, because the scopes overlap, but one would
> not forward it outside of the site (whatever administrator has
> defined as site for multicast purposes).
>
> Sure, technically the subscriptions can be LL, but nobody can send a
> packet to the group with their LL source and expect it to get
> forwarded off of the local link.
>

I get this 'no' from you.

I would like to ask you how would you see vehicular networks work 
without this operation.

>> 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).
>
> In reality, address SCOPES and Multicast Group SCOPES are completely
> separate entities and attempting to conflate them will only lead to
> pain.
>
> Once you understand that, then you need to understand that address
> SCOPES only come in two varieties… Link Local and Global.
>
> Multicast scopes are stranger because they have a lot of
> flexibility. Thus an administrator can actually in some cases define
> scopes which overlap but are not strictly hierarchical. For example,
> a site may have elements of multiple organizations, but not contain
> the entirety of any or all of those organizations.
>
> Let’s consider, for example, a fictitious site ZZYZX which contains
> all of company A, a branch office of company B, and a research lab
> for company C.
>
> Multicast ScopeCompanyScope Name OrganizationAOrg-A SiteA, B,
> CSite-ZZYZX OrganizationBOrg-B OrganizationCOrg-C

(figure in original message).

The scopes as you depict them are frozen: they dont change.  There is a 
god-like administrator who decides who belongs to what scope and then 
configures the routers.

This scheme is hard to implement in vehicular networks: movements of 
various speeds make and de-make what's possible to be in-scope and out 
of scope.  There is no more potent entity (like a fixed router) to which 
one can send subscriptions.

Alex

> The difficulty of implementing this conceptually in your software
> doesn’t matter because each router has to be configured as to what
> Organization boundaries apply and what site boundaries apply if one
> intends to use those group definitions.
>
> Just send the packet to the appropriate (ideally user configured)
> scope and trust that the routing system will do the right thing.
>
>>>>> necessary to report a bug to various vendors concerned for
>>>>> them to deal with this issue in accordance with
>>>>> specifications as per
>>>> 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.
>>>
>> By the specs, yes, he's right.  Thanks to the WG members for
>> having provided the refs to the specs.
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 22 Jun 2016 15:47:57 -0700

> On Jun 22, 2016, at 06:29 , Alexandre Petrescu <[email-masked]> wrote:
> 
> Owen,
> 

Nope… AIUI, only to the neighbor routers who then flood them to their
neighbors, etc.

> prefixes, even if the associated next-hop addresses are addresses with

But if they are working without any GUA or ULA, then they don’t have
any GUA or ULA to advertise in those LSAs. (Unless you and I have
very different definitions of “working without any…”.

True, the routers don’t need to possess any GUA or ULA addresses themselves,
but I don’t see this as relevant to the discussion.

> be an address with link scope even if the associated prefix is of a

Of course, but the link scoped next-hop address has to be on a directly attached
link and next-hop addresses never appear in IP headers.

> OSPF routers across links, or not.

No.

Only to direct neighbors. This is no different from OSPFv2 to OSPFv3.

> prefixes only at thin edges, and in the core only link-local addresses.

Sure, but in this case, you are not forwarding packets which have LL
source or destination across links. You are forwarding packets which have
GUA and/or ULA src/dest headers across links which happen to have only LL
addresses on those links. That is valid.

What is not valid is having a packet with an LL source or destination in
the IP header forward from one link to a different link.

> I read but I do not comment, because I said it above.

Your new example has to have GUA on at least the edge routers of the
scenario you describe, so I argue that it does not fall within the scope
of my previous statements.

> substantiate.  Nobody has done this before so I dont want to say

There are IMHO many reasons nobody has done this before. As to your
last sentence, I will refrain from comment so as to avoid the potential
of ad hominem.

> ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's address.

Then perhaps you should get a reserved multicast group number for “all cars”.

Then, you can use “all cars on link” for link scoped communications where
a LL source address would be valid and “all cars within ORG” for an ORG scoped
communication using a ULA source, etc.

There are clean ways to do this, but the proposals you have put forth so far,
however, are not.

There is no concept of broadcast in IPv6, so you can’t do “broadcast-only”.
You have to use multicast.

> other, or to ask other useful things in a more peer-to-peer manner.

So you want to put passenger safety in the hands of unauthenticated multicast
packets… What could possibly go wrong? Please let me know which manufacturers
you are working with so as I can avoid purchasing their products.

I suggest you look at TCAS from the aviation world and rethink your ideas
here. There is much more data available and it can be used in much better
ways.

To make matters worse, if you use open broadcasts and no authentication, then
all I have to do to commit a pretty gross DDOS is build an autoresponder that
will always tell each car from which it hears an announcement that I have
suddenly appeared directly in front of it at close range.

Everyone in the car gets the maximum braking experience for no reason and
likely receives the rear-end experience in something like 5% of cases.

That’s just lovely.

> without generating much noise.

So why would you possibly ever consider such a thing.

> In this situation, one would like to make IP work.  This is difficult to

In this situation, I think one needs to completely rethink their system. The
model has so many fundamental flaws that I think it is a nightmare waiting to
happen if it ever achieves anything remotely approaching widespread implementation.

I would never knowingly buy a car which implements such a thing in such a terribly
flawed way.

> which works by supprssing all WiFi management frames (and hence no AP no

This seems like an inherently bad idea on multiple levels.

> some cars are the AP (in some platooning the lead car can be AP, but not

Right, well, regardless of the underlying L2 structure, I hope I’ve been able
to show you why the restrictions you attempt to put forward as inherent in
design decisions already made are fundamentally flawed in terms of even making
your system work even _IF_ IP could somehow cope with these poor choices, which
I believe it most likely cannot.

> You may come up with better idea about how IP should run in vehicular networks which are currently broadcast-only.  How?

First of all, you need to recognize that you’re going to need more security
than is possible with your proposed design. Go back and rethink the
fundamental communications model and think in terms of what bad things
can happen if someone wants to inject false information into the network.

You need to either mitigate ALL of those events or better still, prevent
false information from being injected. Since prevention of injection will
require some form of authentication and authorization, I think you have
to move beyond all-broadcast anyway.

Frankly, I worry about this with the design of ADS-B and modern TCAS
today for aircraft, but there’s at least some level of mitigation there.
Your proposed network is significantly weaker than that one and offers
a much larger target base that is much easier for miscreants to attack.

> No no, we should think that IPv6 should be applied in as many settings as possible, including wireless (mobility).

That’s not my point. I’m saying that in the context of IPv6, their definition of the term “link” is wrong. Not that it is wrong to use IPv6.

> The IPv6 idea of a link as 'all things which can be reached from a given interface' carries the wire Ethernet baggage along: the furthest who can be 'reached' from one interface can no longer reach anyone further - it's the 'furthest', end of cable limit.  This idea does not reflect what's happening in wireless: one who can be reached on an interface can further reach others which are invisible to the first - there is no cable limit.

Once they are invisible and require forwarding, they are OFF LINK and MUST BE FORWARDED. At that point, you can’t use LL.

> The IPv6 idea is that somebody can 'reached' because there is a cable. To reach further there is a need of a router at a precise point: the end of the cable.

No, the IPv6 idea is that there are two kinds of hosts. Those that can be directly reached (ON LINK) and those which require forwarding (OFF LINK). It doesn’t matter whether this is cable or wireless. If you can directly reach it from your own local interface, then it is ON LINK. If you need to depend on another host to forward the packet from you to the other host you want to talk to, then that host in the middle is called a router and the other host is OFF LINK.

> In wireless there is no fixed cable and it's hard to decide where to place the routers.

Every form of deployment has its own challenges. It doesn’t change the definition of what is on or off of a LINK.

> It's hard to define link-local scope in a setting where it's hard to define a link altogether.

But it’s NOT hard to define a link. A link is well defined. What is hard is that you don’t like the definition of a link and you want to somehow apply some magical definition that doesn’t actually work.

> WiFi with AP indulges us into believing the link is everybody in that ESSID.

It doesn’t indulge us to believe, it makes that the case.

> But there is no link in WiFi w/o AP and OCB (outsid the…)

Sure there is… It’s limited to the vehicles that can directly see your packets because you don’t have an L2 forwarder (AP) specifically responsible for forwarding those packets.

If you come up with a somewhat reliable mechanism for L2 forwarding of these datagrams, then you can extend your idea of a link farther, but you’re going to quickly run into scaling issues with traffic saturation as your broadcast domain grows.

>> This is not a requirement.

It _IS_ a requirement in IPv6.

> If it were that simple then src-based routing were already there.

That’s like saying “If apples, then space ships.”

It makes literally no sense whatsoever to me.

Source routing has nothing to do with this and isn’t applicable to IPv6.

If a router receives a packet with different scoped addresses, then it
must apply the forwarding policy applicable to the most restrictive scope
present.

Thus, LL,ULA == LL, LL,GUA == LL, ULA,GUA == Global, GUA,GUA == Global
ULA, ULA == Global.

> Yet it's strange to call 'L' in ULA Global scope…

ULA isn’t a scope. It’s a convention.

The problem here is that you keep confusing yourself by thinking of
the L in ULA as being a scope definition. It’s not. It’s just a convention.

> But one would not forward by looking at src, unless the operation were called "rewind”.

In IPv6, the way the protocol is designed, you must look at the scope of the source
address before forwarding it to an interface other than one on the same link as the
interface where the packet arrived. It is a requirement documented in the RFCs.

So your above claim is patently false. You are wrong. It’s as simple as that. You are
required to look at the src before forwarding the packet. You don’t necessarily use
the src in determining where to forward the packet, but you must consider the scope
of the source address in deciding whether or not to forward the packet.

> I would like to ask you how would you see vehicular networks work without this operation.

Presumably with something other than LL addresses.

> The scopes as you depict them are frozen: they dont change.  There is a god-like administrator who decides who belongs to what scope and then configures the routers.

As is the case in the vast majority of implementations and as is the case
in the IPv6 protocol design.

> This scheme is hard to implement in vehicular networks: movements of various speeds make and de-make what's possible to be in-scope and out of scope.  There is no more potent entity (like a fixed router) to which one can send subscriptions.

Hosts come and go from Mobile networks and from WiFi networks all the time.

There’s constant flux on which hosts are ON-LINK or not ON-LINK from any given perspective.

Sure, this could be a particularly challenging aspect of your particular use case.

That’s your challenge to solve, but you don’t get to change IPv6 in a way that is
detrimental to all other users in order to solve it, nor do you get to simply pretend
that IPv6 behaves (or should behave) differently because it is convenient to your
application.

The problem you are trying not to solve is frankly not one you will be able to avoid solving anyway.

You’re going to have to solve that problem in order to have any reasonable measure of security in 
your application.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Jun 2016 15:39:37 +0200

Le 23/06/2016 à 00:47, Owen DeLong a écrit :
[...]
> Then perhaps you should get a reserved multicast group number for “all cars”.

Well I wonder about the name.

The too familiar 'cars' could be more pedantic 'vehicles' or 'light 
vehicles'.

But 'vehicles' would look strange in the current list of nodes, routers, 
servers or agents
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

> communication using a ULA source, etc.

'ORG' - 'organization' is obviously not the right word for something 
ephemeral happening between a few cars on a highway none of which being 
more entitled than another.

> There are clean ways to do this, but the proposals you have put forth so far,

I am looking for clean ways dealing with situations where it's hard to 
say who is the 'owner' or the control entity which keeps track of 
multicast registrations in some scope.

> You have to use multicast.

The word 'broadcast' can be ambiguous in this discussion.  In vehicular 
communications 'broadcasting' means to send in the ether, as opposed to 
sending on a wired Ethernet; and it also means there is no return path - 
a little bit like in 'TV broadcast'.  In a particular report, they say 
"DSRC operates in constant broadcast-and-receive mode": you periodically 
broadcast to everyone else and always receive from everyone else, but 
you can not send to just one entity.  This 'broadcast' concept of 
vehicles is independent of the fact that the MAC dst address is 
ff:ff:ff:ff:ff:ff (MAC broadcast address).

But yes I agree with you when it comes to IPv6 it should use multicast 
addressing, not broadcast addressing.

So I think we should suggest to use 33:33::1 MAC address instead of the 
ff:ff:ff:ff:ff:ff MAC address when IPv6 is used over these links.  I 
will put that in some draft.

Alex

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jun 2016 08:28:36 -0700

On 6/23/2016 6:39 AM, Alexandre Petrescu wrote:
> But 'vehicles' would look strange in the current list of nodes,
> routers, servers or agents

The list includes types of:
    - components in the Internet architecture (hosts, which source/sink
datagrams and routers, which also relay)
    - components that speak a particular protocol that uses multicast

Cars or vehicles are neither.

Physical locations are neither.

If there's a candidate, it really ought to describe something in terms
of the network, not in terms of where the device happens to be deployed
- because whatever deployment assumptions are made today WILL be wrong.

> The word 'broadcast' can be ambiguous in this discussion.  In
> vehicular communications 'broadcasting' means to send in the ether, as
> opposed to sending on a wired Ethernet; and it also means there is no
> return path - a little bit like in 'TV broadcast'. 

Michelson and Morley proved there is no "ether" in 1887. IP runs over
many different link layers that could be used here, including RF (WiFi,
4G, etc.), photonic (headlight and other lamp modulation), etc. And many
of these have been around since the origin of the Internet.

And unidirectional links are just called "half duplex", and have been
part of the Internet since its origin too - including encodings over
idle periods in broadcast TV signals or radio.

> addressing, not broadcast addressing.

IMO, the doc needs to be cast in terms of using multicast, not merely
replace the term for broadcast and assume they are interchangeable.

>
> So I think we should suggest to use 33:33::1 MAC address instead of
> the ff:ff:ff:ff:ff:ff MAC address when IPv6 is used over these links. 
> I will put that in some draft.

Can you explain where this comes from? It's not how IPv6 multicast
typically interacts with MAC addresses. You probably can just explain
what you need in terms of IPv6 and let the link decide what MAC is
appropriate for a given IPv6 multicat.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jun 2016 08:39:13 -0700

> idle periods in broadcast TV signals or radio.

Before anyone jumps, it's half-duplex if the other end can't reply while
you're talking, which seemed to match the discussion.

If what you meant was simplex (no return path is possible at all), then
just say that. True simplex wasn't covered in RFC3819, I suspect because
very few protocols are useful if there is no return path at all (one
could easily argue that a node reachable only by one simplex link is the
proverbial "tree that falls in the forest" that nobody hears, i.e.,
there's no difference between that and a node that simply isn't there).

Joe

---

From: Owen DeLong <[email-masked]>
Date: Thu, 23 Jun 2016 13:33:27 -0700

> On Jun 23, 2016, at 06:39 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> The too familiar 'cars' could be more pedantic 'vehicles' or 'light vehicles'.
> 
> But 'vehicles' would look strange in the current list of nodes, routers, servers or agents

I don’t care what you name it as long as it makes sense and is properly descriptive.

Cars was just an example for the sake of discussion, not an actual recommendation.

> 'ORG' - 'organization' is obviously not the right word for something ephemeral happening between a few cars on a highway none of which being more entitled than another.

Depends. if it’s all the vehicles that belong to e.g. DHL that you are trying to reach, that could be a perfectly legitimate use of ORG.

There are lots of other scopes to choose from as well.

Point is that with ULA SRC, agreement among the participants to forward ULA network numbers, and a proper multicast scope, you can do what you want without breaking half the RFCs to do it.

Sure, your forwarding is now forwarding at layer 3, but that’s better in most cases anyway.

Ad-Hoc random layer 2 forwarding DOES NOT SCALE.

> I am looking for clean ways dealing with situations where it's hard to say who is the 'owner' or the control entity which keeps track of multicast registrations in some scope.

That’s the beauty of having a registered multicast group.

The scope is a choice made at packet creation time, but the semantics of the group number remain the same regardless of scope.

So, for example, All Nodes multicast is always ALL Nodes. You can make it All Nodes on Link, All Nodes within ORG, All Nodes Globally, or whatever. That’s why the group ID and the Scope are separate fields in the IPv6 Multicast address and why there’s a flag to indicate whether the Group ID is permanent/global or valid only within the current context.

(chances of real world forwarding of multicast obviously diminish with increasing scope choice, but that’s a separate matter).

> The word 'broadcast' can be ambiguous in this discussion.  In vehicular communications 'broadcasting' means to send in the ether, as opposed to sending on a wired Ethernet; and it also means there is no return path - a little bit like in 'TV broadcast'.  In a particular report, they say "DSRC operates in constant broadcast-and-receive mode": you periodically broadcast to everyone else and always receive from everyone else, but you can not send to just one entity.  This 'broadcast' concept of vehicles is independent of the fact that the MAC dst address is ff:ff:ff:ff:ff:ff (MAC broadcast address).

That’s a simply stupid definition of the term and can only lead to confusion when you talk to people involved in networking.

> But yes I agree with you when it comes to IPv6 it should use multicast addressing, not broadcast addressing.

Exactly. And it should limit the Multicast to a group assigned to the particular purpose. You might need multiple multicast group numbers for different applications to do this right.

> So I think we should suggest to use 33:33::1 MAC address instead of the ff:ff:ff:ff:ff:ff MAC address when IPv6 is used over these links.  I will put that in some draft.

That’s probably a good start.

Owen

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jun 2016 13:51:13 -0700

> That’s probably a good start.

IMO, it'd be better to say you're using "all nodes" and cite RFC2464
rather than opaquely using the MAC that results.

Joe