Subject: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

From: Fernando Gont <[email-masked]>
Date: Sun, 6 Sep 2020 09:59:55 -0300

Folks,

We continue discussing each of the mitigation proposals that we had in 
draft-gont-6man-slaac-renum.

The next one is about processing PIOs at hosts, such that hosts cap the 
received values to the advertised Route Lifetime -- except when the 
Router Lifetime is set to the special value 0 ("do not use this router 
as a default router") or when the prefix lifetimes are set to the 
special value 0xffffffff ("infinity").

This allows hosts to use more appropriate lifetimes even if routers are 
employing the large default values from RFC4861.

The text is:

---- cut here ----
4.1.2.  Processing of PIO Lifetimes at Hosts

    Hosts SHOULD cap the "Preferred Lifetime" and "Valid Lifetime" of
    PIOs as follows:

    o  IF (Router Lifetime != 0) AND (Preferred Lifetime != 0xffffffff)
       AND (Valid Lifetime != 0xffffffff), then:

          Preferred Lifetime= MIN(Preferred Lifetime, "Router Lifetime")

          Valid Lifetime= MIN(Valid Lifetime, 2 * "Router Lifetime")

    RATIONALE:

       *  Capping the lifetimes in PIOs as suggested will not eliminate
          the problem discussed in this document, but will certainly
          reduce the amount of time it takes for hosts to converge to
          updated network configuration information, even when the SLAAC
          router advertises PIOs with the default values specified in
          [RFC4861] (as opposed to the new default values specified in
          Section 4.1.1) or when the corresponding router ceases to send
          RAs.

       *  A Router Lifetime of 0 has the special meaning of "this router
          is not to be employed as a default router", and may be employed
          only to advertise prefixes via SLAAC (but not as a default
          router).  As a result, PIO lifetimes are not capped when Router
          Lifetime == 0.

       *  A PIO lifetime of 0xffffffff has the special meaning of
          "infinity", which means that these prefixes (and their
          corresponding addresses) should never time out.  As a result,
          PIO lifetimes are not capped when the PIO Valid Lifetime ==
          0xffffffff or the PIO Preferred Lifetime == 0xffffffff.
---- cut here ----

The text has been slightly tweaked to reflect recent discussions.

Thoughts?

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 7 Sep 2020 12:19:03 +0900

I disagree with this change because it reduces the expressiveness of SLAAC
as a configuration protocol. It effectively turns a 32-bit field into a
16-bit field, and makes it no longer possible to have lifetimes that
outlive the default router lifetime. This often is a valid configuration.
In particular, it is a valid configuration when the IPv6 prefix is
statically allocated. This is often the case in enterprise networks, but is
also often the case in residential networks as well. My IPv6 prefix is
static, for example.

It also complicated host implementations. If you want to make this more
reliable, I think you need to tweak source address selection, not lifetimes.

On Sun, Sep 6, 2020 at 10:00 PM Fernando Gont <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 07 Sep 2020 11:43:21 +0200

>    I disagree with this change because it reduces the expressiveness
>    of SLAAC as a configuration protocol. It effectively turns a
>    32-bit field into a 16-bit field, and makes it no longer possible
>    to have lifetimes that outlive the default router lifetime. This
>    often is a valid configuration. In particular, it is a valid
>    configuration when the IPv6 prefix is statically allocated. 

I agree with Lorenzo. A network operator should be able to specify
large lifetimes if required in a particular network.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2020 10:55:37 -0400

On Sep 6, 2020, at 11:19 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> My IPv6 prefix is static, for example.

Argument by anecdote isn’t very convincing, Lorenzo.

While it’s true that in principle some situation could occur where the on-link default router goes away long enough to run out a 16-bit timer, it’s hard to imagine a situation where this would be done deliberately, and it’s equally hard to imagine a situation where it would be useful for the prefix to survive that. You have no router. Either you are communicating with a local device, in which case why not use its link-local address, or you are communicating with an off-link device, in which case you can’t reach it anymore because the router went away.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2020 10:59:28 -0400

On Sep 7, 2020, at 10:55 AM, Ted Lemon <[email-masked]> wrote:
> On Sep 6, 2020, at 11:19 PM, Lorenzo Colitti <lorenzo=[email-masked] <mailto:lorenzo=[email-masked]>> wrote:

Sorry, I realize that this is a rather incomplete thought. What I mean is that in O(0) home networks is this the case. It’s the case on your network because you are an IPv6 expert doing something weird, not because it is a configuration we have any reason to consider likely or important.

Now, it could be that you think that this _should_ be a common configuration, because you _should_ be able to set up servers that are reachable from the Internet. I even agree with you that this is how things _should_ be, although for the vast majority of Internet users it is not how things _are_. However, you still need a router in order for it to matter that your server is reachable from the Internet. So when the router goes away, the fact that your server is not reachable is because the router went down, not because the prefix expired. When the router comes back, your server will once again have its prefix, and will once again have a router, and will once again be reachable.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 07 Sep 2020 17:31:47 +0200

>    Either you are communicating with a
>    local device, in which case why not use its link-local address,

Please describe how to put a link-local address in DNS. I.e, for a host that
has multiple interface there is no way you can describe in DNS which interface
should be used for a link-local address.

Of course, you could always argue that the only hosts that use SLAAC are 
those in home situations or similar, and would never need a stable connection
to another host on the same link.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2020 11:40:45 -0400

> should be used for a link-local address.

Fair point—I’m more accustomed to using DNSSD for finding services on the local network, and it _will_ return the link-local address and indeed prefer it when communicating locally.

> to another host on the same link.

I don’t think that’s true. However, hosts communicating locally definitely shouldn’t be using a GUA. They should be using a ULA. And if the home router goes down, and stays down, then that could break local communications, but I don’t think this is really the scenario we most desperately need to plan for, since, given the prevalence of WiFi in this particular scenario, it’s unlikely that there will be a layer 2 on which to communicate when that happens.

Practically speaking, nobody who has a home network is using anything other than DNSSD+mDNS for local service discovery. There are of course exceptions, but these are Lorenzo-style exceptions. We’re working on unicast DNS solutions for DNSSD in the DNSSD working group, and for a unicast solution, it’s likely that we wouldn’t want to register a link-local address for a service, but we would definitely want to prefer a ULA, since it would survive uplink reconnects.

Bear in mind that surviving uplink reconnects that accidentally or intentionally trigger flash renumbering is the whole reason we are having this conversation.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 7 Sep 2020 16:56:30 +0100

Ted Lemon wrote on 07/09/2020 16:40:
> Bear in mind that surviving uplink reconnects that accidentally or 
> intentionally trigger flash renumbering is the whole reason we are 
> having this conversation.

Also, it seems like a slightly odd idea that a local area network 
operator would configure a dynamic address assignment system that would 
require every host on the network to reboot if they ever wanted to 
change anything, e.g. dns, refreshing NAT64 parameters, etc.  There's a 
difference between aiming towards a stable network configuration and 
aiming towards a network configuration where it's a thundering headache 
to change anything on.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Sep 2020 15:44:03 -0300

Hi, Lorenzo,

On 7/9/20 00:19, Lorenzo Colitti wrote:
> I disagree with this change because it reduces the expressiveness of 
> SLAAC as a configuration protocol. It effectively turns a 32-bit field 
> into a 16-bit field, and makes it no longer possible to have lifetimes 
> that outlive the default router lifetime.

This seems incorrect. The proposed change does allow (and honors) 
prefixes that employ the special value 0xffffffff that means "infinity". 
So you *can* have prefixes that outlive the default router lifetime.

That said, modulo special cases, I wonder what's the use of having a 
prefix if you don't have an associated router -- that's why we have a 
scoped address architecture, after all.

And regarding expressiveness, let's do some math:
If you employ the largest possible RA value, you get a lifetime of 18 
hours. That means that you have 18 hours for the local router to send an 
unsolicited RA, or for hosts to poll the router if they don't get one. 
That seems more than reasonable.

An, as noted, you can always set the prefix lifetime to 0xffffffff.

> This often is a valid 
> configuration. In particular, it is a valid configuration when the IPv6 
> prefix is statically allocated.

In such case, if the prefix is static, you'd probably want to set the 
lifetime to 0xffffffff ("infinity", what probably describes the "static" 
nature best).

> This is often the case in enterprise 
> networks, but is also often the case in residential networks as well. My 
> IPv6 prefix is static, for example.

In a residential network, if the router can't refresh the associated 
timers, that will usually mean that the router is dead. At which point 
the user will likely reset the router, your link state will go down, and 
many implementations will remove any configured addresses. (assuming the 
most usual residential deployment scenario).

In scenarios where the user knows better (like yours), and for some 
reason the user employs RAs to configure addresses while aware that the 
prefixes are static, the user can always set the prefix lifetime to 
0xffffffff (infinity), so the prefixes lifetimes won't be capped.

> It also complicated host implementations.

I did at least three implementations of this, and, in the context of 
SLAAC, the complexity of this seem O(0) -- as Ted would say. :-)

> If you want to make this more 

I think that source address selection (SAS) would be the wrong place to 
deal with this. My rationale:

This is all about keeping fresh/valid SLAAC information -- hence the 
problem belongs to SLAAC (principle of "clean up your own mess").

SLAAC is employed for automatic configuration. As such, I would expect 
that, from a configuration point of view, slaac is able to keep fresh 
information.

OTOH, given a set of configured addresses, there's a need to pick the 
most appropriate one to source packets to a given destination. That's 
SAS' job. -- SAS assumes that the list of "candidate" source addresses 
is valid.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Sep 2020 15:47:47 -0300

> should be used for a link-local address.

Indeed, ULAs would be a better option for that.

That aside, you can set the prefix lifetime to 0xffffffff (infinity) if 
you wish.

> to another host on the same link.

For the most typical home scenario, if the router is alive, the prefix 
lifetime will be refreshed. If the router is dead, packets won't be 
routed/switched anyway.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Sep 2020 16:21:26 -0300

> aiming towards a network configuration where it's a thundering headache 

+1.

Indeed, at home I had to manually override the PIO lifetimes in my CPE 
to deal with this problem. I'm currently using:

  Prefix                   : XXXXX::/64
   On-link                 :          Yes
   Autonomous address conf.:          Yes
   Valid time              :         1800 (0x00000708) seconds
   Pref. time              :          900 (0x00000384) seconds

(same as the Router Lifetime) and would most likely reduce those further.

I have experienced the flash-renumbering scenario myself (my ISP is 
trying to find why), and given the current default PIO lifetimes, 
there's not much of an option other than resetting everything -- which 
is *very* annoying.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Sep 2020 12:20:50 +0900

On Mon, Sep 7, 2020 at 11:59 PM Ted Lemon <[email-masked]> wrote:

> On Sep 6, 2020, at 11:19 PM, Lorenzo Colitti <
> lorenzo=[email-masked]> wrote:
>
> This is not argument by anecdote. Static prefixes and global addresses are
a common use case. My point was that they are not only common in enterprise
networks, they are also relatively common at home.

Sorry, I realize that this is a rather incomplete thought. What I mean is
> that in O(0) home networks is this the case. It’s the case on your network
> because you are an IPv6 expert doing something weird, not because it is a
> configuration we have any reason to consider likely or important.
>

No, this is not me doing something weird. The incumbent FTTH network in
Japan works this way. The middle bits of the IPv6 prefix are statically
assigned to the physical link. This is a real use case.

> Now, it could be that you think that this _should_ be a common
> configuration, because you _should_ be able to set up servers that are
> reachable from the Internet. I even agree with you that this is how things
> _should_ be, although for the vast majority of Internet users it is not how
> things _are_. However, you still need a router in order for it to matter
> that your server is reachable from the Internet. So when the router goes
> away, the fact that your server is not reachable is because the router went
> down, not because the prefix expired. When the router comes back, your
> server will once again have its prefix, and will once again have a router,
> and will once again be reachable.
>

I do in fact have servers that are reachable from the Internet. And they
have AAAA records with global addresses in them. Why can't I use that AAAA
record from everywhere? That's whole point of global addresses: they work
everywhere. And for me, another advantage the global address is that it
will *never* change unless I move. This is *better* than ULA, which will
change if/when I swap or factory reset my router.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2020 23:48:34 -0400

You should use the GUA when it is the narrowest scope. You should use the ULA when it is reachable. Nobody memorizes ipv6 addresses. Why do you care if they change over time?

As for this Japanese isp, what provision do they make for advertising services off the home network?

> On Sep 7, 2020, at 23:21, Lorenzo Colitti <[email-masked]> wrote:
> 
> 
>> This is not argument by anecdote. Static prefixes and global addresses are a common use case. My point was that they are not only common in enterprise networks, they are also relatively common at home.
>> 
> No, this is not me doing something weird. The incumbent FTTH network in Japan works this way. The middle bits of the IPv6 prefix are statically assigned to the physical link. This is a real use case.
>  
> I do in fact have servers that are reachable from the Internet. And they have AAAA records with global addresses in them. Why can't I use that AAAA record from everywhere? That's whole point of global addresses: they work everywhere. And for me, another advantage the global address is that it will *never* change unless I move. This is *better* than ULA, which will change if/when I swap or factory reset my router.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 00:53:47 -0300

On 8/9/20 00:20, Lorenzo Colitti wrote:
> On Mon, Sep 7, 2020 at 11:59 PM Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>     On Sep 6, 2020, at 11:19 PM, Lorenzo Colitti
>>     <lorenzo=[email-masked]
>>     <mailto:lorenzo=[email-masked]>> wrote:
> This is not argument by anecdote. Static prefixes and global addresses 
> are a common use case. My point was that they are not only common in 
> enterprise networks, they are also relatively common at home.

FWIW, the reasons why we do honor VL/PL == 0xffffffff is exactly "static 
prefixes".

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Sep 2020 13:03:24 +0900

The server is reachable via its AAAA record. If I replace my router the ULA
will change and I will need to change the AAAA record. Given that the
prefix is static that's an additional burden.

As for what the ISP is trying to do, it doesn't matter: my point was just
that this is just an example of a real configuration which will be made
worse by changing the semantics of PIO lifetimes.

On Tue, Sep 8, 2020 at 12:48 PM Ted Lemon <[email-masked]> wrote:

> You should use the GUA when it is the narrowest scope. You should use the
> ULA when it is reachable. Nobody memorizes ipv6 addresses. Why do you care
> if they change over time?
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Sep 2020 13:05:23 +0900

> FWIW, the reasons why we do honor VL/PL == 0xffffffff is exactly "static

I don't think I've ever seen a non-3GPP network that sent a PIO with a
lifetime of 0xffffffff. This is because lifetimes are configured by humans,
and nobody would explicitly configure a lifetime of 136 years.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Sep 2020 00:16:13 -0400

Why wouldn’t you use DNSSD on your local network? Why would you publish your ULA address globally?

And specifically hope does the user of the Japanese ISP you mentioned lose? What’s the use case that breaks?

> On Sep 8, 2020, at 00:03, Lorenzo Colitti <[email-masked]> wrote:
> 
> 
> The server is reachable via its AAAA record. If I replace my router the ULA will change and I will need to change the AAAA record. Given that the prefix is static that's an additional burden.
> 
> As for what the ISP is trying to do, it doesn't matter: my point was just that this is just an example of a real configuration which will be made worse by changing the semantics of PIO lifetimes.
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 01:17:38 -0300

On 8/9/20 01:03, Lorenzo Colitti wrote:
> The server is reachable via its AAAA record. If I replace my router the 
> ULA will change and I will need to change the AAAA record. Given that 
> the prefix is static that's an additional burden.
> 
> As for what the ISP is trying to do, it doesn't matter: my point was 
> just that this is just an example of a real configuration which will be 
> made worse by changing the semantics of PIO lifetimes.

Are you arguing that during a "Router Lifetime" period your systems will 
not receive an RA? -- for example, in a period of 30'-45' they would 
fail to receive an RA?  In such case, how would they deal with a missing 
default router?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 01:22:10 -0300

On 8/9/20 01:05, Lorenzo Colitti wrote:
> On Tue, Sep 8, 2020 at 1:02 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> lifetime of 0xffffffff.

The ISP shipping the ISP can certainly set the PL/VL to 0xffffffff if 
they know prefixes are stable, and they don't expect to change that fact 
-- although, in general, I believe it's a bad choice.

> This is because lifetimes are configured by 
> humans, and nobody would explicitly configure a lifetime of 136 years.

 From a practical perspective, there's not much of a difference between 
7 days/30 days and 136 years, unless you could convince me that you'd 
sit in front of your computer for 7 days/30 days doing nothing, until 
the stale prefixes go away and your IPv6 connections becomes usable....

Regards,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Sep 2020 15:33:11 +0900

> your ULA address globally?

I don't use ULA. Why should I? I have global space. When my network is up,
I can reach it. When my network is down, I can reach it from inside my
network. ULA can't do any better than that.

> lose? What’s the use case that breaks?

The above stops working if there is an outage that is longer than the
router lifetime.

---

From: [email-masked]
Date: Tue, 8 Sep 2020 09:06:25 +0200

This working group is standardizing IPv6 for a wide set of networks and use cases.
Please keep that in mind also in this thread.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 04:28:25 -0300

On 8/9/20 03:33, Lorenzo Colitti wrote:
> On Tue, Sep 8, 2020 at 1:16 PM Ted Lemon <[email-masked] 
> I don't use ULA. Why should I? I have global space. When my network is 
> up, I can reach it. When my network is down, I can reach it from inside 
> my network. ULA can't do any better than that.

Just set the lifetime to 0xffffffff (infinity). That's the *only* 
setting that will guarantee that things continue working no-matter how 
long the outage lasts (including "forever").

If you use the current default lifetimes, then things will stop working 
at most after 30 days after a continued outage. If they don't, then 
you're overriding the default lifetimes -- at which point one would 
wonder why, if you're aware you have a stable prefix, and want the 
prefix to stay even if your router dies, you're not using 0xffffffff in 
the first place.

>     And specifically hope does the user of the Japanese ISP you
>     mentioned lose? What’s the use case that breaks?
> 
> 

That's assuming you have stacked switches or the like. Otherwise, most 
likely you wouldn't have layer-2, either.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Sep 2020 16:52:05 +0900

> prefix to stay even if your router dies, you're not using 0xffffffff in

I'm not worried about outages lasting more than 30 days. Realistically, I
doubt that anyone is. They don't happen in practice.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 05:20:30 -0300

On 8/9/20 04:52, Lorenzo Colitti wrote:
> On Tue, Sep 8, 2020 at 4:35 PM Fernando Gont <[email-masked] 
> I'm not worried about outages lasting more than 30 days. Realistically, 
> I doubt that anyone is. They don't happen in practice.

They may not happen in the specific place you're looking at. -- that's 
quite different from "they don't happen".

Besides, you're referring to a specific case where you get stable 
prefixes from your ISP, you have stacked switches, *and* you somehow 
know or can enforce the length of outages. -- that's far from being a 
generic case. And even then, a prefix lifetime of 0xffffffff would get 
you what you want.

Furthermore, implementations (e.g. radvd(8)) normally override the 
default prefix lifetimes to values in the order of a day, or smaller. In 
which case, if you really want prefixes to last that long, you need to 
make sure to manually override whatever is the default (i.e., you can't 
rely on routers using what's specified as the default).

In which case, so far I don't see any drawback of employing 0xffffffff 
for the lifetimes --- other than "I want to use '30 days' because I want 
to use '30 days'".

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Sep 2020 18:01:45 +0900

> for the lifetimes --- other than "I want to use '30 days' because I want

Using 0xffffffff doesn't allow you to reflect the actual lifetime of
anything that's longer than 30 days - for example, a 6-month or 1-year
contract.

In any case - we shouldn't be restricting the protocol to fix configuration
errors or operational problems that can be fixed in other ways. This is a
32-bit field, and there are valid use cases for numbers that are greater
than 65536 seconds, and there may be valid cases that we have not yet
thought of. We should not be constraining the maximum value of the field
just because some routers cause operational issues by setting it to values
that can result in outages. If we want to solve that problem, then we need
operational guidance (or even standards text) that says, "if the router is
subject to loss of state it SHOULD ensure that it never announces a PIO of
lifetime greater than the Router Lifetime". We should *not* change the
standards to force hosts to ignore values that have valid use cases.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 08 Sep 2020 12:31:48 +0200

>aiming towards a network configuration where it's a thundering headache 

I think the proposed feature is a bad trade-off. The proposal constrains
admins on networks that have static prefixes and use SLAAC. 

On the other hand, as a solution for flash renumbering, it doesn't really do
much. With this proposal, after a flash renumbering event it would
take around 30 minutes before the prefix is deprecated.

For flash renumbering we need something that reacts a lot quicker. Once we
have that, this feature is no longer needed.

There is a quite a lot of push to use SLAAC everywhere, not just in
peoples homes but also on corporate LANs. So this proposal affects a very
diverse set of networks.

There is the exception for infinite lifetime. I'm a bit worried about that.
For example, what this proposal tries to fix is home routers advertising
lifetimes of many days. If instead home routers would have announced
infinite lifetimes, this proposal would not have worked.

So I'm a bit worried about forcing wide spread use of infinite lifetimes even
if people actually want a few days or a week.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 08:24:31 -0300

Hi, Philip,

> have that, this feature is no longer needed.

FWIW, this particular bit helps mitigate the case where the router that 
originally announced the prefix just vanishes (or at least that what it 
looks like from the point of view of the host). It is not mean to be a 
replacement to any other mitigation, but to complement it.

> infinite lifetimes, this proposal would not have worked.

While we frequently end up talking about home routers, this is indeed a 
general problem. And the mitigations are not meant to fix any specific 
scenario -- but to be of help in all of them.

> if people actually want a few days or a week.

The reason for which RAs are periodically sent is so that if they are 
not, associated timers expire in a meaningful timeframe.

Wanting a prefix to be valid does not need to mean that you sign a 
contract for the whole lifetime, but rather that you keep refreshing the 
lifetime for long enough such that the effective lifetime is the 
intended one.

We currently have timers that never go off in any meaningful time frame. 
*That* is, IMO, an unnecessary increase in the complexity of the 
resulting code, for no value. I'm finding a hard thinking of a protocol 
that has timers that never go of in any meaningful timeframe.

Regards,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 08 Sep 2020 14:57:30 +0200

>replacement to any other mitigation, but to complement it.

This implies that there are at least two routers. If you have two routers
that advertise different prefixes and one of them is down, then you are
in the general area of multi-homed networks. That can easily be solved
by using the prefix for which the router is reachable. No need to play
with timers.

Also in this case, it takes 30 minutes for anything to happen. That just
not a reasonable timeframe.

>not, associated timers expire in a meaningful timeframe.

A router advertisement in the classical sense, advertises that the router
is alive. Obviously, a router that is alive can periodically announce
that fact.

However, what we have done with SLAAC is to tie address allocation on
a subnet to routers. Which was not a big problem because you can have
multiple nodes advertise a SLAAC prefix (even if those nodes are not
default routers).

This gets more complex when we tie SLAAC prefix to routers because of multiple
homing.

And this proposal ties lifetime of addresses to routers. But fundamentally
addresses have nothing to do with routers. It is one convenient option
to have routers advertise SLAAC prefixes, but we should see it as just
that, a convenience.

If a router goes down, the addresses can just continue to exists. There no
reason to force somebody to use link-local or ULAs if they have a static
prefix.

>lifetime for long enough such that the effective lifetime is the 

There is no reason to tie local communication on a link to whether a 
router is alive or not. There is also no reason to force local communication
of a link to use only link-local addresses. Only on small home networks is
the router also the switch and wifi access point.

>that has timers that never go of in any meaningful timeframe.

I think this issue is already addressed in v6ops. The fact that a default
invented a couple of decades ago are now less useful in a home situation
does mean that each and every host on the internet has to limit lifetimes
of addresses.

You complain about timers going off in a meaningful time. In many contexts,
a grace period of one month is perfectly normal. It is quite possible that
if someone wants to renumber a network in a controlled fashion, that the
complete event would take multiple months.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Sep 2020 09:27:46 -0400

On Sep 8, 2020, at 8:57 AM, Philip Homburg <[email-masked]> wrote:
> That can easily be solved

How do you know that the router is reachable? Is that not also informed by timers? Suppose the router rebooted and got flash renumbered. Did its link-local address change?

> reason to force somebody to use link-local or ULAs if they have a static

If the router has flash renumbered, then when it goes down and comes back, and you continue to have an ancient GUA configured on the interface to that link, you will use that GUA as a source address, and replies will not come back to you. You will experience weird half-function: the network will work or not depending on the vagaries of source address selection between equivalently scoped addresses, which may or may not be deterministic.

> the router also the switch and wifi access point.

This is a reason to use link-local addresses for communications on a local link.

Honestly, this discussion reminds me of my attitude toward DHCP when I worked at DEC in ~1997. I thought DHCP was a bad idea, because leases were bad: leases would result in loss of connectivity when the DHCP server went down, or something else went wrong. How would my telnet connections survive over time? Would my X windows not die randomly? We actually used BOOTP at the time to assign addresses. It was absolutely clear to me that DHCP was a bad idea that would ultimately die, or else we would just all use infinite leases, to get the benefits of DHCP without the disadvantages.

Of course we all know how that turned out. DHCP became the default for any device that isn’t in a data center, and now even devices in data centers are often configured with DHCP. In practice, leases are not a problem. Leases solve a lot of problems. Yes, stale network data isn’t cleaned up as quickly as we might wish, but leases do really help with garbage collection.

And then we see this:

> The fact that a default

This is basically recapitulating my attitude about DHCP back when I was working at DEC, perhaps not coincidentally a “couple of decades" ago.

In reality, a functioning network has to have a router. The router has to be advertising a PIO. If the router dies and is down for an extended period, the network stops working. This is because devices join and leave the network: if the network is not providing PIOs, then devices that join will not be able to communicate with devices that are already present.

The fact that you can maybe reach your printer when the PIOs are not coming, because you happened to be connected, and your printer happened to be connected, when PIOs were present, is not evidence that the network is working. 

If you can reach your IoT devices, it is because the network is working in the constrained way that it needs to for your IoT devices to work, and those devices _had better_ work when there is no global prefix being advertised. In practice, you most likely have an IoT router, because your IoT devices are on a constrained network, not on WiFi. That router had better be providing a prefix to use for communications on the WiFi network; if it is not, your lights and switches will neither be reachable nor controllable.

Disconnected working is completely orthogonal to connected working, or should be. Networks are not some platonic ideal. We all know that. Sure, if you have servers on your network and a static prefix, you want your server(s) to have the same address whenever there is a route to the Internet. SLAAC won’t get you that. Whether your server has and is able to use that address when the edge router is down is simply not connected to whether your home network functions when the edge router is down.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 10:43:15 -0300

> by using the prefix for which the router is reachable. No need to play

How would existing timers invalidate the prefix?

> not a reasonable timeframe.

As noted, this is not a replacement for other things. But does to 
deprecation and garbage collection (invalidation) in the short term. -- 
better to get rid of stale prefixes in 30 minutes, than in 30 days, so 
to speak.

> addresses have nothing to do with routers. 

RFC8028 seems to argue otherwise. Quite the contrary, actually.

> It is one convenient option
> If a router goes down, the addresses can just continue to exists.

An address is a topologically-dependent identifier. What would be the 
topological significance of an address when there's no router?

> router is alive or not.

Communication on a link implies link-local. Otherwise, by using an 
address while not being part of the topology you are claiming something 
else.

> does mean that each and every host on the internet has to limit lifetimes

I'm not sure why you insist in the home network scenario. I belive the 
same holds true for every scenario, not just home networks.

> complete event would take multiple months.

Well, with the current timers, you're probably doomed to that.

I personally think that a network configuration that *requires* months 
to renumber (we're talking about automatic mechanisms here, not 
configuration files or the like) is pretty broken.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 08 Sep 2020 16:15:47 +0200

>    That can easily be solved by using the prefix for which the
>    router is reachable. No need to play with timers.
> 
>    How do you know that the router is reachable? Is that not also
>    informed by timers? Suppose the router rebooted and got flash
>    renumbered. Did its link-local address change?

Typically you know that a router is reachable if it is reachable according
to the neighbor cache. Now I think the neighbor cache needs some work, but
bassically, if you try to use a router you verify that it is reachable
every 30 seconds.

This deals with the case that a router gets replaced with another
router. 

So if you have a prefix from a router that is now down, then NUD will
tell you that the router is down, and a host can avoid using that prefix.

>      If a router goes down, the addresses can just continue to
>      exists.  There no reason to force somebody to use link-local
>      or ULAs if they have a static prefix.
> 
>    If the router has flash renumbered, then when it goes down and
>    comes back, and you continue to have an ancient GUA configured
>    on the interface to that link, you will use that GUA as a source
>    address, and replies will not come back to you. You will experience
>    weird half-function: the network will work or not depending on
>    the vagaries of source address selection between equivalently
>    scoped addresses, which may or may not be deterministic.

In the current proposal that will happen for 30 minutes anyhow. I don't
see how people are going to wait that long.

So we need something else. Once we have a better solution, this change is
no longer needed.

>      There is no reason to tie local communication on a link to
>      whether a router is alive or not. There is also no reason to
>      force local communication of a link to use only link-local
>      addresses. Only on small home networks is the router also the
>      switch and wifi access point.
> 

Link local addresses are completely horrible. Apart from a few IPv6
experts, nobody understands them. They don't work like other addresses.

Only in relatively closed systems like mDNS, you can expect link-local
to work. And even them, most people are likely to fail if they have to
troubleshoot something.

Link-local address are slight better than the old site-local addresses, but
not much.

Basically if you want local address use a ULA.

>    Honestly, this discussion reminds me of my attitude toward DHCP
>    when I worked at DEC in ~1997. I thought DHCP was a bad idea,
>    because leases were bad: leases would result in loss of connectivity
>    when the DHCP server went down, or something else went wrong.
>    How would my telnet connections survive over time? Would my X
>    windows not die randomly? We actually used BOOTP at the time to
>    assign addresses. It was absolutely clear to me that DHCP was
>    a bad idea that would ultimately die, or else we would just all
>    use infinite leases, to get the benefits of DHCP without the
>    disadvantages.

I grew up with RARP. So DHCP was just needless complexity that somehow got
popular :-)

In any case, DHCP has been a source of a lot of problems. Very often a
network fails because the DHCP server is down or unreachable. Or out
of leases.

But the main thing here, it is upto the network operator to deploy DHCP
and set the lease times. There is nothing that hosts do other than
the follow what they get from DHCP.

This proposal requires that hosts ignore what the network operator wants to
do.

The key thing is that the network operator can decide how to run the network
best, with DHCP (and appropriate lease times) or static configuration.

>    In reality, a functioning network has to have a router. The
>    router has to be advertising a PIO. If the router dies and is
>    down for an extended period, the network stops working. This is
>    because devices join and leave the network: if the network is
>    not providing PIOs, then devices that join will not be able to
>    communicate with devices that are already present.

Yes, that is indeed an issue. However, it doesn't strike me as a good
reason to distrupt communications just because a new device may be unable
to join a network.

>    Disconnected working is completely orthogonal to connected
>    working, or should be. Networks are not some platonic ideal. We
>    all know that.  Sure, if you have servers on your network and
>    a static prefix, you want your server(s) to have the same address
>    whenever there is a route to the Internet. SLAAC won't get you
>    that. Whether your server has and is able to use that address
>    when the edge router is down is simply not connected to whether
>    your home network functions when the edge router is down.

With the current defaults, the server will have the public address if the
router was up anytime in the last 30 days and the server is not rebooted
after the router went down.

Some DHCP clients actually write the DHCP lease to disk and continue using
the lease after a reboot. There is no reason a SLAAC implementation 
couldn't do the same.

If that would be common, any device can just reboot when the router is down
and connectivity local to the link remains.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Sep 2020 11:48:14 -0300

On 8/9/20 11:15, Philip Homburg wrote:
> to the neighbor cache. 

The neighbor cache doesn't cause prefixes to be deprecated or 
invalidated, as far as I remember.

> Now I think the neighbor cache needs some work, but

So, that's not the current state now.

That said, it would be quite tricky to link NUD with Source Address 
Detection.

> So we need something else. Once we have a better solution, this change is

Typically, you can improve the situation where *the same* router 
renumbers. e.g. an RA missing a PIO triggers some sort of probe packet, 
and then eventually you refresh/check the missing PIO, or you don't.

When it comes to routers that simply vanish, even if you got into 
gratituous probing of all available routers, I don't think you'd 
eliminate them sooner that Router Lifetime....

> experts, nobody understands them. They don't work like other addresses.

You don't need link-locals specifically. You also have ULAs. That's why 
we have a scoped address architecture.

> Basically if you want local address use a ULA.

Agreed.

> network fails because the DHCP server is down or unreachable. Or out

So would SLAAC if SLAAC routers fail.

And yes, DHCP may run out of leases -- if improperly configured, or if 
you indeed have a small pool of addresses.

But then we also have people complain that nodes use to many addresses...

> the follow what they get from DHCP.

Hosts are not forced to use a lease for the whole lifetime without e.g. 
trying to renew way before the lease expires.

Similarly, the lifetimes in an RA are an upper lifetime, not a forceful 
requirement to use the addresses for that time period without 
double-checking that things are still okay.

> This proposal requires that hosts ignore what the network operator wants to

This is not DHCP, but SLAAC. Hosts receive information from the network, 
and within limits, they can do what they please.

I'm not sure how you think setting the PIO lifetimes in a way that you 
will double-check that the PIO is still valid during the whole ROuter 
Lifetime could be "ignoring what the operator wants to".

> reason to distrupt communications just because a new device may be unable

I go back to my original question: If you are not connected to the 
network, how could you possibly claim where you belong in the network 
topology?

> the lease after a reboot. There is no reason a SLAAC implementation

Most DHCP implementations don't do RECONFIGURE, either. So what?

> and connectivity local to the link remains.

This seems like very broken behavior to me. In fact, implementations 
seem to be heading in exactly the opposite direction: like getting rid 
addresses on a link-down event.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Sep 2020 11:34:45 -0400

> tell you that the router is down, and a host can avoid using that prefix.

You missed my last question. What if the router is _reachable_, but has forgotten its old prefix because it was just rebooted?

> see how people are going to wait that long.

They aren’t. Router reachability will address some problems. Happy eyeballs will address others. But as long as that stale prefix is present, the network is going to be rickety. Getting rid of it in 30 minutes is better than getting rid of it in 30 days.

> experts, nobody understands them. They don't work like other addresses.

They work like link-scoped multicast addresses! :)

> to work. And even them, most people are likely to fail if they have to

mDNS is a first-class name service on every operating system out there except Linux. On Linux you have to install either Apple’s open source mDNSResponder code or avahi-daemon. I’m doing development on a Raspberry Pi right now. To ssh to it, I type “ssh tau.local”. I don’t type in an IPv6 address. So if all that’s available is a link-local address, it’ll Just Work.

> Basically if you want local address use a ULA.

No argument here—it was Lorenzo who complained about ULAs.

> network fails because the DHCP server is down or unreachable. Or out

Out of leases used to happen a fair amount when you used e.g. a cheap access point in a large meeting room. But that’s not an issue for SLAAC.

> reason to distrupt communications just because a new device may be unable

Right, that was my argument for not liking DHCP, too. But what I actually found, and what convinced me, was that actually _not_ using leases made things _worse_, not _better_. This was in the days of IP address scarcity, which isn’t an issue with IPv6, but the principle is the same: if you clean up garbage, things work better.  If the prefix is still valid and usable, you should be seeing PIOs advertising it. If you aren’t seeing them, it’s garbage.

> the lease after a reboot. There is no reason a SLAAC implementation 

When is doing this going to make a difference in your life?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Sep 2020 11:13:55 +1200

On 09-Sep-20 02:15, Philip Homburg wrote:
...>>      There is no reason to tie local communication on a link to
> experts, nobody understands them. 

I think that's an unreasonable generalisation. What might be widely
misunderstood is the term "link". Once you have that straight,
"link-local" is self-defining.

> They don't work like other addresses.

They aren't meant to (see below). But I don't see what's hard to
understand.
 
> Basically if you want local address use a ULA.

Yes, if you want an address space that extends across a limited
domain containing at least one router. But link-local was invented
as an equivalent of what several other networks could do in 1994
that IP couldn't do: configure itself automatically on a piece of
wire that had no connection to the outside world (i.e. no router
whatever, and no such thing as a DHCP server). That still works
nicely.

> the follow what they get from DHCP.

DHCPv6 is not a required feature of an IPv6 network.

> This proposal requires that hosts ignore what the network operator wants to

Yes. Hosts should defend themselves first, because they may (and often do) move
between operators of varying quality.

> best, with DHCP (and appropriate lease times) or static configuration.

Or with neither of those things, which is where SLAAC and RAs take over.

>>    In reality, a functioning network has to have a router. 

Actually not, unless access to the outside world is required.

>>   The

It can always join with a link-local address. Whether it can find its
peers' link-local addresses is another matter, of course. That's where
a link-local aware solution comes in.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 09 Sep 2020 12:28:34 +0200

> You missed my last question. What if the router is _reachable_,
> but has forgotten its old prefix because it was just rebooted?

30 minutes is not an acceptable time scale to recover from this event.
So we need something else. Once that is in place, we no long need this feature.

> They arent. Router reachability will address some problems. Happy
> eyeballs will address others. But as long as that stale prefix is
> present, the network is going to be rickety. Getting rid of it in
> 30 minutes is better than getting rid of it in 30 days.

Yes, 30 minutes is better than 30 days, but we need to do better than
30 minutes. 

> mDNS is a first-class name service on every operating system out
> there except Linux. On Linux you have to install either Apples open
> source mDNSResponder code or avahi-daemon. Im doing development on
> a Raspberry Pi right now. To ssh to it, I type ssh tau.local. I
> dont type in an IPv6 address. So if all thats available is a
> link-local address, itll Just Work.

'every operating system'. This is just not true. Unless you are willing to 
ignore a lot of software.

Maybe you like mDNS, fine. Maybe other people want to be able to refer to a
service even if it is on a different subnet.

Note that SLAAC is also used in companies, etc. This change affects a lot more
than just home networks.

> No argument hereit was Lorenzo who complained about ULAs.

I said 'if you want a local address'. I think Lorenzo didn't want to use a 
local address. On my home I also use global addresses exclusively.

> Right, that was my argument for not liking DHCP, too. But what I
> actually found, and what convinced me, was that actually _not_
> using leases made things _worse_, not _better_. This was in the
> days of IP address scarcity, which isnt an issue with IPv6, but
> the principle is the same: if you clean up garbage, things work
> better.  If the prefix is still valid and usable, you should be
> seeing PIOs advertising it. If you arent seeing them, its garbage.

My exerience is that static address allocation works a lot better for
devices that are permanently or regularly present. 

By now most people have learned to live with the fact that devices regularly
get different IP addresses. That doesn't mean it is a good idea.

Indeed if you don't have enough IPv4 address then cleaning up may become an
issue.

In any case, SLAAC already provides hosts with dynamic configuration. What we
talking about it making it impossible for the network operator to see 
lifetimes of addresses as he or she sees fit.

Or, if we see a host as an end user device, having the host work against the
user when the router goes down, but not really helping the user during a 
flash renumber event because it still takes 30 minutes for the old prefix
to be deprecated. Rebooting is quicker.

> When is doing this going to make a difference in your life?

There is a common complaint of things not working when an internet
connection is broken. We should make things better when that happens instead
of making it worse.

Note that any network admin can still set the lifetimes in RAs to a low 
value. We are doing making a change to all IPv6 hosts in the world just
because there are some CPEs that use overly long lifetimes.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 09 Sep 2020 14:30:37 +0200

>They aren't meant to (see below). But I don't see what's hard to

We can try a small quiz.

1) You notice a problem reaching address fe80::42, as a quick check you
   try to ping this address:

   ping fe80::42

   Why does this fail? how to correct the ping command?

2) Your collegue tried to put a link-local address in DNS and asks for help.
   The following line was added:

   testhost IN AAAA fe80::42

   Why does this fail. How to correct this?

3) A C programmer uses inet_ntop to convert an IPv6 to a printable string 
   for logging purposes. Why is this the wrong approach for link-local
   addresses. How to do this correctly? What can still go wrong?

Bonus question:

4) A host at address fe80::42 is running a web server for configuration. 
   How you do reach this host using a web browser?

I think there is only a small fraction of technical people who can answer
one of these questions, and almost none can answer all 4.
If we replace the link-local address which a GUA, then most of these questions
become trivial.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Sep 2020 09:07:49 -0400

>   Why does this fail? how to correct the ping command?

You didn’t specify which interface to use. Personally I think the stack should just handle this unless the same address is visible on more than one link, but be that as it may, how did you get that IP address and why wasn’t it printed correctly? ifconfig on the mac prints the correct address:

	inet6 fe80::10b4:b622:6db:e59d%en0 prefixlen 64 secured scopeid 0x9 

On linux, the wrong address is printed:

        inet6 fe80::4dcc:a04a:df5a:6aba  prefixlen 64  scopeid 0x20<link>

This is a bug in ifconfig—it’s not printing the address correctly (perhaps for a reason you allude to in a later question).

If you didn’t get the address from ifconfig, how did you get it? Why didn’t you get a name? What sort of end user are we talking about here? If they are reading a log, they are not a typical end user. If this was presented in a UI, the UI is wrong.

>   Why does this fail. How to correct this?

This is invalid. You can’t put link-local addresses in DNS, as we’ve already discussed. You should use mDNS for this, because mDNS returns the correct interface information.

>   addresses. How to do this correctly? What can still go wrong?

Arguably inet_ntop is broken if it doesn’t include the scope id.

>   How you do reach this host using a web browser?

webserver.local

Why on earth would you ever copy an IPv6 address into the URL bar? How many users know how to do _that_ correctly?

I’m not being facetious here. If you have a device that does this, it is nearly 100% likely that it is advertising the service using mDNS. The only exception I can think of is OpenWRT.

If the device is advertising using mDNS, then the service can be browsed—if you aren’t sure what service it is, go look for it.  E.g.:

tau% dns-sd -B _http._tcp
Browsing for _http._tcp
DATE: ---Wed 09 Sep 2020---
13:56:37.764  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
13:56:37.941  Add        2   2 local.               _http._tcp.          Brother HL-L2370DW series
^C
tau% 

or

tau% avahi-browse --resolve _http._tcp
+   eth0 IPv6 Brother HL-L2370DW series                     Web Site             local
+   eth0 IPv4 Brother HL-L2370DW series                     Web Site             local
=   eth0 IPv4 Brother HL-L2370DW series                     Web Site             local
   hostname = [BRN3C2AF45FEC2F.local]
   address = [192.168.4.57]
   port = [80]
   txt = []
=   eth0 IPv6 Brother HL-L2370DW series                     Web Site             local
   hostname = [BRN3C2AF45FEC2F.local]
   address = [192.168.4.57]
   port = [80]
   txt = []

Looks like a bug above in avahi-browse—it’s looking up the IPv6 address but then printing the IPv4 address.

tau% dns-sd -Q BRN3C2AF45FEC2F.local aaaa
DATE: ---Wed 09 Sep 2020---
14:01:19.404  ...STARTING...
Timestamp     A/R Flags if Name                          Type  Class   Rdata
14:01:19.404  Add     2  2 BRN3C2AF45FEC2F.local.        AAAA   IN     FE80:0000:0000:0000:3E2A:F4FF:FE5F:EC2F
^C
tau% 

Notice that mDNS is in fact advertising a link-local address, and that pinging it works on the Mac:

mithrandir% ping6 BRN3C2AF45FEC2F.local.
PING6(56=40+8+8 bytes) fe80::10b4:b622:6db:e59d%en0 --> fe80::3e2a:f4ff:fe5f:ec2f%en0
16 bytes from fe80::3e2a:f4ff:fe5f:ec2f%en0, icmp_seq=0 hlim=64 time=4.979 ms
16 bytes from fe80::3e2a:f4ff:fe5f:ec2f%en0, icmp_seq=1 hlim=64 time=4.620 ms
^C
--- brn3c2af45fec2f.local ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 4.620/4.800/4.979/0.179 ms
mithrandir% 

Notice that the address scope ID is present and correct (the if column above):

tau% ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:b3:17:00 brd ff:ff:ff:ff:ff:ff

Unfortunately ping6 on linux appears not to work:

tau% ping6 BRN3C2AF45FEC2F.local.
ping: BRN3C2AF45FEC2F.local.: Name or service not known

It does work for IPv4, which indicates that the issue is that for some reason the resolver setup for ping6 is using the wrong API or using the right API incorrectly:

tau% ping BRN3C2AF45FEC2F.local.
PING BRN3C2AF45FEC2F.local. (192.168.4.57) 56(84) bytes of data.
64 bytes from 192.168.4.57 (192.168.4.57): icmp_seq=1 ttl=255 time=1.50 ms
64 bytes from 192.168.4.57 (192.168.4.57): icmp_seq=2 ttl=255 time=1.14 ms
64 bytes from 192.168.4.57 (192.168.4.57): icmp_seq=3 ttl=255 time=1.01 ms
^C
--- BRN3C2AF45FEC2F.local. ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 1.008/1.218/1.503/0.208 ms
tau% 

So there are some bugs to fix here.

> If we replace the link-local address which a GUA, then most of these questions

Not really true.  Generally speaking, if you give the end user a URL or a hostname, they’ll be okay. If you give them an IPv6 address, they will have no idea what to do with it, and will most likely get it wrong.

IOW, what you are complaining about here is a UI issue, not a problem with link-local addresses.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Sep 2020 09:14:44 -0400

> devices that are permanently or regularly present. 

I don’t think any of us are saying that if you statically configure a GUA on an interface that you have to deconfigure it if the router goes away for 30 minutes.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Sep 2020 09:22:32 -0400

> connection is broken. We should make things better when that happens instead

That’s what we’re trying to do. If we are not doing it correctly, you should argue that case and not tell us to stop trying to do what you also want. That is, if you think this draft makes things worse, that’s the argument you should be making. We all want to make things better.

> because there are some CPEs that use overly long lifetimes.

There is no network admin in most cases. And I think at this point we all have enough experience to know that CPEs will not do the right thing, and that hosts, as a general rule, are more likely to do the right thing.

If your only objection to this proposal is that you don’t want servers to spontaneously abandon statically configured GUAs, I don’t think we have a problem.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Sep 2020 09:38:33 -0400

I agree with Lorenzo and a Phillip and others regarding enterprises with
statically configured IPv6 addresses as being the Norm as well as home
network.  So we as operators should be able to specify larger 32 bit
lifetimes.

Kind Regards

Gyan

> large lifetimes if required in a particular network.

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 9 Sep 2020 15:45:24 +0000

Hi all,
I agree with Philip that 30min is not a good solution. Imagine that your meeting call has been just disconnected. Would it make sense to re-connect to the meeting in 30min?
Old telephony guys did strongly insist on 50ms.
VoIP has trained us to be tolerant to sub-second.
4G fallback (to 3G/2G) has increased our tolerance to 10 seconds.
We would probably have CPE reload in considered case - it means 1-2 min of outage anyway. Then 1 additional minute would not make the big difference.
Flush renumbering would rise this bar to the next level (30min).
What would be next?!?
Is it the phenomenon that has been called "progress"?
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: 9 сентября 2020 г. 13:29
To: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

> You missed my last question. What if the router is _reachable_, but 
> has forgotten its old prefix because it was just rebooted?

> > Only in relatively closed systems like mDNS, you can expect 
> > link-local to work. And even them, most people are likely to fail if 
> > they have to troubleshoot something.
> 
> mDNS is a first-class name service on every operating system out there 
> except Linux. On Linux you have to install either Apples open source 
> mDNSResponder code or avahi-daemon. Im doing development on a 
> Raspberry Pi right now. To ssh to it, I type ssh tau.local. I dont 
> type in an IPv6 address. So if all thats available is a link-local 
> address, itll Just Work.

'every operating system'. This is just not true. Unless you are willing to ignore a lot of software.

Maybe you like mDNS, fine. Maybe other people want to be able to refer to a service even if it is on a different subnet.

Note that SLAAC is also used in companies, etc. This change affects a lot more than just home networks.

> No argument hereit was Lorenzo who complained about ULAs.

I said 'if you want a local address'. I think Lorenzo didn't want to use a local address. On my home I also use global addresses exclusively.

> actually found, and what convinced me, was that actually _not_ using 
> leases made things _worse_, not _better_. This was in the days of IP 
> address scarcity, which isnt an issue with IPv6, but the principle is 
> the same: if you clean up garbage, things work better.  If the prefix 
> is still valid and usable, you should be seeing PIOs advertising it. 
> If you arent seeing them, its garbage.

My exerience is that static address allocation works a lot better for devices that are permanently or regularly present. 

By now most people have learned to live with the fact that devices regularly get different IP addresses. That doesn't mean it is a good idea.

Indeed if you don't have enough IPv4 address then cleaning up may become an issue.

In any case, SLAAC already provides hosts with dynamic configuration. What we talking about it making it impossible for the network operator to see lifetimes of addresses as he or she sees fit.

Or, if we see a host as an end user device, having the host work against the user when the router goes down, but not really helping the user during a flash renumber event because it still takes 30 minutes for the old prefix to be deprecated. Rebooting is quicker.

> > Some DHCP clients actually write the DHCP lease to disk and continue 
> > using the lease after a reboot. There is no reason a SLAAC 
> > implementation couldn't do the same.
> 

There is a common complaint of things not working when an internet connection is broken. We should make things better when that happens instead of making it worse.

Note that any network admin can still set the lifetimes in RAs to a low value. We are doing making a change to all IPv6 hosts in the world just because there are some CPEs that use overly long lifetimes.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Sep 2020 08:13:38 +1000

>    Why does this fail? how to correct the ping command?

Learn how to troubleshoot IPv6.

Reading this article will teach you everything you need to know to make
that work and more.

Pinging all IPv6 nodes on a link
https://ipv6tao.blogspot.com/2020/01/pinging-all-ipv6-nodes-on-link.html?m=1

>    Why does this fail. How to correct this?

Learn how to operate IPv6.

>    addresses. How to do this correctly? What can still go wrong?

Learn how to program IPv6.

>    How you do reach this host using a web browser?

Learn IPv6.

Use the mDNS name. That's how my IPv6 printer works and how Windows 10
prints to it using its Link-Local address.

> one of these questions, and almost none can answer all 4.

Or they can learn something new. Don't get into this dynamic industry if
you don't want to have to learn new things to keep up.

How to use IPv6 Link-Local Addresses in Applications
https://tools.ietf.org/id/draft-smith-ipv6-link-locals-apps-00.html

I don't really understand why you're here, all you seem to want IPv6 to be
is IPv4 with bigger addresses, dragging IPv6 back to  1970s protocol design.

We should be aim for 1980s IPX and AppleTalk ease of use and operation -
and those protocols are where most of IPv6's new features have come from or
been inspired by.

If we replace the link-local address which a GUA, then most of these
> questions

See the above Internet Draft for why GUAs aren't equivalent.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Sep 2020 12:47:49 +1200

> On Sep 9, 2020, at 8:30 AM, Philip Homburg <[email-masked]> wrote:
...
> Why on earth would you ever copy an IPv6 address into the URL bar? How many users know how to do _that_ correctly?

Actually, you can't do it *correctly* because the WHATWG decided in its wisdom to intentionally not implement RFC6874, on the basis of a complaint from some Firefox implementer that it's annoying code to write.
 
> I’m not being facetious here. 

Neither am I. The use case for allowing Zone IDs in URIs was for expert users trying to debug LL reachability issues. WHATWG specifically decided to prevent this use case.

The consequence is that I can log into my CE router via https://[fe80::2e3a:fdff:fea4:dde7]/ but not via https://[fe80::2e3a:fdff:fea4:dde7%256]/ which is the correct format.

That certainly takes some explaining to a typical user, even an expert user.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Sep 2020 20:51:14 -0400

On Sep 9, 2020, at 8:47 PM, Brian E Carpenter <[email-masked]> wrote:
> The consequence is that I can log into my CE router via https://[fe80::2e3a:fdff:fea4:dde7]/ <https://[fe80::2e3a:fdff:fea4:dde7]/> but not via https://[fe80::2e3a:fdff:fea4:dde7%256]/ <https://[fe80::2e3a:fdff:fea4:dde7%256]/> which is the correct format.
> 

I’ve run into the same issue. That’s why I consider it ridiculous to try to copy IP addresses into URL bars, and why I know how to use mDNS to do it. It’s not because I think this is a good outcome. :(

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Sep 2020 21:14:41 -0400

Brian E Carpenter <[email-masked]> wrote:
    > The consequence is that I can log into my CE router via
    > https://[fe80::2e3a:fdff:fea4:dde7]/ but not via
    > https://[fe80::2e3a:fdff:fea4:dde7%256]/ which is the correct format.

But, only on a Windows machine that has a single network interface.
So on your laptop that has a wire and wireless, it won't work.

While it is possible that browsers on other platforms have done something
special, but the OSes don't allow it.

I once tried to stuff:

fe80::2e3a:fdff:fea4:dde7%256   myrouter

into /etc/hosts hoping that the getaddrinfo() call might do the right thing
under the hood, but it sadly doesn't work like that. (I think it should)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Sep 2020 12:35:22 +1000

> special, but the OSes don't allow it.

Glibc's getaddrinfo() now supports zone ids.

> under the hood, but it sadly doesn't work like that. (I think it should)

That doesn't work with Glibc's getaddrinfo() and I also think it should.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Sep 2020 15:39:10 +1200

On 10-Sep-20 14:35, Mark Smith wrote:
> 
> 
> On Thu, 10 Sep 2020, 11:15 Michael Richardson, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>         > The consequence is that I can log into my CE router via
>         > https://[fe80::2e3a:fdff:fea4:dde7]/ but not via
>         > https://[fe80::2e3a:fdff:fea4:dde7%256]/ which is the correct format.
> 

I have Python code that handles zone ids (well, actually, interface
indices) correctly on both WinSock and POSIX stacks. There's very little
code that is OS-dependent. The browser issue is specific to browsers that
obey WHATWG edicts.

   Brian

>     Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
>     [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 02:14:19 -0300

On 9/9/20 21:51, Ted Lemon wrote:
> On Sep 9, 2020, at 8:47 PM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>>> Why on earth would you ever copy an IPv6 address into the URL bar? 
>>> How many users know how to do _that_ correctly?
>>
>> Actually, you can't do it *correctly* because the WHATWG decided in 
>> its wisdom to intentionally not implement RFC6874, on the basis of a 
>> complaint from some Firefox implementer that it's annoying code to write.
>>
>> Neither am I. The use case for allowing Zone IDs in URIs was for 
>> expert users trying to debug LL reachability issues. WHATWG 
>> specifically decided to prevent this use case.
>>
>> The consequence is that I can log into my CE router 
>> viahttps://[fe80::2e3a:fdff:fea4:dde7]/but not 
>> viahttps://[fe80::2e3a:fdff:fea4:dde7%256]/which is the correct format.
>>
> I’ve run into the same issue. That’s why I consider it ridiculous to try 
> to copy IP addresses into URL bars, and why I know how to use mDNS to do 
> it. It’s not because I think this is a good outcome. :(

FWIW, I normally install mDNS on systems where I might want to do 
something like connecting with a link local address. Among other reasns, 
so that I don't need to remember addresses.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 10 Sep 2020 09:19:23 +0100

on the one hand:

Mark Smith wrote on 09/09/2020 23:13:
> and those protocols are where most of IPv6's new features have come from 
> or been inspired by.

 > Learn IPv6.

Apart from the mind-boggling disparity between the two positions you're 
suggesting here, I'm pretty disturbed by Philip's email because of two 
things: firstly how inherently complicated ipv6 is, and secondly this is 
ietf 6man and like Philip, I'll bet that most people in this WG wouldn't 
be able to answer all 4 questions correctly.  I know I couldn't.

This poses the question: is 6man an appropriate working group to be 
entrusted with the maintenance of the ivp6 protocol?

Nick

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Sep 2020 09:26:08 -0400

On Sep 10, 2020, at 4:19 AM, Nick Hilliard <[email-masked]> wrote:
> Apart from the mind-boggling disparity between the two positions you're suggesting here, I'm pretty disturbed by Philip's email because of two things: firstly how inherently complicated ipv6 is, and secondly this is ietf 6man and like Philip, I'll bet that most people in this WG wouldn't be able to answer all 4 questions correctly.  I know I couldn't.
> 
> This poses the question: is 6man an appropriate working group to be entrusted with the maintenance of the ivp6 protocol?

There’s also v6ops.

I think that the working group chairs hold a strong editorial position, and this is arguably not ideal, but on the other hand, if they did not, I suspect that we’d do a lot more harm. If I were to suggest an improvement, it would be that this were done more openly, with more transparency, and with a somewhat muted assumption that everything is already perfectly correct, which I do sometimes notice (sorry, guys!).

That said, any networking stack is going to be complicated. IPv4 is differently complicated. Are you an expert on the many different kinds of network address translation, how they succeed, how they fail, and how to write an application that will win in the maximal set of cases? How about DNS? Do you know all the ways that middleboxes can break DNS, and how to win when they do? Do you know how to correct a bufferbloat problem? Do you know how to configure a multi-subnet home network so that devices on all subnets can discover and reach each other?

The answer is likely that you do not. All of these, including typing in IPv6 addresses, are things that experts know, not things that end users know. End users type in names if they type in anything. They click on URLs. They plug their routers together using similar-looking cables. They do not type in IP addresses.

So the set of bugs I pointed out in the Linux stack need to be fixed, for sure, but the basic issue comes down to good UI design, not to making every user an expert in our obscure field.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 10 Sep 2020 14:07:09 +0000

Hi all,
I completely agree to this: I think you need to tweak source address selection, not lifetimes.
In fact I propose 2 solutions:

1.      Long term: solution that I have proposed in this alias before (see below – new flag in RA). As soon as ND would have major refreshment – it should be already in one of RFC updates ready for cut & paste.

2.      Short term: properly choose address on host side. I am not sure should it be update to HE or RFC 6724 (better last one, but HE is more popular). It is easy – just prefer the address that has longer preferred time (if scope and mask are the same).
Both solutions is better to documented in standards. I do not insist on my long-term solution to be properly documented (it is for future anyway – needs ND versioning), but I am sure that for short-term Lorenzo is right.

Long term clean fix:

> RA (section 4.2 RFC4861) has 2 flags and 6 bits reserved.

> I propose to use 1 bit from reserved for additional flag: "C"="Complete". It would mean that RA has all information in this packet, including all PIOs.

> If host have recorded before some other information from the *same router* (same LLA) - then absence of this information in last RA means that information should be deprecated, irrespective of timers.

> I propose to immediately put address from missing PIO into " deprecated " state up to the end of the life for this prefix.

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 7 сентября 2020 г. 6:19
To: Fernando Gont <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

I disagree with this change because it reduces the expressiveness of SLAAC as a configuration protocol. It effectively turns a 32-bit field into a 16-bit field, and makes it no longer possible to have lifetimes that outlive the default router lifetime. This often is a valid configuration. In particular, it is a valid configuration when the IPv6 prefix is statically allocated. This is often the case in enterprise networks, but is also often the case in residential networks as well. My IPv6 prefix is static, for example.

It also complicated host implementations. If you want to make this more reliable, I think you need to tweak source address selection, not lifetimes.

On Sun, Sep 6, 2020 at 10:00 PM Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

The text is:

---- cut here ----

    RATIONALE:

---- cut here ----

Thoughts?

Thanks!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 10 Sep 2020 17:04:47 +0200

Eduard,

Would you mind writing a draft on that?

Best regards,
Ole

> On 10 Sep 2020, at 16:07, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi all,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 11:12:34 -0400

Mark Smith <[email-masked]> wrote:
    >> Brian E Carpenter <[email-masked]> wrote: > The
    >> consequence is that I can log into my CE router via >
    >> https://[fe80::2e3a:fdff:fea4:dde7]/ but not via >
    >> While it is possible that browsers on other platforms have done
    >> something special, but the OSes don't allow it.
    >>

    > Glibc's getaddrinfo() now supports zone ids.

Yes, and it has supported it for awhile.  I can certainly ping6 LL.
But, browsers don't use it, which is the problem.

    >> into /etc/hosts hoping that the getaddrinfo() call might do the right
    >> thing under the hood, but it sadly doesn't work like that. (I think it
    >> should)
    >>

    > That doesn't work with Glibc's getaddrinfo() and I also think it

that seems fixeable.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 10 Sep 2020 16:01:19 +0000

Hi Ole,
You probably mean only long-term solution (RA improvement). No problem. I will.
Because short term idea from Lorenzo should be probably added to the current draft of Fernando. 30min interruption for soccer live translation is definitely not acceptable solution.
Please confirm, that I have understood you right.
Potentially I could specify both.
Eduard
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 10 сентября 2020 г. 18:05
To: Vasilenko Eduard <[email-masked]>
Cc: Lorenzo Colitti <lorenzo=[email-masked]>; Fernando Gont <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

Eduard,

Best regards,
Ole

> The next one is about processing PIOs at hosts, such that hosts cap 
> the received values to the advertised Route Lifetime -- except when 
> the Router Lifetime is set to the special value 0 ("do not use this 
> router as a default router") or when the prefix lifetimes are set to 
> the special value 0xffffffff ("infinity").
> 
> This allows hosts to use more appropriate lifetimes even if routers 
> are employing the large default values from RFC4861.
> 
> The text is:
> 
> ---- cut here ----

---

From: [email-masked]
Date: Thu, 10 Sep 2020 19:44:49 +0200

Eduard,

> Potentially I could specify both.

When we adopted this work, we adopted the problem, and we would certainly encourage alternative solutions.
Perhaps we need to go back to requirements, and also see what's short-comings in implementations versus what's shortcomings in specifications.
To see if we can properly solve the larger robustness problems. If there is one.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 16:29:50 -0300

Ole,

> Perhaps we need to go back to requirements, and also see what's short-comings in implementations versus what's shortcomings in specifications.

FWIW, following your own (chairs') advice, some of us are getting work 
started to produce not only a set of of desired requirements, but also a 
set of proposed solutions that can be evaluated in the light of such 
requirements, to bring to the working group for discussion and evaluation.

So far we're at least the current authors and Philip, with another 
member yet to be confirmed.

What we have tried to do so far is to discuss each of the mitigations 
that are orthogonal to the one that seemed to be the center of objections.

And having cleaned that from the table, proceed and focus on that.

> To see if we can properly solve the larger robustness problems. If there is one.

Give that we have been discussing the topic for more than 1.5 years, and 
that we have a problem statement document 
(draft-ietf-v6ops-slaac-renum), is it too much to expect that the 
problem be acknowledged, and that we try to solve it, instead of 
possibly boiling the ocean?

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Sep 2020 15:40:25 -0400

On Sep 10, 2020, at 3:29 PM, Fernando Gont <[email-masked]> wrote:
> Give that we have been discussing the topic for more than 1.5 years, and that we have a problem statement document (draft-ietf-v6ops-slaac-renum), is it too much to expect that the problem be acknowledged, and that we try to solve it, instead of possibly boiling the ocean?

Indeed, best is the enemy of good enough here. Let’s proceed with the work we are doing before adding new work.

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Sep 2020 13:23:27 +1000

On Thu, 10 Sep 2020, 18:19 Nick Hilliard, <[email-masked]> wrote:

> suggesting here,

Please don't take my statements and selectively quote them, delete context
and change their order to suit your position and the criticisms you want to
make.

For many things, ease of use usually comes at a cost of complexity. A car
made in 2020 is much easier to use than a car made in 1920. A 2020 car is
also much more complex and requires much more expertise to fix when it
fails. The complexity also means that it fails less often in common
possible failure situations.

The idea and deployment of a "link local" or "this network" network address
is not new at all. It has existed in IPv4 since 1989 (see RFC1122, 3.2.1.3),
in Novell's IPX, likely Xerox XNS as IPX is based on that, and in Apple's
Appletalk.

Nothing in IPv6 is new, IPv6 versions are just generalised or more
efficient versions of what has been done and been done widely before.

I'm pretty disturbed by Philip's email because of two
> things: firstly how inherently complicated ipv6 is,

and secondly this is

Nick