Mailing List Archive

> If the delegated prefix changes, you'll be simply postponing the local
> communication failure, not prevent it.
Only if the new prefix is different to the old one.

> The last year has convinced me that the best user experience is
> achieved by having an in-home stable ULA prefix to complement the
> ISP-delegated global prefix[es] [if any], and that all the internal
> hostnames should resolve to the IPv6 addresses assigned from the ULA
> prefix.
Yes, but this is probably a bit different to the AVM behavior. I have in
mind that the default configuration on Fritzboxes is to announce the ULA
*only* if the upstream is down. Then your local active sessions breaks
twice.

Holger

>> Imagine a setup with *two* routers. One of them has broken Internet,
>> the other is working. How can the hosts decide if both keep announcing
>> themselves as "I can reach anything"?
>
> in the general case the host still has to take the 'I can reach anything' announcement with a pinch of salt.
> and it should be able to try both (or more) connections and react accordingly when one fails.
...which is the default host behaviour if the OS supports RFC4861.
Sadly some "user friendly" network mangers breaks this and setting a
static route with a better metric to just one(!) router.

Holger

Am 14.10.2016 um 13:57 schrieb Holger Zuleger:
>> If the delegated prefix changes, you'll be simply postponing the local
>> communication failure, not prevent it.
> Only if the new prefix is different to the old one.

I get never the same prefix! (ISP DTAG, private consumer)


>
>> The last year has convinced me that the best user experience is
>> achieved by having an in-home stable ULA prefix to complement the
>> ISP-delegated global prefix[es] [if any], and that all the internal
>> hostnames should resolve to the IPv6 addresses assigned from the ULA
>> prefix.
> Yes, but this is probably a bit different to the AVM behavior. I have in
> mind that the default configuration on Fritzboxes is to announce the ULA
> *only* if the upstream is down. Then your local active sessions breaks
> twice.

The default/recommended(by AVM) behavior is still so.
I agree Tore. I use ULA(permanent on) for local NAS to avoid internal
interruptions. (cifs)

Thomas



--

There’s no place like ::1

Thomas Schäfer (Systemverwaltung)
Ludwig-Maximilians-Universität
Centrum für Informations- und Sprachverarbeitung
Oettingenstraße 67 Raum C109
80538 München ☎ +49/89/2180-9706 ℻ +49/89/2180-9701

Holger,

>>> Imagine a setup with *two* routers. One of them has broken Internet,
>>> the other is working. How can the hosts decide if both keep announcing
>>> themselves as "I can reach anything"?
>>
>> in the general case the host still has to take the 'I can reach anything' announcement with a pinch of salt.
>> and it should be able to try both (or more) connections and react accordingly when one fails.
> ...which is the default host behaviour if the OS supports RFC4861.
> Sadly some "user friendly" network mangers breaks this and setting a
> static route with a better metric to just one(!) router.

not really. that only covers the first hop. any failure anywhere else along the path would not be dealt with by 4861.

cheers,
Ole

On 14.10.2016 14:33, otroan@employees.org wrote:
> Holger,
>
>>>> Imagine a setup with *two* routers. One of them has broken Internet,
>>>> the other is working. How can the hosts decide if both keep announcing
>>>> themselves as "I can reach anything"?
>>>
>>> in the general case the host still has to take the 'I can reach anything' announcement with a pinch of salt.
>>> and it should be able to try both (or more) connections and react accordingly when one fails.
>> ...which is the default host behaviour if the OS supports RFC4861.
>> Sadly some "user friendly" network mangers breaks this and setting a
>> static route with a better metric to just one(!) router.
>
> not really. that only covers the first hop. any failure anywhere else along the path would not be dealt with by 4861.
Yes, of course, you're right.

But coming back to Brians problem.
The behavior of his router is confirm to RFC7084:

"G-4: By default, an IPv6 CE router that has no default router(s) on
its WAN interface MUST NOT advertise itself as an IPv6 default
router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it
originates [RFC4861]."

But this would break local connectivity if the router does not also
fulfill L-3

"L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface."

So far so good. But if the host doesn't honour the RIO then again local
connectivity is broken.

So take a look at the reasons for this. The second paragraph of 3.2.1 says:

"At the time of this writing, several host implementations do not
handle the case where they have an IPv6 address configured and no
IPv6 connectivity, either because the address itself has a limited
topological reachability (e.g., ULA) or because the IPv6 CE router is
not connected to the IPv6 network on its WAN interface. To support
host implementations that do not handle multihoming in a multi-prefix
environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
as detailed in the requirements below, advertise itself as a default
router on the LAN interface(s) when it does not have IPv6
connectivity on the WAN interface or when it is not provisioned with
IPv6 addresses. For local IPv6 communication, the mechanisms
specified in [RFC4191] are used."

At the end, the whole behavior is because some host have problems in
handling situations where they have an IPv6 address configured and now
internet connectivity. But the solution to this requires that the host
is able to understand and work with RIO options, which seams to be "at
the time" not generally the case.

Do we replace one evil by another?

BR
Holger

> At the end, the whole behavior is because some host have problems in
> handling situations where they have an IPv6 address configured and now
> internet connectivity. But the solution to this requires that the host
> is able to understand and work with RIO options, which seams to be "at
> the time" not generally the case.
>
> Do we replace one evil by another?

I like Tore's solution of using ULA for local communication even when
the external link is down.

Steinar Haug, AS2116

Holger,

>>
>>>>> Imagine a setup with *two* routers. One of them has broken Internet,
>>>>> the other is working. How can the hosts decide if both keep announcing
>>>>> themselves as "I can reach anything"?
>>>>
>>>> in the general case the host still has to take the 'I can reach anything' announcement with a pinch of salt.
>>>> and it should be able to try both (or more) connections and react accordingly when one fails.
>>> ...which is the default host behaviour if the OS supports RFC4861.
>>> Sadly some "user friendly" network mangers breaks this and setting a
>>> static route with a better metric to just one(!) router.
>>
>> not really. that only covers the first hop. any failure anywhere else along the path would not be dealt with by 4861.
> Yes, of course, you're right.
>
> But coming back to Brians problem.
> The behavior of his router is confirm to RFC7084:
>
> "G-4: By default, an IPv6 CE router that has no default router(s) on
> its WAN interface MUST NOT advertise itself as an IPv6 default
> router on its LAN interfaces. That is, the "Router Lifetime"
> field is set to zero in all Router Advertisement messages it
> originates [RFC4861]."
>
> But this would break local connectivity if the router does not also
> fulfill L-3
>
> "L-3: An IPv6 CE router MUST advertise itself as a router for the
> delegated prefix(es) (and ULA prefix if configured to provide
> ULA addressing) using the "Route Information Option" specified
> in Section 2.3 of [RFC4191]. This advertisement is
> independent of having or not having IPv6 connectivity on the
> WAN interface."
>
> So far so good. But if the host doesn't honour the RIO then again local
> connectivity is broken.
>
> So take a look at the reasons for this. The second paragraph of 3.2.1 says:
>
> "At the time of this writing, several host implementations do not
> handle the case where they have an IPv6 address configured and no
> IPv6 connectivity, either because the address itself has a limited
> topological reachability (e.g., ULA) or because the IPv6 CE router is
> not connected to the IPv6 network on its WAN interface. To support
> host implementations that do not handle multihoming in a multi-prefix
> environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
> as detailed in the requirements below, advertise itself as a default
> router on the LAN interface(s) when it does not have IPv6
> connectivity on the WAN interface or when it is not provisioned with
> IPv6 addresses. For local IPv6 communication, the mechanisms
> specified in [RFC4191] are used."
>
> At the end, the whole behavior is because some host have problems in
> handling situations where they have an IPv6 address configured and now
> internet connectivity. But the solution to this requires that the host
> is able to understand and work with RIO options, which seams to be "at
> the time" not generally the case.
>
> Do we replace one evil by another?

Yes, we did.
This work was done at the time of "host IPv6 brokenness".
Perhaps time to revisit those decisions?

Best regards,
Ole

On 14.10.2016 15:20, sthaug@nethelp.no wrote:
>> At the end, the whole behavior is because some host have problems in
>> handling situations where they have an IPv6 address configured and now
>> internet connectivity. But the solution to this requires that the host
>> is able to understand and work with RIO options, which seams to be "at
>> the time" not generally the case.
>>
>> Do we replace one evil by another?
>
> I like Tore's solution of using ULA for local communication even when
> the external link is down.
That's not the question. The question is: Should a router stop
advertising a default route if the (or better say "his") upstream link
is down.

Holger

On 14.10.2016 15:26, otroan@employees.org wrote:
> Holger,
>
>>>
>>>>>> Imagine a setup with *two* routers. One of them has broken Internet,
>>>>>> the other is working. How can the hosts decide if both keep announcing
>>>>>> themselves as "I can reach anything"?
>>>>>
>>>>> in the general case the host still has to take the 'I can reach anything' announcement with a pinch of salt.
>>>>> and it should be able to try both (or more) connections and react accordingly when one fails.
>>>> ...which is the default host behaviour if the OS supports RFC4861.
>>>> Sadly some "user friendly" network mangers breaks this and setting a
>>>> static route with a better metric to just one(!) router.
>>>
>>> not really. that only covers the first hop. any failure anywhere else along the path would not be dealt with by 4861.
>> Yes, of course, you're right.
>>
>> But coming back to Brians problem.
>> The behavior of his router is confirm to RFC7084:
>>
>> "G-4: By default, an IPv6 CE router that has no default router(s) on
>> its WAN interface MUST NOT advertise itself as an IPv6 default
>> router on its LAN interfaces. That is, the "Router Lifetime"
>> field is set to zero in all Router Advertisement messages it
>> originates [RFC4861]."
>>
>> But this would break local connectivity if the router does not also
>> fulfill L-3
>>
>> "L-3: An IPv6 CE router MUST advertise itself as a router for the
>> delegated prefix(es) (and ULA prefix if configured to provide
>> ULA addressing) using the "Route Information Option" specified
>> in Section 2.3 of [RFC4191]. This advertisement is
>> independent of having or not having IPv6 connectivity on the
>> WAN interface."
>>
>> So far so good. But if the host doesn't honour the RIO then again local
>> connectivity is broken.
>>
>> So take a look at the reasons for this. The second paragraph of 3.2.1 says:
>>
>> "At the time of this writing, several host implementations do not
>> handle the case where they have an IPv6 address configured and no
>> IPv6 connectivity, either because the address itself has a limited
>> topological reachability (e.g., ULA) or because the IPv6 CE router is
>> not connected to the IPv6 network on its WAN interface. To support
>> host implementations that do not handle multihoming in a multi-prefix
>> environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
>> as detailed in the requirements below, advertise itself as a default
>> router on the LAN interface(s) when it does not have IPv6
>> connectivity on the WAN interface or when it is not provisioned with
>> IPv6 addresses. For local IPv6 communication, the mechanisms
>> specified in [RFC4191] are used."
>>
>> At the end, the whole behavior is because some host have problems in
>> handling situations where they have an IPv6 address configured and now
>> internet connectivity. But the solution to this requires that the host
>> is able to understand and work with RIO options, which seams to be "at
>> the time" not generally the case.
>>
>> Do we replace one evil by another?
>
> Yes, we did.
> This work was done at the time of "host IPv6 brokenness".
> Perhaps time to revisit those decisions?

Personally I think it's not worth the effort. I believe that we end up
with quite more complex home network environments in the near (ok "near"
has to be defined somehow) future.

Better let's work on those...
And in the meantime fight for correct host behaviour and (just as one
example) RIO support.

By the way: Does anyone know if (or when) Cisco will support Route
Information Options in router advertisements? :-)

BR
Holger

On 14/10/2016 21:07, Thomas Schäfer wrote:
> Am 13.10.2016 um 21:56 schrieb Brian E Carpenter:
>> On 13/10/2016 21:14, Lorenzo Colitti wrote:
>>> Of note is the fact that the ULA prefix being announced is the ubiquitous
>>> fd00::/64.
>>
>> 0 is a perfectly random number, just like the ubiquitous PIN code 1234.
>>
>> But yes, this a sloppy job by the FritzBox. Hopefully they've fixed this in
>> more recent models.
>
> It is fixed. In newer versions it is a random number and can
> additionally changed manually.

Danke schön! In general I love my FritzBox.

Brian

On 14/10/2016 23:20, Thomas Schäfer wrote:
> I was wrong. Randomly set: no, manually change possible: yes.
> The reason for my confusion was "::" versus ":"
> Sometimes reading ipv6-addresses is hard.

Yes, and in fact my box has that feature. So thanks again!

Brian

On 14/10/2016 23:32, Gert Doering wrote:
> Hi,
>
> On Fri, Oct 14, 2016 at 12:00:04PM +0200, Holger Zuleger wrote:
>> Of course the default route should *not* be withdrawn.
>> The RA default router announcement says just, "Hey hosts, I'm the way
>> out of your local subnet", and not "Hey host, I have a upstream
>> connection to the rest of the internet".
>
> If the router has no default route, it should not announce one - this
> is why PIO exists for more specific info.
>
> Imagine a setup with *two* routers. One of them has broken Internet,
> the other is working. How can the hosts decide if both keep announcing
> themselves as "I can reach anything"?

Correct. When there's only one router, it doesn't matter too much (no default
route gives a prompt fail and a broken default route turns the Internet
into a black hole). But when there are multiple exits...

I really should have figured this out without help. S***, it's exactly the
problem that https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host
is aimed at.

Brian

On 15/10/2016 00:57, Holger Zuleger wrote:
>> If the delegated prefix changes, you'll be simply postponing the local
>> communication failure, not prevent it.
> Only if the new prefix is different to the old one.
>
>> The last year has convinced me that the best user experience is
>> achieved by having an in-home stable ULA prefix to complement the
>> ISP-delegated global prefix[es] [if any], and that all the internal
>> hostnames should resolve to the IPv6 addresses assigned from the ULA
>> prefix.
> Yes, but this is probably a bit different to the AVM behavior. I have in
> mind that the default configuration on Fritzboxes is to announce the ULA
> *only* if the upstream is down.

Correct, there is an option to change that however.

Brian

> Then your local active sessions breaks
> twice.