Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 04:29:38 -0300

On 1/11/19 03:49, Mark Smith wrote:
> 
> 
> On Fri, 1 Nov 2019, 14:31 Fernando Gont, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On 31/10/19 21:20, Mark Smith wrote:
>     >
>     >
>     > On Fri, 1 Nov 2019, 06:34 Ted Lemon, <[email-masked]
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     On Oct 31, 2019, at 3:21 PM, Fernando Gont
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >>     On 27/10/19 09:02, Ted Lemon wrote:
>     >>>     Indeed, this would also not actually solve the problem.   At
>     present,
>     >>>     the ISPs are doing something that is out of spec and causes
>     problems.
>     >>>     If we “fix” this by accommodating what they do, does that
>     help, or
>     >>>     does it just encourage them to continue doing it?
>     >>
>     >>     Did happy eyeballs encourage broken IPv6 connectivity, or did it
>     >>     actually help IPv6 deployment?
>     >
>     >     Don’t get me wrong—I’m not saying we shouldn’t do things to
>     improve
>     >     the situation.   I am saying that we should be strategic about it.
>     >
>     >>>     What should be happening on the host with a prefix that’s
>     deprecated
>     >>>     is that TCP connections should be timing out.   This doesn’t
>     take
>     >>>     very long.  
>     >>
>     >>     ~9 minutes, IIRC.
>     >
>     >     Should be 90 seconds.
>     >
>     >
>     > You've got no more than 10 seconds unless you want end users to
>     actively
>     > try to do something to recover, which can include calling their ISP's
>     > helpdesk.
> 
>     I'd argue the opposite..
> 
> 
> 
> I wouldn't argue with research from 1968, referenced in an article from
> 1993, by an expert in usability, cited in my slides.
> 
> 
>   Response Times: The 3 Important Limits
> 
> https://www.nngroup.com/articles/response-times-3-important-limits/

What I meant is that I wouldn't expect you to deal with this at the
transport layer, but at the app layer. Setting timers to small values at
the transport layer is asking for all sort of failures. -- and not only
that: you could have situations in which the transport-layer timers
don't go off (say, you do get some data at the transport layer), but you
don't get the app protocol-data-units that you can act upon.

[....]
> 
> It not being in control of the user is the point of knowing UX/HCI
> factors so the good default response times can be chosen.
> 
> TCP's default timeouts are way too large for a good end user experience.
> I don't know what criteria were used to select them, but it certainly
> wasn't human usability factors.

TCP is not optimized for anything (although IIRC there are now
"flavours" of TCP popping up). TCP simply aims at reliability, so that,
unless there's an unrecoverable error, TCP does it best to make the data
delivered to the remote TCP. The long user timeout means that transient
network errors can be recovered.

Similarly, TCP has an exponential back-off -- something that will likely
not relate into nice response times.

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Nov 2019 04:50:55 -0400

On Oct 31, 2019, at 10:27 PM, Fernando Gont <[email-masked]> wrote:
>> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the
>> situation.   I am saying that we should be strategic about it.
> 
> For the home network case, the situation right now is that there are
> deployments that break, and ISPs meaning to deploy IPv6 that can't do
> stable prefixes. Certainly, that's a very bad strategy on our side.
> 
> That said, and as noted, the home network case is just *one* scenario
> where this problem may be faced. And a subset of the mitigations for
> this scenarios are useful for the general case.

You mention later that if it takes more than ten seconds for the connection to resume, the user will be on the phone to the ISP.  It sounds, then, like they already have an incentive to configure their networks so that this doesn’t happen.   So why aren’t they doing that?   What’s the obstacle?

>>>> What should be happening on the host with a prefix that’s deprecated
>>>> is that TCP connections should be timing out.   This doesn’t take
>>>> very long.  
>>> 
>>> ~9 minutes, IIRC.
>> 
>> Should be 90 seconds.
> 
> Nope. The default user timeout is 5 minutes as per RFC793. (The first
> para of the second page of RFC5482 provides a summary wrt the
> specification of the user timeout).

Hm, okay.

>>> That's not correct. Neither the Valid Lifetime nor the Preferred
>>> Lifetime affect address selection.
>> 
>> Okay, there’s something to fix.  Why would these not affect source
>> address selection?
> 
> For many reasons: one of them: two different routers might be using
> different values for these timers, in an un-coordinated manner. And
> there's not reason for which the smaller or larger lifetimes should
> imply an address is preferred.
> 
> OTOH, you might thing about preferring "the last advertised prefix". BUt
> that would mean that src address would flap, which is bad for
> trouble-shooting.

On what actual network would this scenario occur, though, in a way that would actually cause the problem you anticipate?  I know you can set this up in the lab.   But in practice, I never have two competing routers advertising different and incompatible lifetimes for the same prefix on my home network.  So if you want to break things in other ways in order to be able to adapt to this situation, it should be likely.  When and where is it likely?

As for previous comments about source address selection, I think that if you have two prefixes that are otherwise equivalent (a tie), and one has a preferred lifetime of zero, while the other has a preferred lifetime of not-zero, it would be dysfunctional to choose the one with the preferred lifetime of zero.  What on earth is the purpose of preferred and valid lifetimes if SAS isn’t taking them into account?

>> What is “FHS”?
> 
> Sorry, for that: First Hop Security, Cisco's speak for RA-Guard, ND
> inspeaction, and so on…

Ah.   Maybe we should call that NKB (network knows best).

>>>> If you Really Really want to be able to have the routers send out RAs
>>>> that deprecate the default route, and, as Mark is saying here, to
>>>> upgrade millions or perhaps billions of hosts, why not ask for
>>>> something that’s a real improvement?
>>> 
>>> Every piece helps.
>> 
>> Right, but if the effort involved in two different options differs by
>> epsilon, you should always choose the option that produces the better
>> outcome, shouldn’t you?
> 
> Is there any of the proposed fixes that we shouldn't be doing, already,
> anyway?

   o  CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
      messages upon reboot events.

We should definitely be doing this, but it might be worth pointing out that a very simple fix for this problem would be to have the server acknowledge the release but ignore it.  The server is allowed to give out the same prefix again even when it’s received a release, so the release is not a “change my prefix” signal, and perhaps we should explicitly advise that it not be treated that way.   This would be an easy tweak in a DHCP server, much easier than updating a billion CPEs.

   o  A CPE router sending RAs that advertise dynamically-learned
      prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
      stable storage, the list of prefixes being advertised on each
      network segment.

Okay.   However, if an ISP makes the change I suggest above, this is no longer necessary, although I think it’s still good advice.

Your other proposed changes seem fine to me; my main focus here is really on whether there are other things we could be doing that would improve things even more.

>>> What's the practical difference between that, an a network that supports
>>> RA-Guard?
>> 
>> On a network that supports RA guard, there probably is no difference,
>> but RA guard on some networks, as we’ve discussed in the past, will
>> actually make the network not work.   RA guard requires an active
>> administrator.   So the CPE case we’re talking about isn’t relevant.
> 
> The point is: in a network where you do not employ RA-Guard, you are
> already trusting the router. Actually, it's worse: you trust all local
> systems.

That’s why I’m suggesting that there might be a way to allow us to trust less and verify more, rather than having an entity on the wire that has no basis for knowing which devices are trustworthy and which are not, making that decision for us (NKB).

>>>> When another RA arrives, see if it was signed with the same key.   If
>>>> so, it came from the same router, and can be trusted to update
>>>> whatever information that router sent, including flash-deprecating a
>>>> prefix.   If not, ignore it.
>>> 
>>> In the non-SEND trust model, you do trust the local router. Why did you
>>> trust the local router to configure your network, but not for
>>> deprecating the prefix?
>> 
>> In the non-SEND trust model, you trust the local network.   You
>> /hope/ that the RA you get “from the router” is actually from the router.
> 
> Exactly: that's the point: you already trust the local network. What's
> the rationale for trusting one of the RAs, but not the others?

If I get an RA that’s not signed by the same key as a route in my routing table that’s working, I don’t let it override what is currently in my routing table and working.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 06:45:04 -0300

On 1/11/19 05:50, Ted Lemon wrote:
> On Oct 31, 2019, at 10:27 PM, Fernando Gont <[email-masked]
> You mention later that if it takes more than ten seconds for the
> connection to resume, the user will be on the phone to the ISP.  It
> sounds, then, like they already have an incentive to configure their
> networks so that this doesn’t happen. 

In the presence of Happy Eyeballs, the problem will be masqueraded.

> So why aren’t they doing that?   What’s the obstacle?

Are you referring to the CPE case, or to the rest?

[....]
> On what /actual/ network would this scenario occur, though, in a way
> that would actually cause the problem you anticipate?  I know you can
> set this up in the lab.   But in practice, I never have two competing
> routers advertising different and incompatible lifetimes for the same
> prefix on my home network.  So if you want to break things in other ways
> in order to be able to adapt to this situation, it should be likely.
>  When and where is it likely?

If you assume all routers employ the same values for the valid/preferred
lifetimes, then what you propose is the equivalent to "prefer the last
advertised prefix". In which case, in the presence of multiple RAs the
src address of new sessions will deterministically flap. That doesn't
seem nice from a troubleshooting perspective.

> As for previous comments about source address selection, I think that if
> you have two prefixes that are otherwise equivalent (a tie), and one has
> a preferred lifetime of zero, while the other has a preferred lifetime
> of not-zero, it would be dysfunctional to choose the one with the
> preferred lifetime of zero.  What on earth is the purpose of preferred
> and valid lifetimes if SAS isn’t taking them into account?

The timers are only supposed to be of use if they go off. Given the
default values the use (one month, and one week), they never go off.

The valid lifetime would trigger garbage collection for stale prefixes.
The preferred lifetime would keep a fresh and working address as the
preferred address for new flows. -- if only they went of in a timelier
manner.

So, I'd rather ask the question: what on earth is the purpose of setting
a timer that will never go off in a meaningful situation and period of time?

> We should definitely be doing this, but it might be worth pointing out
> that a very simple fix for this problem would be to have the server
> acknowledge the release but ignore it.

What if the user does want to release the prefix, e.g. for privacy reasons?

>  The server is allowed to give
> out the same prefix again even when it’s received a release, so the
> release is not a “change my prefix” signal, and perhaps we should
> explicitly advise that it not be treated that way.   This would be an
> easy tweak in a DHCP server, much easier than updating a billion CPEs.
> 
> Okay.   However, if an ISP makes the change I suggest above, this is no
> longer necessary, although I think it’s still good advice.
> 
> Your other proposed changes seem fine to me; my main focus here is
> really on whether there are other things we could be doing that would
> improve things even more.

I'm all for that.

> That’s why I’m suggesting that there might be a way to allow us to trust
> less and verify more, rather than having an entity on the wire that has
> no basis for knowing which devices are trustworthy and which are not,
> making that decision for us (NKB).

Not that I oppose to that. But I just note that there's no reason for ot
trusting a router that advertises PIO,VL=0, because your trust model is
that you do trust the router (if not your whole local network).

> If I get an RA that’s not signed by the same key as a route in my
> routing table that’s working, I don’t let it override what is currently
> in my routing table and working.

But that's not the current deployed reality. IN current deployments, RAs
are not signed. So why wuld you be skeptical to PIO, VL=0?

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Nov 2019 06:11:52 -0400

> Are you referring to the CPE case, or to the rest?

I’m specifically referring to the ISP case, although I think referring to it as “the CPE case” is limiting your options! :)

> seem nice from a troubleshooting perspective.

No, I’m saying that if you have two prefixes, one with a preferred lifetime of zero, and another with a preferred lifetime that is not zero, you should choose the second one.   Can you explain in a little more detail when this would cause a “deterministic flap”?

> a timer that will never go off in a meaningful situation and period of time?

Possibly we are talking past each other.   A prefix with a preferred lifetime of zero always has a preferred lifetime of zero.   There’s no timer to go off.   How the preferred lifetime got to be zero is of course an important question, and there I think that what you are getting at is important: a 30 day expiry time is way too long.

> are not signed. So why wuld you be skeptical to PIO, VL=0?

Right, we have a problem there.   SEND didn’t solve it.   I don’t think RA Guard solves it for the home case.   So, there is work to do… :)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 06:54:38 -0300

On 1/11/19 05:50, Ted Lemon wrote:
> connection to resume, the user will be on the phone to the ISP.

On this lat/long, *if* the failure is visible (likely not, thanks to
Happy Eyeballs), people will normally just unplug and reconnect all
boxes (e.g. CPE router). Normally, a call to the ISP will lead to the
same procedure.

(Then, in my own circle, *I* get the call. And based on past
experiences, I wouldn't bother to try to escalate the issue at the ISP,
and most likely disable IPv6 myself, keep my folks' networks running,
and use my time for something else.)

P.S.: On a related note, IPv4 masquerading IPv6 issues is the same
reason why there have not been peaks of support calls complaining about
the DNS configuration mess(android with no dhcpv6, windows with no rdnss).

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 07:39:52 -0300

On 1/11/19 07:11, Ted Lemon wrote:
> On Nov 1, 2019, at 5:45 AM, Fernando Gont <[email-masked]
> I’m specifically referring to the ISP case, although I think referring
> to it as “the CPE case” is limiting your options! :)

At least one ISP reported issues with their provisioning system. I will
ask another, and come back to you.

> No, I’m saying that if you have two prefixes, one with a preferred
> lifetime of zero, and another with a preferred lifetime that is not
> zero, you should choose the second one.   Can you explain in a little
> more detail when this would cause a “deterministic flap”?

I misunderstoof you. What I was assuming that you were describing is this:

* CPE no longer advertises OLDPREFIX

* CPE now advertises NEWPREFIX

* If hosts always prefer the prefix with the larger Preferred Lifetime
(or the latest advertised Prefix), then you have "solved the problem"

However, in a scenario where you have two routers, Router_A that
advertises PREFIX_A, and Router_B that Advertises Prefix_B, then, upon
receipt of an RA from Router_A, Prefix_A would become preferred. But
then, when an RA from Router_B is received, Prefix_B will become
preferred. Then, upon receipt of an RA from Router_A, Prefix_A will
become preferred again.

In the case you discribe, all is fine. However, the key is: what caused
the Preferred Lifetime to become 0? (and RA from the CPE trying to
deprecate a previous prefix?)

> Possibly we are talking past each other.   A prefix with a preferred
> lifetime of zero always has a preferred lifetime of zero.   There’s no
> timer to go off.   How the preferred lifetime /got/ to be zero is of
> course an important question, and there I think that what you are
> getting at is important: a 30 day expiry time is way too long.

Yep, then we were talking past each other :-)

> Right, we have a problem there.   SEND didn’t solve it.   I don’t think
> RA Guard solves it for the home case.   So, there is work to do… :)

Improvements in this area would certainly be nice. However, my point is
that it should be quite acceptable for one to update RFC4861 such that
PIO, VL=0 be honored, since the trust model is that you do trust
routers... and, in terms of DoS, there are already pletny of other
vectors for an attacker to exploint.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Nov 2019 12:17:24 +0100

Ted,

>> RA Guard could be default configured on switches with particular default “plug router in here” (uplink) ports, eliminating the need for an active administrator. This could be a useful specification in the HomeNet documents, perhaps.
> 
> This would be disastrous.   It pretty much makes permissionless networking impossible in exchange for solving a security problem no-one has.

At the risk of straying off topic. There is no mechanism for permissionless networking in IPv6.
(which I think is a big gap)

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Nov 2019 08:22:43 -0400

> (which I think is a big gap)

Do you mean permissionless advertising of routes to new networks?   If so, I agree.   It can be made to sort of work for limited cases, but there’s no standardized way to make end-to-end connectivity work between all networks using the various bits of protocol and practice that we have at present.

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Nov 2019 14:51:09 +0100

Hi Ted,

> Do you mean permissionless advertising of routes to new networks?   If so, I agree.   It can be made to sort of work for limited cases, but there’s no standardized way to make end-to-end connectivi…

I would define it as:
"Permission-less extensions of the network with new links (and by implications new routers) are not supported."

NPT66/NAT66 is the only alternative (talking network layer here).

If we have permission then:
 - normal managed network. Just add new router and run routing protocol. Manually managed addressing
 - HNCP (automated addressing and routing)
 - hierarchical DHCP PD (only works in single rooted DAG)
 - proxy ND (RFC recommending against)

Cheers,
Ole

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Nov 2019 08:38:42 -0700

> On Oct 31, 2019, at 8:02 PM, Fernando Gont <[email-masked]> wrote:
> 
> On 31/10/19 16:38, Owen DeLong wrote:
>> 
>> 
>>> On Oct 31, 2019, at 12:21 PM, Fernando Gont <[email-masked]> wrote:
>>> 
>>> Hello, Ted,
>>> 
>>> 
>>>> Indeed, this would also not actually solve the problem.   At present,
>>>> the ISPs are doing something that is out of spec and causes problems.
>>>> If we “fix” this by accommodating what they do, does that help, or
>> Considering these mutually exclusive is a false dichotomy.
>> 
>> It did both.
> 
> It's hard for me to believe that folks were breaking stuff on purpose.

Perhaps “encouraging broken…” is too strong, but certainly it “reduced motivation to fix broken IPv6” and “reduced visibility of broken IPv6”.

> In any case, I would assume and expect that helping IPv6 deployment was
> more of a priority at the time. IN fact, we wouldn't be talking about
> "google seeing 25% of IPv6" if there wasn't a way to circumvent
> brokenness, I'd assume.

It absolutely was more of a priority and that’s why it was implemented. However, we should recognize that it was not without collateral damage.

It may be that we accept that this idea, too, comes with certain unintended consequences, but we should at least make a legitimate effort to identify and consider them, mitigate them to the extent possible, and then make a conscious deliberate decision to accept them (or not).

> [...]
>> Trusting the local router to configure the network to add a previously non-operational host to the network has a somewhat different set of consequence for failure than trusting whatever on-link host wishes to tell you to effectively shut down your currently operating network connection.
> 
> We'll that's the SLAAC model.

I think you are still missing the point here… The current SLAAC model is trusting the router to configure the network. The consequences when this model fails are that new hosts have difficulty (or failure) joining the network. In most cases, it has pretty limited consequences to existing hosts ability to continue to run.

On the flip side, what is being proposed does create a possibility where a single crafted packet can literally immediately disconnect every host on the link from the network.

The model is the same, but the consequences are significantly different, so perhaps the greater consequences warrant considering a different trust model.

> 
> 
> 
>> Especially when you consider that such an announcement can be sent to the all nodes on link multicast address, effectively dropping them all at once.
>> 
>> I agree it’s not a huge difference, but, it is a difference and certainly the scope of the resulting problem can be much larger than the case of individual host configuration.
> 
> Hosts trust a lot of other crap. e.g., feel free to advertising a Cur
> Hop Limit of 1. Is that any different?

Yes… A hop limit of 1 leads to errors that make the cause rather obvious.

Crafted RAs that send out PIOs deprecating all the actually valid prefixes lead to error conditions that can be much harder to identify/isolate.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Nov 2019 08:39:45 -0700

> On Oct 31, 2019, at 8:06 PM, Fernando Gont <[email-masked]> wrote:
> 
> On 31/10/19 16:39, Owen DeLong wrote:
>> 
>> 
>>> On Oct 31, 2019, at 12:25 PM, Fernando Gont <[email-masked]> wrote:
>>> 
>>> On 27/10/19 10:54, Ted Lemon wrote:
>>>> On Oct 27, 2019, at 9:41 AM, Philip Homburg <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>> The little bit missing is that the CPE should write prefixes
>>>>> advertised using
>>>>> SLAAC to persistent storage which allows the CPE to invalidate stale
>>>>> prefixes
>>>>> after a reboot.
>>>> 
>>>> Actually I do not believe this is correct behavior.   Let us assume
>>>> prefix delegation.   If we have prefix delegation, then when the CPE
>>>> comes back from a power cycle, it should reconfirm the prefix it had
>>>> previously; the assumption is that that prefix is still valid.  This can
>>>> be handled in infrastructure—the ISP edge router should know whether the
>>>> prefix is still valid, because if it is it should be advertising a route
>>>> for it.   If it is not still valid, then the CPE router should attempt
>>>> to renew it, which would go to the DHCP server (possibly both messages
>>>> would).
>>> 
>>> That assues the CPE has stored the previously-leased prefix on stable
>>> storage -- which does not need to be the case. Hence the related text in
>>> our I-D.
>> 
>> IMHO, the CPE requirements should be increased and the CPE should be required
>> to store the prefix and it’s expected valid and preferred expiration times in persistent
>> storage. I would like to see the text in the I-D updated accordingly.
> 
> It's already there (draft-gont-v6ops-slaac-renum-00):
> 
> 3.2.1.  Signaling Stale Configuration Information
> 
>   In order to phase-out stale configuration information:
> 

Where is the mention of storing the expiration times?

Did I miss it, or did you miss that part of my comment?

Owen

> Thanks!

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Nov 2019 08:48:33 -0700

> On Oct 31, 2019, at 8:18 PM, Fernando Gont <[email-masked]> wrote:
> 
>> <mailto:[email-masked]>> wrote:
>> 
>>    On Oct 31, 2019, at 3:21 PM, Fernando Gont <[email-masked]
>>    Don’t get me wrong—I’m not saying we shouldn’t do things to improve
>> You've got no more than 10 seconds unless you want end users to actively
> I'd argue the opposite. But, anyway, for the most part the user timeout
> is not under the control of the user.

It depends on which user time out you are referring to…

The TCP stack user timeout is not under user control.

The time between when the user clicks on a URL and the when the user starts
hitting the refresh button in the browser with a frequency that increases in
proportion to said user’s frustration level is entirely under the user’s
control.

Which of these timers is more significant is left as an execrcise to the reader.

Owen

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Nov 2019 16:16:07 +0000

>    Where is the mention of storing the expiration times?

Also, based on RFC8415 this means that the client should use a DHCPv6 Rebind when it powers back on as now it has the information to ask whether it is still valid (assuming it hasn't expired)?

See Section 18.2.18 of RFC8415:

   Whenever a client may have moved to a new link, the
   prefixes/addresses assigned to the interfaces on that link may no
   longer be appropriate for the link to which the client is attached.
   Examples of times when a client may have moved to a new link include
   the following:

   -  The client reboots (and has stable storage and persistent DHCP
      state).

   -  The client is reconnected to a link on which it has obtained
      leases.

   -  The client returns from sleep mode.

   -  The client changes access points (e.g., if using Wi-Fi
      technology).
...

   If the client has any valid delegated prefixes obtained from the DHCP
   server, the client MUST initiate a Rebind/Reply message exchange as
...

- Bernie

On 11/1/19, 11:41 AM, "v6ops on behalf of Owen DeLong" <[email-masked] on behalf of [email-masked]> wrote:

    

    Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Nov 2019 09:33:03 -0700

> On Nov 1, 2019, at 3:11 AM, Ted Lemon <[email-masked]> wrote:
> 
> On Nov 1, 2019, at 5:45 AM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:

What we’re talking about is the case where you have two routers advertising the same PIO with the same VL. Let’s assume you are using a VL=3600 in your PIOs on both routers and that the routers started up 1800 seconds apart.

At T=0, you get RA from router A with prefix 2001:db8:4000:5000::/64 PL=3600
You start a bunch of flows using that address.
At T=1800, you get RA from router B with prefix 2001:db8:b000:c000::/64 PL=3600.
Your record for 2001:db8:4000:5000::/64 has PL=1800 remaining.
Therefore, you now start (under your proposal) using 2001:db8:b000:c000::/64 as your source
prefix for all new flows.
At T=3600, you get RA from router A refreshing prefix 2001:db8:4000:5000::/64 PL=3600
which resets the PL timer for that prefix to 3600 while the PL timer for …:b000:c000::/64
has now counted down to 1800. Under your proposal, we flap back to 2001:db8:4000:5000::/64.

Lather, rinse, repeat this change in source address every 1800 seconds.

Obviously, real world scenarios will be more complicated and the randomness of RA refresh will come into play making it slightly less deterministic as to when these flaps occur.

> Right, we have a problem there.   SEND didn’t solve it.   I don’t think RA Guard solves it for the home case.   So, there is work to do… :)

Why can’t RA Guard solve it for the home case?

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Nov 2019 11:14:32 -0700

Rebind isn’t the same as remembering.

Consider the situation where a cable provider rehouse the customer to an entirely different CMTS which may utilize an entirely different DHCP server. A rebind is not going to get useful timer data in response.

Owen

> On Nov 1, 2019, at 9:16 AM, Bernie Volz (volz) <[email-masked]> wrote:
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Nov 2019 20:44:37 +0000

Owen .. this is IF the device remembers (i.e., writes the information to persistent storage).

> A rebind is not going to get useful timer data in response.

Yes, it should. This is because the CPE will include its existing (remembered) prefixes in the Rebind and the server that receives this can immediately respond with lifetimes of 0 if the PDs are no longer valid for where the CPE is "now" connected. Which is exactly what you wanted the device to know.

Here's text from https://tools.ietf.org/html/rfc8415#section-18.3.5:

   If the server finds that the client entry for the IA and any of the
   addresses or delegated prefixes are no longer appropriate for the
   link to which the client's interface is attached according to the
   server's explicit configuration information, the server returns those
   addresses or delegated prefixes to the client with lifetimes of 0.

- Bernie

-----Original Message-----
From: Owen DeLong <[email-masked]> 
Sent: Friday, November 1, 2019 2:15 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Fernando Gont <[email-masked]>; [email-masked]
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Owen

>>>>> On Oct 27, 2019, at 9:41 AM, Philip Homburg 
>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> advertised using SLAAC to persistent storage which allows the CPE 
>>>>>> to invalidate stale prefixes after a reboot.
>>>>> 
>>>>> comes back from a power cycle, it should reconfirm the prefix it 
>>>>> had previously; the assumption is that that prefix is still valid.  
>>>>> This can be handled in infrastructure—the ISP edge router should 
>>>>> know whether the prefix is still valid, because if it is it should be advertising a route
>>>>> to renew it, which would go to the DHCP server (possibly both 
>>>>> messages would).
>>>> 
>>>> That assues the CPE has stored the previously-leased prefix on 
>>>> stable storage -- which does not need to be the case. Hence the 
>>>> related text in our I-D.
>>> 
>>> IMHO, the CPE requirements should be increased and the CPE should be 
>>> required to store the prefix and it’s expected valid and preferred 
>>> expiration times in persistent storage. I would like to see the text in the I-D updated accordingly.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 4 Nov 2019 09:34:46 +0100

> "Permission-less extensions of the network with new links (and by implications new routers) are not supported."

This is a problem statement.  It must be put in a draft.

There is a related problem statement about the IID being 64bit length, 
and the SLAAC on Ethernet running only on that.

They could be associated.

Alex