Subject: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

From: [email-masked]
Date: Tue, 7 Jul 2015 04:47:01 -0700

A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment.

---

From: Erik Kline <[email-masked]>
Date: Tue, 7 Jul 2015 21:38:24 +0900

+1

I would include some text to the effect that a router may additionally
transmit a unicast RA toward at virtually any time, not just in
response to RSes.

These could be on a schedule of course, but more importantly, if a
router knows it has a queue of packets to send to a node it is free to
push a unicast RS onto the front of that queue as a way to assist the
client keeping RA data fresh.

On 7 July 2015 at 20:47,  <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tore Anderson <[email-masked]>
Date: Tue, 7 Jul 2015 16:55:51 +0200

* [email-masked]

> A new draft has been posted, at
> http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast.
> Please take a look at it and comment.

Support WG adoption.

Comments:

1) Nit: Abstract: s/network/networks/ (Or so I think. I'm not a native
speaker.)

2) Section 2, second bullet: Would like to add that the lost
connectivity (due to default route expiring) persists after the device
has woken back up again. This is another big reason for a network
operator to send RAs frequently, to ensure that a device re-gains its
connectivity as soon as the user starts interacting with his device.
Furthermore, a reference to draft-ietf-6man-rs-refresh might be prudent
here.	

3) Section 3: Did you consider recommending making unicast the default
behaviour for solicited RAs on all networks, not just the ones with
sleepy devices? I was thinking about it for a while and I couldn't
immediately see any big issue with that, but I might be missing
something. If the recommended approach isn't also suitable for, say, an
enterprise wired LAN with desktop PCs, or a data centre server LAN,
maybe include some text describing why not?

4) Section 3: I think that for a complete solution you should also
recommend that hosts MUST not ignore multicast RAs when they're
sleeping. Otherwise, you're missing a big part of the solution - the
hosts I discussed in #2 still lost their connectivity while sleeping
and after waking back up, and the way to combat that would still be for
the network to send unsolicited (multicast) RAs frequently.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 8 Jul 2015 19:09:24 +0000

Lorenzo and Andrew:

I'm trying to figure out how to unjam the Prague agenda, and I wonder if this (very simple) draft can be sorted out on the list before the event. We already have two supportive comments. I'll note that what you describe for IPv6 is pretty common in IPv4 today - and I have it in my head it is common in IPv6 today. What I think you're saying is "please make it common if it's not".

RFC 4861, section 6.2.6, says:

   In addition to sending periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   an advertising interface.  A ROUTER MAY CHOOSE TO UNICAST THE
   RESPONSE DIRECTLY TO THE SOLICITING HOST'S ADDRESS (if the
   solicitation's source address is not the unspecified address), but
   the usual case is to multicast the response to the all-nodes group.
   In the latter case, the interface's interval timer is reset to a new
   random value, as if an unsolicited advertisement had just been sent
   (see Section 6.2.4).

emphasis mine.

Your draft says, if I may summarize in two sentences, "routers that don't send unicast RAs in response to an RS cost the network and its hosts a lot of resources" and "please send RAs unicast unless there is a good reason not to, such as a periodic RA".

Correct?

If I were to give you an agenda slot, did I just say everything (modulo perhaps a supporting graphic) that you would say?

Presuming the answer to be "yes", let me propose a short-circuit process. I would invite immediate discussion - do we agree with this? Is there an alternative viewpoint we're missing? Are there other cases the draft should address (it's primarily about mobile, but I would submit it is relevant to any shared L2 infrastructure, which could describe data centers and WiFi networks)?

BTW, chair hat off, I would suggest that your proposed configuration knob default to "send unicast", not "send multicast".  Take that as you see fit. I have been wrong before.

Given an avalanche of "yes, and let's make it a WG document, but here's a comment", I'd suggest that
 - I don't give the authors a meeting slot
 - We accept this as a working group document
 - The authors post the updated draft as draft-ietf-v6ops-solicited-ra-unicast in August
 - I run a WGLC in September
 - we ship it

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jul 2015 15:08:58 +1000

Hi,

I support the adoption of this draft.

One thought I have though is that I wonder if just changing solicited
RAs from multlicast to unicasts would result in an increase in the
number of multicast RSes?

It was my understanding that the idea behind multicasting solicited
RAs was to also update hosts who were soon going to be issuing
multicast RSes, which would then reduce the volume of multicast RSes.
If those hosts are now not going to receive the multicast solicited
RAs, then they I think they would now be issuing multicast RSes more
often where as in the past they wouldn't.

As a side note, the radvd RA daemon already supports a UnicastOnly option:

--
UnicastOnly on|off
Indicates that the interface link type only supports unicast. This
will prevent unsolicited advertisements from being sent, and will
cause solicited advertisements to be unicast to the soliciting node.
This option is necessary for non-broadcast, multiple-access links,
such as ISATAP.

Default: off
--

The issue of increased numbers of multicast RSes would be avoided on
e.g., ISATAP networks because hosts using that use static, DHCPv4 or
DNS lookups to discover routers instead of multicast RSes.

Regards,
Mark.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 9 Jul 2015 05:38:44 +0000

> On Jul 8, 2015, at 10:08 PM, Mark Smith <[email-masked]> wrote:
> 

Sounds like you have a tool that you could use to simulate that and find out?

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jul 2015 16:20:51 +1000

> Sounds like you have a tool that you could use to simulate that and find out?

Ok, I'll set something up.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jul 2015 18:15:35 +1000

Hi,

> Sounds like you have a tool that you could use to simulate that and find out?

So thought about this a bit more, and realised that my thinking wasn't
quite right.

Hosts don't issue periodic multicast RSes, such that receiving a
solicited multicast RA a short period before a periodic multicast RS
would have been sent would suppress the multicast RS. Periodic
unsolicited multicast RAs keep hosts' knowledge of default routers
fresh, so hosts would only issue a multicast RS when they need to
discover routers "now" i.e., when an interface comes up.

I think this means that unicasting solicited RAs on certain link types
would usefully reduce multicasts. It does raise the question as to why
solicited RAs were multicast in the first place. The only other
benefit I can see of mulicasting solicited RAs is that it would keep
all of the receiving hosts' default router knowledge more accurate and
the aging of the default router information more synchronised across
all nodes over the periodic unsolicited multicast RAs. I'm not sure if
it would matter if the loss of this increased default router accuracy
and aging synchronisation would matter if solicited RAs were unicast
instead of being multicast.

Out of interest, I also captured RSes and RAs on my home Wifi LAN (all
hosts were variants of Linux), and also looked up some Windows boot
packet captures I have. Here's what I found and some thoughts.

o  RSes with a :: source address

Windows XP sends some early RSes with a source address of the
unspecified address. These RSes didn't have the Source Link-Layer
Address Option (because :: shouldn't be added to the neighbor cache).
This is permitted by RFC4861. It later sends RSes using a link-local
source address, now containing the Source Link-Layer Address Option.
Later versions of Windows didn't issue RSes with :: source addresses
i.e., they waited until they had a link-local address to use (and
included the Source Link-Layer Address Option).

It isn't possible to use the :: address as a destination address for
the solicited RA per RFC4291, so it seems the only choice for the IPv6
destination address is FF02::1. However, if the link-layer header
source address of the RS is available to the RA process, then it could
link-layer unicast the multicast RA, as per RFC6085, "Address Mapping
of IPv6 Multicast Packets on Ethernet".

I think it is necessary to describe how to handle these :: source
address RSes in this draft, as they're valid and could appear on a
"solicited unicast RA only" link.

o  RSes with a link-local source addresses, but no Source Link-Layer
Address Option

Some of my Linux hosts issued RSes with a link-local source address,
but without the Source Link-Layer Address Option. This also seems
permitted by RFC4861. These hosts were Fedora 22 hosts, using the user
space Network manager package to perform/handle RS/RA processing in
user space, verses other hosts (Android, Chrome OS) which are probably
using the Linux kernel's RS/RA facilities. I dug into the Network
manager code and found that it was using the libndp.org NDP library,
and was using a single call that builds a generic RS without the SLLA
option.

RFC4861 is pretty clear about what to do when there is an SLLA option
in an RS - create or update a neighbor cache entry for the RS source
address with the SLLA option value, and set it to STALE. However, I
don't find the text about when there is no SLLA option that clear:

"If there is no existing Neighbor Cache
   entry and no Source Link-Layer Address option was present in the
   solicitation, the router may respond with either a multicast or a
   unicast router advertisement.  Whether or not a Source Link-Layer
   Address option is provided, if a Neighbor Cache entry for the
   solicitation's sender exists (or is created) the entry's IsRouter
   flag MUST be set to FALSE."

It seems to be strongly implying that a neighbor cache entry could be
created even if there is no SLLA option, because it says it is
possible to respond with a unicast RA. However, to be able to use the
RS's source IPv6 address to unicast the RA, I think a NS/NA
transaction would need to occur first for the RS's source address,
before the unicast RA is sent.

The implementation could use the link-layer source address from the
frame the RS arrived in to send a link-layer unicast solicited unicast
RA (i.e., don't use the neighbor cache to resolve the link-layer
destination address, use the RS frame's source address). In that case,
I think the frame's link-layer source address should only be used for
this unicast solicited RA. An entry in the neighbor cache would be
created for the RS's source address, and then an NS/NA transaction to
verify its reachability independent of sending the RA.

Alternatively, the method of link-layer unicasting a multicast
solicited RA could be used, although there is probably more broader
value in the triggering an NS/NA transaction method.

o  At least one common IPv6 RA implementation isn't rate limiting
sending solicited RAs

This is for the current version of OpenWRT, sending way more than one
RA per 3 seconds if I solicit them quickly. So it may be worth
observing in the ID that RA rate limits may not have been implemented,
and unicasting RAs in that case will have the benefit of avoiding
sending these RAs to nodes that didn't solicit them.

17:14:47.312209 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.313398 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.314363 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.315563 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.316739 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.529880 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.533531 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.536100 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.538672 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.541194 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192

Regards,
Mark.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 16 Jul 2015 08:23:29 +0000

> On Jul 16, 2015, at 10:15 AM, Mark Smith <[email-masked]> wrote:
> 
> solicited RAs were multicast in the first place.

Not sure. RFC 826, which is the obvious predecessor, calls for the response to an ARP request to be unicast.

Thanks for your note.

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Jul 2015 11:01:02 +0200

> Not sure. RFC 826, which is the obvious predecessor, calls for the response to an ARP request to be unicast.

I believe it was thought of as an optimisation.

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jul 2015 19:18:49 +1000

Hi Fred,

> Not sure. RFC 826, which is the obvious predecessor, calls for the response to an ARP request to be unicast.

Now you've mentioned an old RFC, it has reminded me of RC1256, "ICMP
Router Discovery Messages", which I came across again fairly recently.
It describes RS/RAs for IPv4, and somewhat surprisingly
implementations of it seem to be fairly available - Cisco and Juniper
call it IRDP, and e.g., my Fedora 22 host has a client for it
installed by default ('rdisc').

It says that RAs can be unicast, multicast or broadcast. It seems to
give a bit of a clue as to why multicast solicited RAs would be
useful:

"A unicast response may be delayed, and a multicast
   response must be delayed, for a small random interval not greater
   than MAX_RESPONSE_DELAY, in order to prevent synchronization with
   other responding routers, and to allow multiple, closely-spaced
   solicitations to be answered with a single multicast advertisement."

In 1991, hosts were pretty much mains powered, fixed location and
wired, so they could all rush to send multicast RSes after a mains
power outage or the 10BASE2 cable broke and was then fixed, and they
wouldn't have come and gone much from the link either. A single
multicast RA in response to the first RS in a flood of them could have
caused a lot of later RSes to be suppressed.

> Thanks for your note.

No worries.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jul 2015 19:49:47 +1000

>>> On Jul 16, 2015, at 10:15 AM, Mark Smith <[email-masked]> wrote:

<snip>

> caused a lot of later RSes to be suppressed.

So the next logical thing to do would be to have the router default to
unicast Router Advertisements, measure the rate of received Router
Solicitations, and switch to multicast RA mode past a certain
threshold to cover this sort of situation. Once the number of RSes
falls, it switches back to unicast RA mode.

That would get rid of the configuration knob proposed in this ID, and
is behaviour that I think could be universal for all link types,
rather than just for the case of wireless ones with mobile devices.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 17 Jul 2015 07:34:13 +0000

> rather than just for the case of wireless ones with mobile devices.

If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast.

---

From: Erik Kline <[email-masked]>
Date: Fri, 17 Jul 2015 16:59:27 +0900

> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second…

Like what happened with the Happy Eyeballs draft, I think many
strategies will be possible.  It may be best to simply document the
considerations, along with a baseline recommendation that unicast
options of some kind SHOULD be available.

I'd leave it at roughly:

    - multicast RA at least once every max_ra is still a MUST (iirc)
    - unicast RAs MAY be sent at any time, whether solicited or not
    - unicast RAs SHOULD be considered for link layers where this
helps efficiency

The exact strategy for Happy Hosts / Happy Routers (Happy Nodes?) will
likely depend on link layers and use cases, some of which have yet to
be defined.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 17 Jul 2015 18:57:32 +0200

> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second…

values of T less than 3 seconds would make performance worse than today.

There are many things to optimize for:

- wireless airtime
- bandwidth used by RAs
- CPU usage sending unicast RAs by router
- energy consumption on devices for more than one medium

Some of them are orthogonal, some of them contradict each other, some of them align. People may want to optimize differently.

I'd opt for simplicity - and use the text Erik Kline posted in another email.

This would allow the developers to adapt for individual use cases on the spot.

--a

---

From: Mark Smith <[email-masked]>
Date: Sat, 18 Jul 2015 09:51:06 +1000

> This would allow the developers to adapt for individual use cases on the spot.

I think specifically calling out the above optimisation considerations
would be good to do in this draft.

While providing flexibility is useful to cover the unexpected, I also
think it is also important to have consistency. Specific case
optimisations can be beneficial, but they're also variations and
exceptions. The more variations and exceptions there are, the more
things people have to try to understand and remember, which makes then
makes configuration and troubleshooting harder.

So, for example, it would be good to have a consistent default
behaviour for all Wifi links (likely unicast solicited RAs, because
hosts (PCs, laptops, smartphones) come and go regularly), and a
consistent default behaviour for all wired links (likely multicast
solicited RAs, because hosts (servers) don't come and go regularly, so
the recovery from power outage scenario flood of RSes is the likely
common scenario for solicited RAs).

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2015 16:23:09 +0200

> A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment.

A bit late but...I fully support the draft. Very useful work.

One comment: Lorenzo, Andrew - do you think it worth mentioning the
difference in how reliable multicast and unicasts are on wifi?

-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Jul 2015 18:29:08 +0200

> often where as in the past they wouldn't.

Yes. In the (rare) case where a large number of nodes joins the network at
the same time, sending a single multicast RA would likely be more
efficient. That would need to be weighed against the power implications on
the nodes that are already connected, so it probably only makes sense if
the router is seeing large enough numbers of RS packets that it believes
that it cannot handle them efficiently.

We could put something in the draft saying that "routers configured in this
mode MAY send solicited RAs multicast in conditions where it is likely that
doing so will be more efficient (e.g., if a large number of clients is
sending RS packets at the same time and the packets are being dropped due
to control plane limiting).

That doesn't help because it doesn't do unsolicited advertisements.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Jul 2015 18:35:21 +0200

>     - multicast RA at least once every max_ra is still a MUST (iirc)

Do we need to repeat this? It should already be clearly stated by RFC 4862.

>     - unicast RAs MAY be sent at any time, whether solicited or not

What's the use case for a unicast unsolicited RA? They can only reach nodes
for which the router knows the IPv6 addresses, and so pretty much require
that routers keep a lot of state.

> helps efficiency

I think we also need to provide a clear recommendation to do this on common
types of links where this is beneficial, i.e., Wi-Fi.

---

From: Erik Kline <[email-masked]>
Date: Mon, 20 Jul 2015 19:04:14 +0200

> that routers keep a lot of state.

Yes, and these routers exist.  The M2M stuff I scanned in 3GPP has
nodes that sleep on a schedule and the network knows when they're
supposed to wake up (and they have to wake up periodically if only to
sync their clocks with the network).

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Jul 2015 19:17:44 +0200

> sync their clocks with the network).

That's a very different use case from this draft as currently written,
though.

Are you suggesting that this document should be extended to cover both and
provide separate advice to both? We can do that, but I don't think we
should make this document into a generic document that only says "do the
right thing for your link type". The reason we have this problem is that
vendors and operators do not necessarily know what the right thing for
their link type is.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Jul 2015 20:18:12 +0200

> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second…

First of all I support this document as a WG document.

But in terms of implementation, isn't it simpler to always(*) respond to 
a RS with a unicast RA?
As background, the text in RFC4861 comes from the old concern that all 
devices might boot at the same time when the power is re-established 
after a building power failure; that doesn't happen since most devices 
(laptops, smartphones, IoT devices) have batteries today. In that case 
it might have made sense to sending fewer RA messages by using multicast.

(*) the only case in RFC 4861 when I think a multicast response might be 
considered is when the source IPv6 address in the RS is the unspecified 
address. Further, an implementation which rate limits received RS 
packets (e.g., CoPP in a router) might also want to detect when the rate 
limit might have dropped RS packets and multicast an RA in that case.

I do wonder why implementations haven't already changed to send unicast 
solicited RA, and whether it would make a difference if we have an 
informational document asking them to do this. Alternatively we could 
have a proposed standard which updates section 6.2.6 to change the "MAY 
unicast" to a "SHOULD unicast".

FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.

Thanks,
    Erik

---

From: Tarko Tikan <[email-masked]>
Date: Mon, 20 Jul 2015 22:00:44 +0300

hey,

> What's the use case for a unicast unsolicited RA? They can only reach
> nodes for which the router knows the IPv6 addresses, and so pretty much
> require that routers keep a lot of state.

Another use case, not directly relevant to this draft, is targeting 
specific nodes for which RA should be injected.

This is required in shared L2 environments where you don't want to 
enable ipv6 for all nodes. This requires router to keep some sort of 
state or use external lookup (radius).

-- 
tarko

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 Jul 2015 20:34:16 +0000

Did you guys look at RFC-6085 ? We published this clarification mainly to support per-MN prefix model on shared links, by the use of L2 unicast RA's. Is that not sufficient ?

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 20, 2015 10:17 AM
To: Erik Kline <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

On Mon, Jul 20, 2015 at 7:04 PM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:

That's a very different use case from this draft as currently written, though.

Are you suggesting that this document should be extended to cover both and provide separate advice to both? We can do that, but I don't think we should make this document into a generic document that only says "do the right thing for your link type". The reason we have this problem is that vendors and operators do not necessarily know what the right thing for their link type is.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 21 Jul 2015 11:33:47 +0200

On 7/20/15, Erik Nordmark <[email-masked]> wrote:
>> If it were me implementing it, I think I would go about this in a little
>> different way, hopefully simpler. I would want to send at most one (e.g.,
>> either zero or one) RA per some interval (a second?). In the normal case,
>> that is sent unicast. However, having sent a unicast RA at time t, if I
>> now receive another RS before t+1, I send the next one (at time t+1) as a
>> multicast.
>

Yes. I did not respond on-list yet - but from operational perspective
"always send solRA unicast" / "always send solRA multicast" definitely
wins in my book, and I'd avoid premature optimizations (but maybe we
can say the implementers are explicitly free to do their own
optimizations if they see fit)

That said, will be very interesting to hear data from folks who will
run "all-unicast solRA", in real networks and then compare the effect
of their proposal optimizations on their real-world scenarios.

> solicited RA, and whether it would make a difference if we have an

TBH that's my concern as well. I think we should tweak the text in
4861 to encourage a bit more consideration on the implementer's side.

> unicast" to a "SHOULD unicast".

Yeah, I actually have had the different text aimed for 6man, but
Lorenzo's concern was 6man would say "there is no protocol update
here, go away", so he rewrote it for v6ops.

We should probably discuss this at the mic and get the opinion of the
6man chairs - if there is no outright "no" on this, a normative doc
would be a better way to convince the implementers ?

> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.

Nice catch, thanks!

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Jul 2015 11:35:49 +0200

On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark <[email-masked]> wrote:

> But in terms of implementation, isn't it simpler to always(*) respond to a
> RS with a unicast RA?
>

It would be simpler to document, yes, but I don't know that we should make
a one-size-fits all recommendation, because there might be link types or
environments where this is more expensive.

> devices might boot at the same time when the power is re-established after
> a building power failure; that doesn't happen since most devices (laptops,
> smartphones, IoT devices) have batteries today. In that case it might have
> made sense to sending fewer RA messages by using multicast.
>

This sort of thing can still happen. If lots of devices join at once,
(e.g., if something happens at a large-scale event when hundreds of people
pull their phones out of their pockets and turn them on at the same time),
it may well be cheaper for the network to send one multicast RA.

I'm not opposed to changing the standards as well, but I think respinning
RFC 4861 would require much more careful consideration than simply
publishing an operational guidance document such as this one. Perhaps we
can just recommend in this document that 6man consider this operational
need and consider modifying the protocol?

---

From: Gert Doering <[email-masked]>
Date: Tue, 21 Jul 2015 11:48:11 +0200

Hi,

> it may well be cheaper for the network to send one multicast RA.

I've been told that on a *Wifi* network, multicast never comes cheap
(so in the end your AP might just turn the multicast RA into 
unicast-to-all-stations anyway).

So I find that particular argument less than convincing.

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: Mark Smith <[email-masked]>
Date: Tue, 21 Jul 2015 19:50:40 +1000

On 21 July 2015 at 19:35, Lorenzo Colitti <[email-masked]> wrote:
> It would be simpler to document, yes, but I don't know that we should make a
> one-size-fits all recommendation, because there might be link types or
>> devices might boot at the same time when the power is re-established after a
>> building power failure; that doesn't happen since most devices (laptops,
> This sort of thing can still happen. If lots of devices join at once, (e.g.,
> if something happens at a large-scale event when hundreds of people pull
> their phones out of their pockets and turn them on at the same time), it may
> well be cheaper for the network to send one multicast RA.
>

Actually I've witnessed these sorts of events in recent times - when
1000s or 10s of 1000s of residential broadband subscribers come back
on-line after the BRAS/BNG has booted either due to failure or
maintenance, or the backhaul infrastructure between the BRAS/BNG and
subscribers has failed and recovered.

Unicast RAs in the specific scenarios I've seen it in though may not
have helped, as the subscribers were attached via individual PPPoE
sessions, so multicasting a single RA to many/all of them efficiently
might not be possible, unless there was some fancy hardware/firmware
that meant the control plane didn't have to do it.

However, if single link/multi-access methods of attaching subscribers
are used e.g., TR-101 N:1 VLAN, then solicited multicast RAs would
help significantly reduce the number of multicast RSes from CPE during
these events.

> publishing an operational guidance document such as this one. Perhaps we can
> just recommend in this document that 6man consider this operational need and
> consider modifying the protocol?

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Jul 2015 12:47:11 +0200

> But in terms of implementation, isn't it simpler to always(*) respond to a RS with a unicast RA?
> As background, the text in RFC4861 comes from the old concern that all devices might boot at the same time when the power is re-established after a building power failure; that doesn't happen since most devices (laptops, smartphones, IoT devices) have batteries today. In that case it might have made sense to sending fewer RA messages by using multicast.

in addition to Mark’s points.
 - what happens when the router reboots, will not all the hosts then try to actively reconnect?
   that router could server thousands of users.
 - while this is intended for WIFI networks, in common deployments the WIFI interface is not integrated in the router. for the router’s perspective this just looks like another wired interface. either this has to be made configurable and not the default, or considerations of large flat wired L2 networks must also be considered.

cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 Jul 2015 13:02:34 +0200

On 20 July 2015 at 22:34, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> Did you guys look at RFC-6085 ? We published this clarification mainly to
> support per-MN prefix model on shared links, by the use of L2 unicast RA's.
> Is that not sufficient ?

http://tools.ietf.org/html/rfc6085 seems useful and it should be referenced.

But I would not say it's sufficient, if only from an "explicit
clarity" standpoint.  I think explicit mention of RAs and the other
discussion is helpful for implementors not inclined to dig to great
depths or just seeking explicit confirmation.

---

From: Gert Doering <[email-masked]>
Date: Tue, 21 Jul 2015 13:16:45 +0200

Hi,

>  - what happens when the router reboots, will not all the hosts then try to actively reconnect?

Sending periodic unsolicited multicast RAs sounds still useful, like "at boot"
or "interface down/up events"...

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Jul 2015 21:25:18 +1000

> http://tools.ietf.org/html/rfc6085 seems useful and it should be referenced.

I thought that could be an option, however I encountered RSes without
the Source Link Layer Option, which means if RFC6085 is to be used,
the link-layer header has to be available to get the source link-layer
address from.

After I wondered about the efficiency benefit of using multicasts for
solicited RAs, Fred asked me to do some testing/investigation. I wrote
up what I found here, the few unusual RS cases I saw the following,
which I put down some thoughts about handling via e.g., RFC6085.

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

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Jul 2015 13:37:54 +0200

>  - what happens when the router reboots, will not all the hosts then try

It depends on whether the router is also the wifi access point. In general,
in the large wifi networks to which this draft is targeted, that is not the
case.

>  - while this is intended for WIFI networks, in common deployments the
> WIFI interface is not integrated in the router. for the router’s
> perspective this just looks like another wired interface. either this has
> to be made configurable and not the default, or considerations of large
> flat wired L2 networks must also be considered.
>

The router wouldn't need to know this, only the network administrator. If
the network administrator knew that a particular interface was providing
service to a network with a large number of mobile nodes, then the
administrator could configure that interface to send solicited RAs unicast.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 21 Jul 2015 12:42:16 +0000

IPv6 ND and DHCPv6 do support randomizing sending of messages for the use case below.     Also, if a DSL modem is reset because its L2 headend reloaded, the hosts behind the modem will likely not reset.  Thus the number of hosts reset is less.

Hemant

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Tuesday, July 21, 2015 5:51 AM
To: Lorenzo Colitti
Cc: v6ops list; [email-masked]
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

Actually I've witnessed these sorts of events in recent times - when 1000s or 10s of 1000s of residential broadband subscribers come back on-line after the BRAS/BNG has booted either due to failure or maintenance, or the backhaul infrastructure between the BRAS/BNG and subscribers has failed and recovered.

Unicast RAs in the specific scenarios I've seen it in though may not have helped, as the subscribers were attached via individual PPPoE sessions, so multicasting a single RA to many/all of them efficiently might not be possible, unless there was some fancy hardware/firmware that meant the control plane didn't have to do it.

However, if single link/multi-access methods of attaching subscribers are used e.g., TR-101 N:1 VLAN, then solicited multicast RAs would help significantly reduce the number of multicast RSes from CPE during these events.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 16:08:48 +0200

> - energy consumption on devices for more than one medium

and:

- fast handovers: on some links the more frequent the multicast RAs the
faster the handovers are, i.e. less packet loss for end nodes, less
glitches in the video conference stream.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 16:08:57 +0200

> A bit late but...I fully support the draft. Very useful work.

I agree.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Tue, 21 Jul 2015 08:38:05 -0700

It seems to me that the following algorithm would be relatively easy to implement
and provide reasonable network optimization…

On receipt of an RS:

	if(multicast_ra_time_remaining > 15 seconds)
	{
	  Send_Unicast_ra
	}
	else
	{
	  Send_Multicast_ra
	  reset_multicast_timer
	}

In this way, if the timing is reasonably close, you multicast a packet you were about to send
anyway, but if the timing isn’t close, you’re not wasting multicast bandwidth answering a single
node where nobody else cares.

Overall, I’ve always thought that multicast response to RS was kind of silly. It’s probably most
harmful on WiFi.

Owen

> On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko <[email-masked]> wrote:
>

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 21 Jul 2015 23:41:43 +0100

Hi Folks,

I support this document which is very informative, useful and its
implementation will certainly reduce energy consumption due to excessive
Multicast RA sent. The proposed algorithm seems to be suitable for this end
!

Best regards

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 21 Jul 2015 22:39:24 -0430

Hi There,
  I also support this document, it's very positive to see that this
algorithm will save energy.

Regards,

Alejandro,

El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió:
> implementation will certainly reduce energy consumption due to
> excessive Multicast RA sent. The proposed algorithm seems to be
> suitable for this end !
>
>
> Best regards
>
>
>
> On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > On 7/20/15, Erik Nordmark <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 22 Jul 2015 09:20:37 +0200

> On 21 Jul 2015, at 16:08, Alexandru Petrescu <[email-masked]> wrote:
>
>
>

If the network sends the periodic RAs frequently enough to avoid the
glitches of the video stream, this is explicitly *NOT* the network we
are concerned about in this draft.

Also, we wanted to be very focused what we talk about in this
document, to be able to ship it quicker.

We can say "does not apply to 802.11p, applies to 802.11(a|b|g|n|ac).
Applicability to other networks is left at readers' discretion".

Or something along these lines of that - feel free to propose the text
if the above is not what you had in mind.

--a

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 22 Jul 2015 10:19:22 +0200

My brain can not compile this pseudocode...

reset_multicast_timer resets multicast_ra_time_remaining to what value ?

In the large-scale WiFi networks I operate I send multicast RA once in
30 minutes, and an immediate unicast solicited RA upon RS.

If the "reset" is done to the MinRtrAdvInterval...MaxRtrAdvInterval,
then this algorithm would optimize last 15 seconds of these 30 minutes
?

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 12:22:38 +0200

Thanks for all the feedback. We have posted a -01 addressing some of the
feedback we got. The new version also contains a new recommendation not to
send periodic RAs too frequently, so we have changed the title to "Reducing
battery impact of Router Advertisements".

https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01

If there are no objections, we will upload this as a WG document in the
next few days.

On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta <
[email-masked]> wrote:

>> > On 7/20/15, Erik Nordmark < <[email-masked]>[email-masked]> wrote:
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:00:53 +0200

> are concerned about in this draft.

But mentioning 'mobile' for the nodes, makes think so.  Because fast 
address auto-configuration is a characteristic of mobile nodes.  One 
wants to spend as little time as possible waiting for RAs.  For that 
reason the multicast RAs period was reduced to milliseconds.

I agree.

> Applicability to other networks is left at readers' discretion".

I agree.  It should also say it does not apply to LTE.  BEcause in LTE 
an RA is sent on only one ptp link, there is no risk of waking up somebody.

> if the above is not what you had in mind.

On a scale MUST NOT, MAY, SHOULD - SHOULD is the right term.

"SHOULD [...] unless the network is of type LTE or 802.11p".

Or:

"SHOULD [...] unless there is an interest in as numerous RAs as possible 
to help in fast address auto-configuration to large number of mobiles".

or

"SHOULD [...] unless the Hosts are allowed to explicitely express 
interest in the multicast group dst of RA".

or

"SHOULD [...] unless RFC-MLD is updated to require Hosts to express 
interest in the multicast group dst of RA".

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:07:42 +0200

"Reducing battery impact of RAs on Androids"?

Alex

Le 22/07/2015 12:22, Lorenzo Colitti a écrit :
> feedback we got. The new version also contains a new recommendation not
> to send periodic RAs too frequently, so we have changed the title to
> "Reducing battery impact of Router Advertisements".
>
> On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi There,
>>         > On 7/20/15, Erik Nordmark
>>         <<mailto:[email-masked]>[email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 14:10:31 +0200

I'm told the problem affects iPhones as well.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:12:15 +0200

"... on Androids and iPhones"?

But not on huawei E392.

Alex

Le 22/07/2015 14:10, Lorenzo Colitti a écrit :
> On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         wrote:
>
>              Hi There,
>                  On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong
>             <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                      In this way, if the timing is reasonably close, you
>             multicast
>                      a packet you were about to send
>                      anyway, but if the timing isn’t close, you’re not
>             wasting
>                      multicast bandwidth answering a single
>                      Overall, I’ve always thought that multicast
>             response to RS was
>                      kind of silly. It’s probably most
>                      harmful on WiFi.
>
>                      Owen
>
>                      <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>                      >
>                      <<mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>
>
>                      <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>                      >>>> So the next logical thing to do would be to
>             have the
>                      router default to
>                      >>>> threshold to cover this sort of situation.
>             Once the
>                      number of RSes
>                      >>>> That would get rid of the configuration knob
>             proposed in
>                      this ID, and
>                      >>>> is behaviour that I think could be universal
>             for all link
>                      types,
>                      >>>> rather than just for the case of wireless ones
>             with
>                      mobile devices.
>                      >>> If it were me implementing it, I think I would
>             go about
>                      this in a little
>                      >>> different way, hopefully simpler. I would want
>             to send at
>                      most one (e.g.,
>                      >>> either zero or one) RA per some interval (a
>             second?). In
>                      the normal case,
>                      >>> that is sent unicast. However, having sent a
>             unicast RA at
>                      time t, if I
>                      >>> now receive another RS before t+1, I send the
>             next one (at
>                      time t+1) as a
>                      >>> multicast.
>                      >>
>                      > Yes. I did not respond on-list yet - but from
>             operational
>                      perspective
>                      > "always send solRA unicast" / "always send solRA
>             multicast"
>                      definitely
>                      > wins in my book, and I'd avoid premature
>             optimizations (but
>                      maybe we
>                      > That said, will be very interesting to hear data
>             from folks
>                      who will
>                      > run "all-unicast solRA", in real networks and
>             then compare
>                      the effect
>                      >> As background, the text in RFC4861 comes from
>             the old
>                      concern that all
>                      >> devices might boot at the same time when the
>             power is
>                      re-established
>                      >> after a building power failure; that doesn't
>             happen since
>                      most devices
>                      >> (laptops, smartphones, IoT devices) have
>             batteries today.
>                      In that case
>                      >> it might have made sense to sending fewer RA
>             messages by
>                      using multicast.
>                      >>
>                      >> (*) the only case in RFC 4861 when I think a
>             multicast
>                      response might be
>                      >> considered is when the source IPv6 address in
>             the RS is the
>                      unspecified
>                      >> address. Further, an implementation which rate
>             limits
>                      received RS
>                      >> packets (e.g., CoPP in a router) might also want
>             to detect
>                      when the rate
>                      >> limit might have dropped RS packets and
>             multicast an RA in
>                      that case.
>                      >>
>                      >>
>                      >> I do wonder why implementations haven't already
>             changed to
>                      send unicast
>                      >> solicited RA, and whether it would make a
>             difference if we
>                      have an
>                      >
>                      > TBH that's my concern as well. I think we should
>             tweak the
>                      text in
>                      >> have a proposed standard which updates section
>             6.2.6 to
>                      change the "MAY
>                      > Lorenzo's concern was 6man would say "there is no
>             protocol
>                      update
>                      > We should probably discuss this at the mic and
>             get the
>                      opinion of the
>                      >> FWIW the draft incorrectly refers to section
>             6.2.4 instead
>                      of 6.2.6.
>                      >
>                      > Nice catch, thanks!
>                      >
>                      > --a
>                      >
>                      >>
>                      >> Thanks,
>                      >>    Erik
>                      >>
>                      >>>
>                      >>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 14:13:52 +0200

I'm sure that the huawei E392 obeys the laws of physics as well.

On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu <
[email-masked]> wrote:

>>                      > On Jul 21, 2015, at 02:33 , Andrew 
>> Yourtchenko
>>                      >>>> unicast Router Advertisements, measure the rate
>> of
>>                      received Router
>>                      >> But in terms of implementation, isn't it simpler
>> to
>>                      always(*) respond to
>>                      >> a RS with a unicast RA?
>>                      >
>>                      > 6man chairs - if there is no outright "no" on
>> this, a
>>                      normative doc

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:26:45 +0200

Hmm, it's different hardware, different drivers, different brand names. 
  They have different energy consumption, I measured that.

For the laws of physics: I am interested in asking, and give opinion, 
about how much energy it takes to send or receive one 1280 MTU IPv6 
packet.

I looked at the presentation in 6man titled "Preliminary RA power 
observations on wifi".

There was a RG called EERG which died recently and seemed to discuss 
this as well.

But we dont have an agreement about how much energy packets take, and 
whether or not it's worth trying to make protocols more or less 
energy-aware.

Alex

Le 22/07/2015 14:13, Lorenzo Colitti a écrit :
> On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>                  Thanks for all the feedback. We have posted a -01
>         addressing
>                  some of the
>                  If there are no objections, we will upload this as a WG
>         document
>                  in the
>                  next few days.
>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>>
>                  wrote:
>
>                       Hi There,
>                          I also support this document, it's very
>         positive to see
>                  that this
>                           implementation will certainly reduce energy
>         consumption
>                      due to
>                           excessive Multicast RA sent. The proposed
>         algorithm
>                      seems to be
>                           suitable for this end !
>
>
>                           Best regards
>
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                           <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>
>                               It seems to me that the following
>         algorithm would be
>                               relatively easy to implement
>                               <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>                               >
>         <mailto:[email-masked]>>>[email-masked]
>                      <mailto:[email-masked] <mailto:[email-masked]>>
>
>                               <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>                               >>>> unicast Router Advertisements,
>         measure the rate of
>                               received Router
>                               >>>> Solicitations, and switch to
>         multicast RA mode
>                      past a certain
>                               >> First of all I support this document as
>         a WG
>                      document.
>                               >>
>                               >> But in terms of implementation, isn't
>         it simpler to
>                               always(*) respond to
>                               >> a RS with a unicast RA?
>                               >
>                               > can say the implementers are explicitly
>         free to
>                      do their own
>                               > 4861 to encourage a bit more
>         consideration on the
>                               implementer's side.
>                               >
>                               >> informational document asking them to
>         do this.
>                               Alternatively we could
>                               > 6man chairs - if there is no outright
>         "no" on this, a
>                               normative doc
>                      <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                               >>>
>                      <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                      <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                      <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                      <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Jen Linkova <[email-masked]>
Date: Wed, 22 Jul 2015 14:31:36 +0200

> "... on Androids and iPhones"?

I'm not sure what the fact that huawei E392 is not affected by a
particular issue proves.
So far we know that
- there are platforms affected;
- there is one unaffected platform.

Therefore I believe it is perfectly find for the title to be 'Reducing
battery impact of Router Advertisements'. If a particular network and
its devices are not affected - good, the network administrators MAY
(or SHOULD?) ignore the draft and not apply the recommendations.

>>                      > On Jul 21, 2015, at 02:33 , Andrew Yourtchenko

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 22 Jul 2015 14:36:51 +0200

> On 22 Jul 2015, at 14:00, Alexandru Petrescu <[email-masked]> wrote:
> 
> 
> 
> But mentioning 'mobile' for the nodes, makes think so.  Because fast address auto-configuration is a characteristic of mobile nodes.  One wants to spend as little time as possible waiting for RAs.  For that reason the multicast RAs period was reduced to milliseconds.

Yes. We made changes in the newly submitted -01 to make it clearer which networks it will apply to, hopefully it clarifies the scope enough.

--a

> I agree.  It should also say it does not apply to LTE.  BEcause in LTE an RA is sent on only one ptp link, there is no risk of waking up somebody
> 
> "SHOULD [...] unless there is an interest in as numerous RAs as possible to help in fast address auto-configuration to large number of mobiles".
> 
> or
> 
> "SHOULD [...] unless the Hosts are allowed to explicitely express interest in the multicast group dst of RA".
> 
> or
> 
> "SHOULD [...] unless RFC-MLD is updated to require Hosts to express interest in the multicast group dst of RA".
> 
> Alex
> 
>> 
>> --a
>> 
>>> Alex
>>> 
>>>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 14:41:41 +0200

> I'm not sure what the fact that huawei E392 is not affected by a

We don't know if the huawei E392 is affected by this issue until someone
with access to that hardware (Alexandru?) can determine which of the three
behaviours in section 3 it exhibits.

Until we know that, we cannot use that as a basis for discussion.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:46:02 +0200

Le 22/07/2015 14:41, Lorenzo Colitti a écrit :
> On Wed, Jul 22, 2015 at 2:31 PM, Jen Linkova <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> with access to that hardware (Alexandru?) can determine which of the
> three behaviours in section 3 it exhibits.
>

Ok, that could be measured, but it's an LTE USB key.

Let me try another USB WiFi dongle (maybe a tp-link).  Would this apply?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 14:48:35 +0200

> Let me try another USB WiFi dongle (maybe a tp-link).  Would this apply?

Those aren't battery-powered devices.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:53:57 +0200

Le 22/07/2015 14:48, Lorenzo Colitti a écrit :
> On Wed, Jul 22, 2015 at 2:46 PM, Alexandru Petrescu

They are battery-powered devices, except the batteries are bigger.  So 
maybe "various size battery devices"?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 14:59:23 +0200

> maybe "various size battery devices"?

Ok, we can change "battery-powered" to "exclusively battery-powered" in the
next revision of the draft.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 15:02:42 +0200

> - there is one unaffected platform.

I think we discuss here a smartphone world.

Android and smartphones in general are great things that happened to 
Internet, but there is more to it: raspberry pis, and various other 
small yet non-smartphone platforms.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 15:04:32 +0200

Le 22/07/2015 14:59, Lorenzo Colitti a écrit :
> On Wed, Jul 22, 2015 at 2:53 PM, Alexandru Petrescu
>     They are battery-powered devices, except the batteries are bigger.
>     So maybe "various size battery devices"?
>
>
> Ok, we can change "battery-powered" to "exclusively battery-powered" in
> the next revision of the draft.

No, I didnt mean that.

Maybe "exclusively li-ion 7.2V 700maH batteries".

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 15:15:33 +0200

> Maybe "exclusively li-ion 7.2V 700maH batteries".

"Devices where network communication has non-negligible affect on battery
life"

---

From: Jared Mauch <[email-masked]>
Date: Wed, 22 Jul 2015 10:27:11 -0400

> "Devices where network communication has non-negligible affect on battery

	While this is clearly obvious on devices that require sipping
power that they are not working right, it may exist in other devices
or poorly implemented hardware on wired devices which are asleep.  Dave
Thaler talked yesterday about the logo requirements for MSFT in the hardware
to do ARP and NDP offload.

	I suspect instead of arguging about the nits here some generic
text would be most constructive.  Call it "Green" to use lower power
by having unicast vs multicast/broadcast traffic.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 22 Jul 2015 15:48:43 +0100

another title alternative could be: "Towards an eco-friendly Router
Advertisements"

Best regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 17:25:37 +0200

I agree, 'green devices' is right.

But dont make it that multicast is expensive in terms of energy. 
Actually multicast is a tool to make devices save on energy.

Alex

---

From: Gert Doering <[email-masked]>
Date: Wed, 22 Jul 2015 17:26:43 +0200

Hi,

> Actually multicast is a tool to make devices save on energy.

Read up on how multicast on wifi works.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 17:52:10 +0200

> Read up on how multicast on wifi works.

Make sure you look at
http://www.slideshare.net/ArubaNetworks/atoz-design-guide-for-the-allwireless-workplace
slide 20, which says that unicast can negatively affect battery life.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 22 Jul 2015 13:31:29 -0700

> On Jul 22, 2015, at 01:19 , Andrew 👽 Yourtchenko <[email-masked]> wrote:
> 

To whatever value it would get reset to when a multicast_ra is transmitted normally.

Why is this difficult to comprehend?

> 30 minutes, and an immediate unicast solicited RA upon RS.

Seems reasonable.

> then this algorithm would optimize last 15 seconds of these 30 minutes

Yep.

If you think the 15s mark should be increased, I’ve got no problem with that…

If you think it should be configurable, I’m OK with that, too.

If you think it should be computed as a fraction of some value related to {Min,Max}RtrAdvInterval,
then propose something, I’m probably OK with that as well.

The point is it seems to me if you’re reasonably close to transmitting a multicast, then it makes
sense to answer the solicitation with a multicast and reset the multicast timer. Otherwise, send
a unicast RA.

If this seems like a good idea other than arguing about the value of “reasonably close”, then I
think we’re in general agreement and I’m mostly willing to let others pick the value or formula
for determining “reasonably close”.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 22 Jul 2015 13:36:26 -0700

> On Jul 22, 2015, at 05:48 , Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Jul 22, 2015 at 2:46 PM, Alexandru Petrescu <[email-masked] <mailto:[email-masked]>> wrote:

They are a lot of the time… Much of the time, they are plugged into laptops not necessarily plugged into the wall.

In those cases, yes, they are running on (admittedly fairly large) batteries.

Therefore, even for those cases, reducing battery consumption of RAs may be helpful.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 22 Jul 2015 13:37:05 -0700

Please don’t. Alexandru seems to be the only one who cares about this nit and I really don’t think his argument
is all that valid.

Owen

> On Jul 22, 2015, at 05:59 , Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Jul 22, 2015 at 2:53 PM, Alexandru Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> They are battery-powered devices, except the batteries are bigger.  So maybe "various size battery devices"?
> 
> Ok, we can change "battery-powered" to "exclusively battery-powered" in the next revision of the draft.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jul 2015 00:21:51 +0200

> o  RSes with a link-local source addresses, but no Source Link-Layer

Yes, both of those are important (I had forgotten about the second one).

As you say, an implementation might be able to use the link-layer header 
and unicast back a packet. If the source was :: then that approach would 
rely on sending to the multicast ff02::1 while the link-layer 
destination is unicast.

If not, then the implementation needs to multicast the RA.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jul 2015 00:31:19 +0200

On 7/21/15 11:35 AM, Lorenzo Colitti wrote:
> On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark <[email-masked] 
> It would be simpler to document, yes, but I don't know that we should 
> make a one-size-fits all recommendation, because there might be link 
> types or environments where this is more expensive.
I don't think we should be too prescriptive, but it sounds like we 
should at least require that routers have support for unicast solicated RAs.
One could also argue that the default should be to unicast solicited RAs.
>
>     As background, the text in RFC4861 comes from the old concern that
>     all devices might boot at the same time when the power is
>     re-established after a building power failure; that doesn't happen
>     since most devices (laptops, smartphones, IoT devices) have
>     batteries today. In that case it might have made sense to sending
>     fewer RA messages by using multicast.
>
>
> (e.g., if something happens at a large-scale event when hundreds of 
> people pull their phones out of their pockets and turn them on at the 
> same time), it may well be cheaper for the network to send one 
> multicast RA.
>
> I'm not opposed to changing the standards as well, but I think 
> respinning RFC 4861 would require much more careful consideration than 
> simply publishing an operational guidance document such as this one. 
> Perhaps we can just recommend in this document that 6man consider this 
> operational need and consider modifying the protocol?
But the draft sort of does in suggesting the operator to enable a knob 
(unicast solicited RAs) which does not exist in many implementations 
because it isn't required. Hence you are placing requirements on 
implementations.
If a v6ops informational document gets the work done (i.e., get those 
implementations updated) then we're ok. But if we need a more forceful 
message ... then a short document which updates section 6.2.6 in RFC 
4861 isn't that difficult.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jul 2015 00:39:18 +0200

>   - while this is intended for WIFI networks, in common deployments the WIFI interface is not integrated in the router. for the router’s perspective this just looks like another wired interface. ei…

Ole,

Even on a flat wired L2 network I don't think it is harmful to default 
to unicast solicited RAs.

If we take a worst case of 10000 hosts on the L2 network all 
rebooting/initializing at the same time, we will see:
  - 10000 DAD probes for link-local address
  - 10000 MLD joins for the solicited node MC for their link-locals
  - 10000 RS messages(*)
  - 1/10000 RA messages
  - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link)
  - N x 10000 mDNS etc type packets

(*) RFC 4861 suggests receiving an RA before an RS is sent, thus under 
some timing conditions some RS messages might be avoided.

But at best we seem to be talking about saving 20% of the packet during 
the boot of the 10000 hosts.

    Erik

---

From: Owen DeLong <[email-masked]>
Date: Wed, 22 Jul 2015 16:14:06 -0700

> On Jul 22, 2015, at 15:39 , Erik Nordmark <[email-masked]> wrote:
> 
> Even on a flat wired L2 network I don't think it is harmful to default to unicast solicited RAs.
> 
> If we take a worst case of 10000 hosts on the L2 network all rebooting/initializing at the same time, we will see:

As was pointed out earlier, we shouldn’t see MLD joins for LL solicited nodes or any other LinkScoped group, unless I am badly misunderstanding things.

> - 1/10000 RA messages

I think you mean 1 to 10000 because I don’t think fractional messages are possible.

> (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under some timing conditions some RS messages might be avoided.
> 
> But at best we seem to be talking about saving 20% of the packet during the boot of the 10000 hosts.

True… However, even if this is an actual concern, we could consider a threshold in PPS where we send an RA Mcast response.

e.g. if more than 10 RS received in 1 second, send a multicast RA.

In fact, we could probably get away with delaying an RA response to RS for 250ms. If another RS arrives during that delay, respond multicast, else unicast.

That probably still eliminates most of the RA traffic, may eliminate many of those 10000 RS messages, and could provide kind of the best of both worlds.
I’m not sure how hard it would be to implement in silicon, however.

Owen

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 23 Jul 2015 01:52:34 +0200

> On 23 Jul 2015, at 01:14, Owen DeLong <[email-masked]> wrote:
> 
> 

You will see MLD for anything that is not ff02::1. Unlike in IPv4, which does not require LL joins.

RFC3810 talks about this I think.

--a

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jul 2015 10:37:05 +1000

Hi Erik,

On 23 July 2015 at 08:21, Erik Nordmark <[email-masked]> wrote:
> As you say, an implementation might be able to use the link-layer header and
> unicast back a packet. If the source was :: then that approach would rely on
> sending to the multicast ff02::1 while the link-layer destination is
> unicast.
>

I was wondering if instead the implementation could trigger an ND/NS
transaction for the RS source address at that point, and then unicast
the RA when that completes.

RFC4861 seems to be a bit vague about being able to do that. It says
that if the SLLO is not present, the router still can unicast the RA.
As RFC4861 is pre RFC6085, then performing a ND/NS first would be the
only way to do that. The last sentence also seems to be permitting NC
entries to be created when there is no SLLO ("or not a Source
Link-Layer is provided" ... "Neighbor Cache entry" ... "(or is
created)").

Performing an NS/ND to resolve the source address of the RS without a
SLLO would seem consistent with the corresponding RS SLLO handling -
to load the Neighbor Cache with entries for nodes that have sent RSes.

Regards,
Mark.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 23 Jul 2015 04:09:56 -0700

> for determining “reasonably close”.

Upon more thinking, this algorithm is actually a harmful idea -
regardless of the settings it does not save any packets while
deceiving everyone involved (including yourself) that it does, and is
of course more complex than a single knob.

--a

>>> In this way, if the timing is reasonably close, you multicast a packet
>>> you
>>> were about to send
>>>>>> now receive another RS before t+1, I send the next one (at time t+1)
>>>>>> as
>>>>>> a
>>>>>> multicast.
>>>>>

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 Jul 2015 04:33:10 -0700

Owen,

> As was pointed out earlier, we shouldn’t see MLD joins for LL solicited nodes or any other LinkScoped group, unless I am badly misunderstanding things.

a quick wireshark on the IETF wireless shows lots of MLD for solicited node multicast addresses as well as other link-scoped addresses.

we put that in there under the assumption that we needed to, to deal with MLD snooping switches. I’m not sure that assumption held true.

> I’m not sure how hard it would be to implement in silicon, however.

the issue isn’t necessarily link-utilisation.
there are router control planes that would rate-limit 10000 RS messages / second. I agree with Owen and I don’t think we can make a blanket statement that RS replies should always be unicast.

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jul 2015 18:25:45 +0200

> As was pointed out earlier, we shouldn’t see MLD joins for LL solicited nodes or any other LinkScoped group, unless I am badly misunderstanding things.
Owen,
The RFC says to send them for everything but ff02::1 (all-nodes).
> I think you mean 1 to 10000 because I don’t think fractional messages are possible.

Sorry for not explaining my notation. I meant 1 vs. 10000 depending on 
whether multicast or unicast RA is used.
Point is that the saving isn't that large given the other required 
packets during host interface initialization.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jul 2015 18:26:14 +0200

> the RA when that completes.
That would only address the lack of SLLAO case; not the unspecified 
source address case.
I don't know how common these cases are in existing implementations.
The unspecified source would appear if the host is doing DAD in parallel 
with sending the RS.
I don't know when a host would omit the SLLAO in the RS.

>     flag MUST be set to FALSE."
I think the attempt at english as opposed to pseudo-code is hard to read.
AFAIK the intent was
     if NCE
         set NCE IsRouter to FALSE

Thus the NCE might have already existed, or have been created.

I think there is text earlier to say to not create an NCE for 0::0 nor 
if there is no SLLAO (unless the link-layer has no addresses).

Regards,
    Erik

---

From: Mark Smith <[email-masked]>
Date: Mon, 27 Jul 2015 15:13:35 +1000

Hi Erik,

<snip>

> That would only address the lack of SLLAO case; not the unspecified source
> address case.

True. I think the only option to unicast responses for unspecified
source address cases would be link-layer unicast option.

> The unspecified source would appear if the host is doing DAD in parallel

I did some capturing/research related to this draft, Windows XP was
issuing unspecified source RSes at boot, then using link-local sourced
RSes, although the later versions of Windows I looked at didn't.

> I don't know when a host would omit the SLLAO in the RS.

I think it would be fairly common at the moment. The Linux user
interface oriented Network Manager utility
(https://wiki.gnome.org/Projects/NetworkManager), used by at least
Fedora, is sending RSes without the SLLAO, as it uses the libndp.org
library, which only seems to currently support building a minimal
generic RS without the SLLAO option, and there doesn't seem to be an
obvious library call to add an SLLAO to the generic RS.

<snip>

>
> I think there is text earlier to say to not create an NCE for 0::0 nor if
> there is no SLLAO (unless the link-layer has no addresses).
>

I've done some more searching of RFC4861, and haven't seemed to find
anything that specifically prohibits creating an NCE via a ND/NS
transaction for a RS without an SLLAO.

Thinking about it more, triggering an ND/NS to resolve the source
address of the RS if there is no SLLAO may not be all that beneficial,
as it effectively substitutes a multicast ND for a multicast RA. There
might be some other benefits from having router(s) having proactively
resolve a host's link-local RS source address that make trading a
multicast RA for a multicast ND worth while.

Regards,
Mark.