[Catching up on email]
Benedikt,
Note that https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00 is
an attempt at addressing refresh without a multicast RA every 3 seconds,
by only having the host do this refresh when it knows that the router
doesn't default to multicasting solicited
Hi Lorenzo and list,
Lorenzo Colitti lore...@google.com writes:
On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand
b...@stepladder-it.com wrote:
they should at least send an RS when they wake up and ensure their
configuration is still up to date.
That sounds like a bad
On 6/12/15 1:11 AM, Lorenzo Colitti wrote:
Ole said:
do we agree that a host that wakes up and has expired its last
default router should restart router discovery?
In my mind this makes a lot of sense.
That's not necessary. For things to work well a host needs to be able to
maintain
On 12 Jun 2015, at 5:31 , Lorenzo Colitti lore...@google.com wrote:
On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand
b...@stepladder-it.com wrote:
they should at least send an RS when they wake up and ensure their
configuration is still up to date.
That sounds like a bad idea. If
Hi folks,
I can't give you a decisive reference for where it's defined, but the
default maximum interval is 600 seconds and the minimum interval is one
third of that (200 seconds, not 180). The 1800s value may be a
misinterpretation of the router lifetime field in the RAs, which has a
default
Hi Tore and list,
Tore Anderson t...@fud.no writes:
There was another thing I thought of, though. We have a wireless
network with two redundant upstream routers that are not running a FHRP
like VRRP. Active/passive, since they do stateful inspection of
traffic. My solution to facilitate
Hi,
On Thu, Jun 11, 2015 at 09:56:45AM +, Benedikt Stockebrand wrote:
As far as tweaking these values to deal with some sleepy devices is
concerned: I'd personally prefer to consider these devices broken; they
should at least send an RS when they wake up and ensure their
configuration is
Please read some IETF draft related to NDP/multicast/WiFi issues (Lorenzo
is very active there).
Multicast RA are not really needed anyway, some 'high market' (see my
email address) AP have dozens of tricks to reply to RS with a UNIcast RA,
and trying to reduce the amount of NDP mcast.
If you
Lorenzo
On 10 June 2015 at 18:23, Lorenzo Colitti lore...@google.com wrote:
John,
are *all* IPv6 packets blocked, or just multicast packets? I know that a
number of devices will drop multicast IPv6 packets. This eventually
blackholes connections because the device stops receiving RAs and
* Lorenzo Colitti lore...@google.com
On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson t...@fud.no wrote:
are *all* IPv6 packets blocked, or just multicast packets? I know
that a number of devices will drop multicast IPv6 packets. This
eventually blackholes connections because the device
I see that. I don’t think the problem is confined to Samsung or that it can
be completed solved in isolation from fixing wireless AP router behaviour.
At the edge of the WiFi network I also see the IPv6 connectivity dropping
while IPv4 stays up. I’ve a ZyXEL home router that sends periodic
On 10/06/15 18:23, Lorenzo Colitti wrote:
are *all* IPv6 packets blocked, or just multicast packets? I know
that a number of devices will drop multicast IPv6 packets.
On that note, some wireless access points have the ability to convert multicast
packets into unicast packets. Both the Cisco
* Lorenzo Colitti
are *all* IPv6 packets blocked, or just multicast packets? I know
that a number of devices will drop multicast IPv6 packets. This
eventually blackholes connections because the device stops receiving
RAs and thus loses its default route, but that can be worked around
by
On 10 Jun 2015, at 10:33, erik.tarald...@telenor.com
erik.tarald...@telenor.com wrote:
I believe our Cisco equipment defaults to 10 minutes (600 seconds). There
will also be RAs in response
to RS messages.
From the googeling I've done it seems that the defaults span from 180 to 600
On 10 Jun 2015, at 06:33, John Mann john.m...@monash.edu wrote:
Hi,
We have noticed that Samsung Android phones and tablets on dual-stack
IPv4/IPv6 WiFi experience delayed Google notifications when the screen is off.
This issue is blocking the enabling of IPv6 across our large campus
On 10 Jun 2015, at 10:20, erik.tarald...@telenor.com
erik.tarald...@telenor.com wrote:
I see that. I don’t think the problem is confined to Samsung or that it can
be completed solved in isolation from fixing wireless AP router behaviour.
At the edge of the WiFi network I also see the IPv6
16 matches
Mail list logo
