Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 1 Feb 2019 20:02:28 +0100 (CET)

On Thu, 31 Jan 2019, Fernando Gont wrote:

> Question:
> How about making the update to the "Valid Lifetime" a SHOULD or MAY,
> instead?  Or, maybe, at least, set it to the current "Valid Lifetime"?
> Otherwise, with the default values for the "Valid Lifetime", the
> addresses might lie around for 1 month....

I had a real life example today. I have OpenWrt 18.06.1 HGW. This morning, 
I lost Internet access. After diagnosing I realised that WAN was not 
working correctly, so I did "ifdown wan" and "ifdown wan6", switched to my 
secondary provider (which I was still on contract with but don't normally 
use) and then did "ifup" on both. I received new IPv4 GUA and IPv6 GUA PD 
/56, which was then announced on my br-lan. I then ran on that for 3-4 
hours until my regular provider had fixed their hardware problem. Then I 
did the whole ifddown procedure, swapped WAN cable to normal ISP, and did 
ifup again.

Now, I saw IPv6 IA_NA for the temp ISP /56 with a week lifetime on wired 
LAN device so I was a bit worried this would cause long-time problems, but 
the prefixes were deprecated and I couldn't find any actual issues (source 
address selection worked properly). A few hours later all these addresses 
were gone even from my purely wired devices that hadn't seen any link 
down/up events.

So potentially RFC7084 style solves most problems together with 
https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 style 
WAN down/up detection for the IPoE deployment case (PPPoE already have 
this).

OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so I 
would propose to investigate further what hosts today actually do in 
reaction to RFC7084 signalling.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Sat, 02 Feb 2019 12:32:14 +0100

>FWIW, our first initial version only changed the "Preferred Lifetime",
>and never modified the "Valid Lifetime". Then we realized it was easy to
>update the "Valid Lifetime" with the same "mechanism" and incorporated
>that. THe most important bit is, indeed, updating the "Preferred Lifetime".
>
>Question:

In think it is better to solve two separate problems independently and only
merge the solutions if the same solution happens to apply to both.

When router reboots and switches to a new prefix, hosts should switch to the
new prefix as soon as possible. 

On the other hand, removing addresses that have preferred lifetime of zero
is a bookkeeping task that can take more time.

One question is whether it makes sense for routers to have valid lifetimes of
more than a day for prefixes that are obtained using DHCP-PD.

Another is whether general purpose hosts should accept lifetimes of more
than a day. Maybe hosts should just truncate.

If that doesn't solve the issue, then for the valid lifetime it make sense for
the host to wait multiple RA intervals to make sure the router really doesn't
advertise the prefix.

>The mechanism in the document tries to accommodate the case where the
>information conveyed in an RA is split among two RA messages -- so it's
>the second RA with the PIO that causes the update, rather than the first
>one. In all current practical cases, all info is normally conveyed into
>a single RA. However, the mechanism that's currently in the I-D allows
>for cases where it can be split in two.

What happens if a router would advertise 4 prefixes in 4 separate RAs?

---

From: Ole Troan <[email-masked]>
Date: Sat, 2 Feb 2019 12:57:29 +0100

> than a day. Maybe hosts should just truncate.

The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP.
Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that.

The simple solution to this problem is “if it hurts, stop doing it”.

Cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Sat, 2 Feb 2019 19:47:28 -0800

It sounds to me like you needed manual intervention to fix things. Mere mortals need for it to sect that it was down and do the right thing, then detect that it was restored and address that...

Sent using a machine that autocorrects in interesting ways...

> On Feb 1, 2019, at 11:02 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I had a real life example today. I have OpenWrt 18.06.1 HGW. This morning, I lost Internet access. After diagnosing I realised that WAN was not working correctly, so I did "ifdown wan" and "ifdown wan6", switched to my secondary provider (which I was still on contract with but don't normally use) and then did "ifup" on both. I received new IPv4 GUA and IPv6 GUA PD /56, which was then announced on my br-lan. I then ran on that for 3-4 hours until my regular provider had fixed their hardware problem. Then I did the whole ifddown procedure, swapped WAN cable to normal ISP, and did ifup again.
> 
> Now, I saw IPv6 IA_NA for the temp ISP /56 with a week lifetime on wired LAN device so I was a bit worried this would cause long-time problems, but the prefixes were deprecated and I couldn't find any actual issues (source address selection worked properly). A few hours later all these addresses were gone even from my purely wired devices that hadn't seen any link down/up events.
> 
> So potentially RFC7084 style solves most problems together with https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 style WAN down/up detection for the IPoE deployment case (PPPoE already have this).
> 
> OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so I would propose to investigate further what hosts today actually do in reaction to RFC7084 signalling.
> 
> -- 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 3 Feb 2019 08:51:49 +0100 (CET)

On Sat, 2 Feb 2019, Fred Baker wrote:

> It sounds to me like you needed manual intervention to fix things. Mere 
> mortals need for it to sect that it was down and do the right thing, 
> then detect that it was restored and address that...

If I had support for 
https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 then no 
manual intervention would have been needed.

Problem I have with my setup is that my WAN physical port doesn't go down 
just because the upstream router goes unreachable.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 01:26:58 -0300

Hello, Philip,

> is a bookkeeping task that can take more time.

The main concern is certainly "Preferred" addresses. However, the issue
of lagging addresses is related.

> more than a day for prefixes that are obtained using DHCP-PD.

In principle, I guess that as long as you cap the "Valid" and
"Preferred" lifetimes when you announce such prefixes on the LAN side
according to the lease time, you are kind of "okish".

Anyway: do you suggest that we split the "book-keeping stuff" (i.e.,
affecting the Valid Lifetime) into a separate section?

> the host to wait multiple RA intervals to make sure the router really doesn't

What we do in the I-D is equivalent, so to speak: if you do hear RAs
from the router, but the prefix is not advertised, and a different
prefix is, then that's a clear indication that the router has ceased to
advertise the original prefix.

Just waiting for RA intervals (without checking anything else) might
mean the RAs were simply lost, whereas receiving RAs with PIOs that
don't include the previous prefixes is an indication that RAs are
getting through, but the previous prefixes are not advertised anymore...

> What happens if a router would advertise 4 prefixes in 4 separate RAs?

The addresses would oscillate between Preferred <-> non-preferred:

    Router                                           Host
          RA, PIO={2001:DB8:1::/64, L=1, A=1}
        -------------------------------------->
                                                [Host configures addrs
                                                  for this prefix]

                           .
                           .

          RA, PIO={2001:DB8:2::/64, L=1, A=1}
        -------------------------------------->
                                                  deprecate=TRUE

          RA, PIO={2001:DB8:3::/64, L=1, A=1}
        -------------------------------------->
                                                  Pref. Lftime=0
                                                  deprecate=FALSE

          RA, PIO={2001:DB8:4::/64, L=1, A=1}
        -------------------------------------->
                                                  deprecate=TRUE

          RA, PIO={2001:DB8:1::/64, L=1, A=1}
        -------------------------------------->
                                                  Valid and Preferred
                                                  timers are reset
                                                  deprecate=FALSE

The address would only get removed if you advertise five different
prefixes over five different RAs. I haven't seen any router
implementation that is so broken, though -- All I've encountered follow
the practice of "put as much info into each RA as possible".

That said, I wouldn't mind providing alternative mechanisms for
un-preferring and removing the addresses that involve timers. We went
ahead with a mechanism like the one we documented because it makes sense
engineering-wise: it's simple, encompasses realistic scenarios, and
avoid timers.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 01:29:23 -0300

> The simple solution to this problem is “if it hurts, stop doing it”.

FWIW, lifetimes are mostly irrelevant to the problem that *we* are
discussing (which is rather orthogonal to the problem mentioned above):
our case is that in which the router just reboots -- so no matter what
the lifetime was, the information will be invalid anyway.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 02:17:50 -0300

On 1/2/19 16:02, Mikael Abrahamsson wrote:
> I had a real life example today. I have OpenWrt 18.06.1 HGW. This
> morning, I lost Internet access. After diagnosing I realised that WAN
> was not working correctly, so I did "ifdown wan" and "ifdown wan6",
> switched to my secondary provider (which I was still on contract with
> but don't normally use) and then did "ifup" on both. I received new IPv4
> GUA and IPv6 GUA PD /56, which was then announced on my br-lan. I then
> ran on that for 3-4 hours until my regular provider had fixed their
> hardware problem. Then I did the whole ifddown procedure, swapped WAN
> cable to normal ISP, and did ifup again.
> 
> LAN device so I was a bit worried this would cause long-time problems,
> but the prefixes were deprecated and I couldn't find any actual issues
> (source address selection worked properly). A few hours later all these
> addresses were gone even from my purely wired devices that hadn't seen
> any link down/up events.
> 

This is a different problem scenario: the router is in an easy position
to clean up after itself, whereas in the case of crash-and-reboot most
aren't (since most don't record the prefix they were advertising).

> OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so
> I would propose to investigate further what hosts today actually do in

What do you mean by "RFC7084 signaling"?

Thanks!

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Sun, 3 Feb 2019 11:32:49 +0100

> On 3 Feb 2019, at 05:29, Fernando Gont <[email-masked]> wrote:
> 

That’s not how SLAAC and PD are designed. Lifetimes are not invalid just because of a router reboot. Look at advertised lifetimes as a sort of contract. 

What you seem to be talking about is either a bug a misconfiguration or both. 

With that established, you are arguing that hosts/applications should behave better in the case of this misconfiguration?

If you want something like session survivability,
that’s not a trivial problem to solve.

Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so.

Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. 

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 3 Feb 2019 11:54:35 +0100 (CET)

> What do you mean by "RFC7084 signaling"?

Sending RAs with PIOs with zero lifetime.

>From my testing so far they do the right thing and stop using addresses 
from within those PIOs including if they're IA_NAs with a week lifetime, 
but I think it might be good if someone investigated current situation.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 08:49:43 -0300

> That’s not how SLAAC and PD are designed. Lifetimes are not invalid just because of a router reboot. Look at advertised lifetimes as a sort of contract. 

Well, the problem is that you are making a contract on the LAN side for
a contract you may not have on the WAN side. If the router reboots and
the CEP no longer "owns" some prefix, then that contract is void.
Ideally, the CPE will advertise that the contract is void. But it is
clear that for most deployed CPEs, that will not happen.

> What you seem to be talking about is either a bug a misconfiguration or both. 

It's neither of those. If anything, it's the result of
under-specification of the necessary glue between automatic
configuration on the WAN side, and automatic configuration on the LAN side.

e.g., there were no requirements for CPEs to keep track of prefixes that
they have been leased in the past -- if at all possible.

> With that established, you are arguing that hosts/applications should behave better in the case of this misconfiguration?

They should behave better in scenarios where the CPE may have rebooted
and lost state of previously leased prefixes, which may have thus become
invalid.

> that’s not a trivial problem to solve.

Not sure what you mean by "session survivability".

> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so.

Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes?

Answer: Nowhere. They don't get to do that. All ICMPv6 error messages
are soft errors. And it would be a huge mistake (and huge
vulnerability!) to behave otherwise.

> Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. 

Not sure what you mean. If the same router that advertised those
prefixes doesn't advertise those prefixes anymore, why would you think
they are still valid?

---

From: Ole Troan <[email-masked]>
Date: Sun, 3 Feb 2019 13:27:31 +0100

> On 3 Feb 2019, at 12:49, Fernando Gont <[email-masked]> wrote:
> 

You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020.
A reboot doesn’t change that. 

> clear that for most deployed CPEs, that will not happen.

So a bug. 
What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. 

> they have been leased in the past -- if at all possible.

DHCP PD will give you the old prefix back. 

> and lost state of previously leased prefixes, which may have thus become

It’s not the CPE reboot that’s the problem. It’s the ISP breaking the contract and using the opportunity to flash renumber the user. 

> Not sure what you mean by "session survivability"

Try to keep a TCP session active while changing addresses. 

> vulnerability!) to behave otherwise.

It’s a strong hint to the host stack to pick a different source address. 

> prefixes doesn't advertise those prefixes anymore, why would you think

Because that’s what the network previously advertised. 
If source addresses from that prefix no longer works that’s a good hint to the host to try something else. There’s a list of heuristics the host must use. 

I still don’t see how your draft improves much on this. Can you explain?

Ole

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 12:00:27 -0300

> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. 

The CPE is the middle-man between the ISP and the LAN. No matter what
you may *expect* the CPE to do, the CPE is currently not actually
required to e.g. clean after the contract that the ISP broke (if you
assume/think there's such a thing), or even adjust prefix timers
according to the DHCPv6 lease times -- talk about under-specification of
the glue between e.g. DHCPv6-PD and SLAAC.

Besides, the layer-8 contract between the user and the ISP may be that
you get dynamic prefixes. This means that whenever you request a lease,
you get a different prefix. You might say that if you don't do another
DHCPv6-PD request, you should be able to use the same prefix. But if you
do ask a new prefix, you might indeed get a new one -- and this is what
normally happens after reboots.

The CPE should -- if possible -- be faithful to its LAN hosts, and
advertise if previous contracts between the CPE and the LAN hosts are
void. i.e., if the CPE does  not get leased the same prefix as before,
it shoudl notifiy its "clients". However, possibly for simplicity sake,
CPEs don't record what
information was previously advertised on the LAN -- they are not
required, so.... when they reboot, they may not not be in a position to
notify hosts accordingly.

That's the environment hosts operate in -- no matter whether you or me
like it.

In that environment, hosts can and should be smarter.

> DHCP PD will give you the old prefix back. 

Not necessarily. In fact, it may intentionally not do that. If you no
longer own the addresses, the sessions will have to be torn down.

> Try to keep a TCP session active while changing addresses. 

Of course that's not what we're trying to solve here.

> It’s a strong hint to the host stack to pick a different source address. 

You said "deprecate the invalid prefix if it has information to do so."
-- selecting a different address is a very different thing than
deprecating an address. In fact, for connection-less protocols that
might not even make sense -- since it implies resending stuff that you
might not even be able to resend (send buffer is gone).

Besides,

* You are assuming somebody will send an ICMPs. But they may not.

* You are assuming that if they do, they will send code 5. But they may not.

* You are assuming that code 5 is an indication of wrong address... but
it may be an indication of incorrect route.

* You are assuming that nodes will process icmp code 5 in one specific
way. I don't know of any implementation that behaves in the way you
describe.

> I still don’t see how your draft improves much on this. Can you explain?

What our document wants to address is this:

* Initially, unprefer addresses for the deprecated prefix.

* subsequently, clean up the lagging addresses.

One (more complex) way to achive this would be to e.g., wait for N *
ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at
least M RAs with PIOs have been received, but none of them contain PIOs
for the (now invalid) prefix, deprecate the prefix.

The solution we currently propose in the I-D is simpler, and just
involves one additional bit per prefix in the local data structures.

For a sample scenario, please check Appendix B of our draft. THe idea is
simple: if two consecutive RAs with PIOs don't contain the
previously-advertised prefix, un-prefer addresses for such prefix.
Subsequently, once addresses have already been un-preferred, if you
receive two additional RAs with PIOs that don't advertise the
previously-advertised prefix, remove (invalidate) the corresponding
addresses.

So, after two RAs, the lagging addresses are not preferred anymore.
After four RAs, you get rid of them.

---

From: Ole Troan <[email-masked]>
Date: Sun, 3 Feb 2019 16:26:08 +0100

> the glue between e.g. DHCPv6-PD and SLAAC.

RFC3633:
   Each prefix has an associated valid and preferred lifetime, which
   constitutes an agreement about the length of time over which the
   requesting router is allowed to use the prefix.  A requesting router
   can request an extension of the lifetimes on a delegated prefix and
   is required to terminate the use of a delegated prefix if the valid
   lifetime of the prefix expires.

This really isn’t hard.

> normally happens after reboots.

Not normally. That’s ISP allocation policy.
And not recommended.
But sure a correctly behaving DHCP PD implementation will include the current prefixes in it’s request message.

> In that environment, hosts can and should be smarter.

Sure. Hosts should always be smarter.
That doesn’t mean an addressing policy which breaks connections are not broken.

> longer own the addresses, the sessions will have to be torn down.

That’s not how IPv6 addressing and renumbering is intended to work.
I take it your goal isn’t to change that, but to improve the situation where it unfortunately happens.
(Which of course might encourage ISPs to do just that.)

> Of course that's not what we're trying to solve here.

No, but it is important to understand the implications of your work.

> might not even be able to resend (send buffer is gone).

No, I didn’t say that.
I said the network will deprecate the prefix if it has information to do. I.e. send a PIO with preferred lifetime = 0.
And that the network will respond with a type 5 destination unreachable, if an invalid source address is used. See BCP38.

> * You are assuming somebody will send an ICMPs. But they may not.

Is it interesting discussion assumptions that aren’t part of the specifications?

> * You are assuming that if they do, they will send code 5. But they may not.

See above.

> it may be an indication of incorrect route.

No.

> way. I don't know of any implementation that behaves in the way you

Hosts can improve.
My point was that it isn’t obivous that very much more can be done from the network side.

> After four RAs, you get rid of them.

So the proposal is that an address is marked as not preferred after anywhere between 6 and 20 minutes?

I am not saying that we can’t and shouldn’t improve on SLAAC… but I think we can do better. And existing heuristics are better than this.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 13:01:14 -0300

>    lifetime of the prefix expires.

It's not hard. But it just doesn't happen in crash-and-reboot scenarios
for most CPEs nowadays.

> Not normally. That’s ISP allocation policy.

The RIPE document does not recommend it. In Germany, that's the expected
default.

At the end of the day, it's a policy.

> But sure a correctly behaving DHCP PD implementation will include the current prefixes in it’s request message.

But they may just not know what they were (unless the previously-leased
prefix was recorded on stable storage). Or the DHCPv6 server might lease
something else.

> I take it your goal isn’t to change that, but to improve the situation where it unfortunately happens.

Exactly. We are trying to improve the situation when that happens. If
possible, we'd like the situation to be avoided -- e.g., if you want
dynamic prefixes, do so in an ordered way.

But since we cannot rely on others behaving nicely, we want to make
hosts more robust to these scenarios.

> No, but it is important to understand the implications of your work.

Not sure what you mean. You mean the goal its not clearly stated?
Something else?

> I said the network will deprecate the prefix if it has information to do. I.e. send a PIO with preferred lifetime = 0.

Who would be sending that, and in response to what?

> And that the network will respond with a type 5 destination unreachable, if an invalid source address is used. See BCP38.

Again: does this happen *in practice*?

Besides:
fgont@laptop:~$ curl -s https://tools.ietf.org/rfc/bcp/bcp38.txt | grep
-P '(icmp|ICMP)'
   Similar attacks have been attempted using UDP and ICMP flooding.
   domain to reach their systems. The latter attack (ICMP flooding),

>> it may be an indication of incorrect route.

If the address failed ingress/egress policy you may have picked the
wrong address or e.g. default route.

> My point was that it isn’t obivous that very much more can be done from the network side.

CPEs can be required to advertise previously-advertised prefixes that
are not valid anymore. And hosts can be improved so that they can detect
that a prefix is no longer advertised, and hence shouldn't be used --
or, at the very least, should no longer be preferred.

> So the proposal is that an address is marked as not preferred after anywhere between 6 and 20 minutes?

No. It is marked as not preferred in less than one minute (RFC4861):

   For the first few advertisements (up to
   MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it
   becomes an advertising interface, if the randomly chosen interval is
   greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set
   to MAX_INITIAL_RTR_ADVERT_INTERVAL instead.  Using a smaller interval
   for the initial advertisements increases the likelihood of a router
   being discovered quickly when it first becomes available, in the
   presence of possible packet loss.

> I am not saying that we can’t and shouldn’t improve on SLAAC… but I think we can do better. And existing heuristics are better than this.

What are the existing heuristics? If there was such a thing, there
shouldn't be a problem in the first place.

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Feb 2019 03:49:49 +1100

> normally happens after reboots.

That's against the architecture and design of the Internet protocols.

A router reboot, anywhere along the path between communicating
end-points, is supposed to have no more effect than a transient period
of packet loss. Recovery is supposed to be via transport layer
retransmission within the existing established connections.

A first hop CPE rebooting and being given a different PD prefix is
effectively changing a transient packet loss event into the movement
of the CPE and its hosts to a different point of attachment to the
network. That's the significance of what the ISP is imposing on their
customers by having dynamic/unstable PD prefixes. It probably seems
less significant than it really is because the links to the customers
are virtual, e.g. PPPoE, rather than physical.

> In that environment, hosts can and should be smarter.

Multipath transport layer protocols for the win. They're splitting
identifier semantics off from IP addresses.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 3 Feb 2019 18:14:47 +0100 (CET)

On Mon, 4 Feb 2019, Mark Smith wrote:

> effectively changing a transient packet loss event into the movement of

What about if it decides to choose a different /64 out of that /56? Do we 
cover this in any documents? The result to end systems is the same 
regardless if it's different /64 out of the /56 or if it's different /56.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 14:03:38 -0300

On 3/2/19 13:49, Mark Smith wrote:
[....]
> retransmission within the existing established connections.

If you change the addresses, all bets are off. Getting a different
prefix might mean, in theory, that you¡re attached to a different point
of the network topology.

In any case, the debate here is how to improve things when such
scenarios do happen.

> identifier semantics off from IP addresses.

That's mostly irrelevant -- because the thing here is to get rid of the
invalid addresses which tends to be benefical for anything running on IP.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 14:39:55 -0300

On 3/2/19 14:14, Mikael Abrahamsson wrote:
> What about if it decides to choose a different /64 out of that /56? Do
> we cover this in any documents? The result to end systems is the same

Agreed. In that case, if it is able to detect that the advertised prefix
has changed, you might *expect* that it also advertises the original one
with appropriate lifetimes. However, that implies that the prefix had
been recorded in stable storage.

And it all goes back to the same place:

* expectations != requirements
* Robustness has a lot to do with dealing with entities that might not
behave nicely

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 03 Feb 2019 18:46:11 +0100

---->  This is not correct, in the context of another mailing list, a few day ago, some people (including people from Germany) confirmed that this is not true for Germany, neither there is any law or anything similar that requires dynamic prefixes.

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 3 Feb 2019 13:30:08 -0500

I have been trying to follow the discussion.  I think I have been able 
to reconstruct the problem being discussed.

If I understand correctly, we are talking about CPE behavior when the 
CPE receives IPv6 prefixes via DHCP-PD, and then advertises prefixes for 
hust using RA PIO.  The assumptions that I believe Fernando is making are:

1) The CPE Does not store its delegations across reboots.
2) The CPE crashes
3) The CPE requests a prefix from DHCP-PD
4) The CPE receives a different prefix than it received before.

An Fernando seems to be saying that this results in the CPE violating 
its "contract" with the hosts from earlier PIO information.

Given that if the CPE had stored the delegated prefix, it could have 
continued to use it, one could equally (and arguably with more 
justification) argue that the DHCP server violated its contract with the 
CPE when it did not return the still-valid prefix (with a correct 
lifetime).  After all, the server madea "contract" when it handed over 
the address.

Have I missed something in the "problem"?  Robustness is nice.  But 
let's not bend over backwards trying to fix a problem of multiple 
failures.

Yours,
Joel

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 3 Feb 2019 18:53:38 +0000

Joel M. Halpern wrote on 03/02/2019 18:30:
> let's not bend over backwards trying to fix a problem of multiple failures.

the issue is that when this happens, it causes a cascading failure 
situation which can only be fixed either by the end user manually 
prodding all the ipv6 interfaces on the network to refresh the prefix, 
or if the slaac prefix times out naturally across the home network.

If this doesn't happen, the end user experience is going to be that ipv6 
stops cat videos and I.M. apps from working properly.  After a quick 
call-out, the family tech-support dude will cheerily confirm that this 
can be fixed by disabling ipv6, as she/he fumes while rebooting every 
goddamned device on the network because granny moved the cable modem and 
that jiggled the cable, third time this week (YU NO WORK??!?!?).

Mikael pointed out a related problem that if the cpe is delegated a 
prefix via dhcp6-pd and splits this across multiple home networks, it 
needs to do this in a repeatable way so that even if the SP remembers 
what prefix it previously delegated, the CPE will divvy that up the same 
way it did before the reboot.

For whatever sets of underlying reasons, this is a real world problem, 
which indicates that between CPE vendors and provisioning system 
vendors, there are problems which lead to end user loss of service. The 
IETF may well be able to offer reasonable guidance here.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Feb 2019 14:01:24 -0500

Joel M. Halpern <[email-masked]> wrote:
    > justification) argue that the DHCP server violated its contract with
    > the CPE when it did not return the still-valid prefix (with a correct

I mostly agree with your analysis.

There are some additional situations that make this a bit murkier:
1) The CPE died and was replaced, reflashed, upgraded, etc.  After which,
   it could well have a different DHCP DUID and the DHCP server thinks this
   is a different customer/device.  This is hard to get wrong with PPPoE
   if one links the prefixes to the customer login (via radius or other).
   On cable it's easier to get wrong, particularly if the CPE failure results
   in the new one having a different ethernet address (ethernet randomization not
   always good or useful)

2) The ISP died and the user connected to a different ISP!
   The prefix is legitimately quite different.

3) The customer was moved to a different CMTS, with the result that really
   needs to be renumbered.  I think that ISPs can do this correctly by
   setting correct lifetimes and doing some /60 routing until the lease
   expires, but...

    > let's not bend over backwards trying to fix a problem of multiple

I think that the flash write issue is really not that big a deal.
It requires one write per renumber if done intelligently.  Perhaps one can
further enhance the heuristic to not bother if the lease time is less than a
few hours:  There are apparently jurisdictions where everyone gets renumbered
at 1am, but in those places the lifetimes should be very small.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Gert Doering <[email-masked]>
Date: Sun, 3 Feb 2019 20:05:19 +0100

Hi,

On Sun, Feb 03, 2019 at 06:53:38PM +0000, Nick Hilliard wrote:
> The IETF may well be able to offer reasonable guidance here.

But isn't much more fun to quarrel about semantics of some sentence in
a long-dead RFC instead?

Real world problems, experienced by real people out there, how uninteresting.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Feb 2019 08:41:28 +1300

> ---->  This is not correct, in the context of another mailing list, a few day ago, some people (including people from Germany) confirmed that this is not true for Germany, neither there is any law…

It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany.

Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "common problem" simply wasn't a problem.

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 03 Feb 2019 20:45:47 +0100

Agree. Just wanted to clarify that assertion, as I've heard it too many times.

AVM/Fritzbox, if I recall correctly is one of the very very very few vendors that write the prefix in the flash ...

Regards,
Jordi

-----Mensaje original-----
De: Brian E Carpenter <[email-masked]>
Fecha: domingo, 3 de febrero de 2019, 20:41
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

    
    
       Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 3 Feb 2019 21:02:40 +0100

> On 3 Feb 2019, at 20:45, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

And just to be clear. That’s of course not the only solution. Nor necessarily the right solution. 

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

---

From: Christian Huitema <[email-masked]>
Date: Sun, 3 Feb 2019 10:10:54 -1000

If the source address is allocated from a deprecated prefix, or an
unknown prefix, the router cannot forward the packet. The router should
send an ICMPv6 message, but from my quick reading of the RFC I could not
find a code that said "the destination is unreachable because you are
using a source address allocated from a deprecated prefix." The closest
would be "Code = 5, source address failed ingress/egress policy", but
that feels like an approximation.

An appropriate error code would help the source device might take some
corrective action, like for example solicit an RA and configure an
address with an up-to-date prefix. A specific connection might fail, but
by the time little Johnny tries again a new source address would be
available and the cat video will play fine. That seems a lot less
frustrating than calling ISP support...

-- Christian Huitema

---

From: Ole Troan <[email-masked]>
Date: Sun, 3 Feb 2019 21:19:15 +0100

Christian,

The router cannot in its RPF check determine the reason for the wrong source address. If its spoofed or a previously valid address. Therefore code 5. 

Ole

> On 3 Feb 2019, at 21:10, Christian Huitema <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Feb 2019 15:38:17 -0500

Nick Hilliard <[email-masked]> wrote:
    > what prefix it previously delegated, the CPE will divvy that up the
    > same way it did before the reboot.

openwrt gets this right.

    > IETF may well be able to offer reasonable guidance here.

I agree, and having a write up of the issues (as simple as you related them),
would be good, as it would give ISPs something to point at when CPE vendors
get it wrong.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Feb 2019 15:56:09 -0500

Ole Troan <[email-masked]> wrote:
    > The router cannot in its RPF check determine the reason for the wrong
    > source address. If its spoofed or a previously valid address. Therefore
    > code 5.

Right... if the router knew it was the previously valid address, then it
would know what it was, and could have sent a lifetime=0 deprecate out...

(did I follow you correctly?)

    >> unknown prefix, the router cannot forward the packet. The router
    >> should send an ICMPv6 message, but from my quick reading of the RFC I
    >> could not find a code that said "the destination is unreachable
    >> because you are using a source address allocated from a deprecated
    >> prefix." The closest would be "Code = 5, source address failed
    >> ingress/egress policy", but that feels like an approximation.
    >>
    >> address with an up-to-date prefix. A specific connection might fail,
    >> but by the time little Johnny tries again a new source address would
    >> be available and the cat video will play fine. That seems a lot less
    >>> On 2/3/2019 9:45 AM, JORDI PALET MARTINEZ wrote: Agree. Just wanted
    >>> to clarify that assertion, as I've heard it too many times.
    >>>
    >>> AVM/Fritzbox, if I recall correctly is one of the very very very few
    >>> vendors that write the prefix in the flash ...
    >>>
    >>> Regards, Jordi
    >>>
    >>>
    >>>
    >>> -----Mensaje original----- De: Brian E Carpenter
    >>> <[email-masked]> Fecha: domingo, 3 de febrero de 2019,
    >>> 20:41 Para: JORDI PALET MARTINEZ <[email-masked]> CC:
    >>> "[email-masked] WG" <[email-masked]>, 6man WG <[email-masked]> Asunto:
    >>> Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
    >>>
    >>>> On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: The RIPE document
    >>>> does not recommend it. In Germany, that's the expected default.
    >>>>
    ----> This is not correct, in the context of another mailing list, a few
    ----> day ago, some people (including people from Germany) confirmed that
    ----> this is not true for Germany, neither there is any law or anything
    ----> similar that requires dynamic prefixes.
    >>>
    >>> It doesn't matter. The objective fact is that getting a new prefix
    >>> after a CPE reboot, or after a DSL disconnect/reconnect, or every 24
    >>> hours, is common, and not just in Germany.
    >>>
    >>> Not that I've ever had any stale address problems as a result, even
    >>> at a time when I was getting multiple ADSL disconnects per day due to
    >>> a line fault. So with a FritzBox and Windows hosts, the "common
    >>> problem" simply wasn't a problem.
    >>>
    >>> Brian
    >>>
    >>>
    >>>
    >>>
    >>> IPv4 is over Are you ready for the new Internet ?
    >>> http://www.theipv6company.com The IPv6 Company
    >>>
    >>> This electronic message contains information which may be privileged
    >>> or confidential. The information is intended to be for the exclusive
    >>> use of the individual(s) named above and further non-explicilty
    >>> authorized disclosure, copying, distribution or use of the contents
    >>> of this information, even if partially, including attached files, is
    >>> strictly prohibited and will be considered a criminal offense. If you
    >>> are not the intended recipient be aware that any disclosure, copying,
    >>> distribution or use of the contents of this information, even if
    >>> partially, including attached files, is strictly prohibited, will be
    >>> considered a criminal offense, so you must reply to the original
    >>> sender to inform about this communication and delete it.
    >>>
    >>>
    >>>
    >>> IETF IPv6 working group mailing list [email-masked] Administrative
    >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >> _______________________________________________ v6ops mailing list
    >> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: Ole Troan <[email-masked]>
Date: Sun, 3 Feb 2019 22:43:46 +0100

> (did I follow you correctly?)

Yes. Of course it might do both.

Cheers,
Ole

---

From: Christian Huitema <[email-masked]>
Date: Sun, 3 Feb 2019 14:07:50 -1000

> Yes. Of course it might do both.

OK. But then the host knows that it is not engaged in address spoofing, so it could decide to do something about it. That still would be better than calling support.

-- Christian Huitema

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Feb 2019 01:26:57 +0100

> On 4 Feb 2019, at 01:07, Christian Huitema <[email-masked]> wrote:
> 
> 

Well, this is caused by the ISP, so perhaps the call should be the recommended action. :-)

Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Feb 2019 11:51:42 +1100

> In any case, the debate here is how to improve things when such

So I think it is worth finding out exactly why ISPs are doing this, to
then work out what the best solution or solutions are.

Are they doing it

1. because they're used to giving residential IPv4 customers dynamic
addresses by default, so they've carried that practice over to IPv6
without realising there are different and avoidable consequences?

2. their employer charges a premium for static address assignment in
IPv4, and their employer assumes or expects, possibly implicitly, to
do the same with IPv6?

3. because PD privacy e.g. German example?

4. to suit occasional flash renumbering?

5. ???

In some of these cases, education may be a better, easier and quicker
solution in comparison to the years it'd take to deploy CPE behaviour
changes.

I put options in radvd that tried to mitigate this nearly 10 years ago
(DeprecatePrefix, DecrementLifetimes), as radvd was popular in IPv6
CPE I was working with at the time. Assuming radvd is still popularly
used, if those options haven't been widely enabled and are not well
known, then that might indicate an education and expectations problem.

Ultimately though, the residential ISP I worked for decided to give up
the specialness and price premium of static addresses and gives all
customers their own persistent stable PD prefix tied to PPPoE
username. I've had the same one at home for 7 years.

> invalid addresses which tends to be benefical for anything running on IP.

I don't think it is. Invalid addresses become far less of an issue
when a transport layer connection doesn't depend on a single address
at each end and that it is valid all of the time.

Regards,
Mark.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 4 Feb 2019 12:14:15 +1100

CPE’s need both stable prefixes and temporary prefixes.  We really should
just describe how to achieve both with PD as currently specified as it is
possible.  We also need to be able to tag prefixes as intentionally temporary
on the LAN side so node can preference those prefixes for temporary address
use over choosing a temporary address from an otherwise stable prefix.

ISP’s should be expecting CPE’s to request multiple prefixes with PD and
should return them.  The CPE keeps renewing the “stable” prefix, the temporary
prefix gets rolled to a new prefix periodically by the CPE with overlap between
the old and new prefix.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Feb 2019 12:16:25 +1100

> regardless if it's different /64 out of the /56 or if it's different /56.

Are there ones doing that? The effect would be the same. Hosts are
effectively having their network location changed because the only valid
available prefix(es) is/are new one(s).

I'm doing a well overdue (on my part) review of rfc4941bis. Privacy
addresses are in some regards effectively doing this too, because
applications' transport layer connections cannot persist longer than the
privacy addresses' valid lifetime.

The difference is that privacy addresses are expected to have a minimum
valid lifetime that is larger than the longest expected transport layer
connection duration that uses a privacy address.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 20:44:28 -0300

> 4) The CPE receives a different prefix than it received before.

Yes. Or any variation of this that leads to the same behaviour -- e.g.,
the CPE does not cap the prefix lifetime according to the DHCPv6 lease,
and only sends one RA with PIO lifetime=0 at the time a new prefix is
leased -- but that RA is lost and not received by some nodes.

> its "contract" with the hosts from earlier PIO information.

Well, the CPE cannot respect the contract in somehow it does not get
leased the same prefix, and it failed to cap the prefix lifetimes
accordingly, wither.

> lifetime).  After all, the server madea "contract" when it handed over

As far as the DHCPv6 server is concerned, I guess the argument could be:
you got a different prefix because you asked for a new leased. Had you
not asked a new lease, you could have continued using the previous one
-- but you just didn't know about it, because you didn't record it on
stable storage.

> let's not bend over backwards trying to fix a problem of multiple failures.

There are multiple reasons for which this may happen. THe interaction on
the WAN side and LAN side is largely unaddressed. So while we could
"expect" things from the CPEs that "would just make sense", we haven't
helped the situation by the lack of advice on how automatic
configuration on LAN and WAN sides are glued together. Some of those
devices  are part of the installed base, and are not going to go away
anytime soon.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 20:47:13 -0300

> It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany.

Exactly.

> Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "co…

FritzBox used to generate RAs that would disable the outdated prefixes
in response to packets with a source address that it didn't like. See:
http://blog.si6networks.com/2016/02/quiz-weird-ipv6-traffic-on-local-network.html

That may explain why you didn't have stale addresses :-)

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Feb 2019 20:51:07 -0300

> The router cannot in its RPF check determine the reason for the wrong source address. If its spoofed or a previously valid address. Therefore code 5. 

Before anybody proposes reactions to code 5, please remember that GTSM
is *not* enforced on ICMP errors, nor dor they ned to use any specific
source address. i.e., they are trivial to spoof, and make an obvious
attack vector unless simply considered "soft errors".

---

From: Christian Huitema <[email-masked]>
Date: Sun, 3 Feb 2019 19:44:13 -1000

> attack vector unless simply considered "soft errors".

Sure. But then, devices can the code 5 Dest Unreachable ICMP as a hint.
They could for example solicit an RA, and check what prefixes are
currently advertised. If they learn a new prefix, they might want to
configure an additional address.

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Feb 2019 17:57:49 +1100

> configure an additional address.

Possibly a prefix deprecating RA could be sent in parallel to the ICMP
message, rather than waiting for the host to solicit one. It could be
unicast, or probably more usefully multicast, rate limited.

The deprecated prefix length of the old prefix would need to be assumed,
probably quite accurately to be the common prefix length of the newer
prefixes on the interface, and likely /64.

A unicast deprecating RA with a /128 PIO that matches the source address is
an interesting idea, although probably wouldn't work, because I assume
there is prefix length checking upon lifetime updating when receiving PIOs.

Regards,
Mark.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 4 Feb 2019 08:29:41 +0100

* Brian E Carpenter

> Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "co…
If I recall correctly, the FritzBox I used to own would immediately send a few
RAs with PIO timers=0 after receiving a packet from the LAN with a source
address from a unknown prefix.

Thus it didn't have to worry about remembering the previous delegated prefixes
across a crash+reboot, as it would be reminded about it and get the opportunity
to invalidate it the second a host tried to use it.

That approach didn't work very well in networks with multiple routers, of
course...

This was 7-8 years ago, things might have changed since then.

Tore

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Feb 2019 01:07:25 -0300

> configure an additional address.

Isn't this a more complicated way of doing what we're proposing in our
document?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 12 Feb 2019 23:37:12 -0300

> Well, this is caused by the ISP, so perhaps the call should be the recommended action. :-)

Not necessarily. There is no requirement that the ISP leases the same
prefix if the client just asks a new prefix.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 19 Feb 2019 07:16:59 +1100

On Thu, Jan 31, 2019 at 11:12 PM Fernando Gont <[email-masked]> wrote:
> > When the new prefix is received it'll most likely have a higher
> > preferred and valid lifetime, so hosts should use the new prefix just by
> > means of them preferring the higher preferred lifetime of that PIO. So
> > the problem is a bit less than you write in the draft.
>
> Nothing in the spec says preference is related to the "Preferred
> Lifetime" timer. i.e., an address is preferred, or it is not...

I tried to address this problem before (and there are more use cases
than just CPE reboot):
https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

I might be biased here indeed but I think that using the "most
recently updated" (however we define that) address would be the
simpler solution than
deprecating the whole prefix (and both solution requires hosts to keep
the PIO <> advertising router mapping).

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Feb 2019 19:24:23 -0300

Hello, Jen,

> the PIO <> advertising router mapping).

Say the Stale prefix is 2001:Db8:1::/64, for which you configured
2001:db8:1::1.

Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix
2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1.

Say you now need to send packets to 2001:db8:1::/64.

You will use the new addresses (from 2001:db8:2::/64), but will send the
packets assuming nodes are "on-link", instead of sending them to the
default router.

 -- You do need to get rid of information, including routes, asap.

Similarly, if you have multiple interfaces, Rule 5 might override your
rule 8. Whether because you are sending to the stale prefix, or because
your first default-router was the one the happened to crash-and-reboot.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Feb 2019 06:59:56 +0100

> On 18 Feb 2019, at 23:24, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Jen,
> 

How is your case different from the multi-prefix multi-homed case where one path is (temporary) out of service?

Ole

---

From: Jen Linkova <[email-masked]>
Date: Tue, 19 Feb 2019 18:56:12 +1100

> packets assuming nodes are "on-link", instead of sending them to the

True. I'm not convinced that this use case is worth solving by
introducing the complexity (and impact on other scenarios)  the draft
is suggesting

What I'm not a big fun of is assuming that absence of evidence is
actually evidence of absence. When a router stops advertising a prefix
it does not necessary mean
that hosts shall stop using the addresses. It does indeed in the
scenario the draft describes but the host can not know the
topology/scenario.
The proposed host changes would solve  one particular case (DHCPv6-PD
router crash/reboot) while multiprefix/multihomed networks.

Lets say there are two routers (R1 and R2) on the LAN.
R1 advertised 2001:db8:1::/64 and 2001:db8:3::/64
R2 advertised 2001:db8::2::/64 and 2001:db8:3::/64.

Hosts have addresses from 3 prefixes.
Now R2 stops advertising 2001:db8:3::/64.

There is no reason for hosts to deprecate addresses in 2001:db8:3::/64.
What's going to happen is every time an RA from R1 is received, hosts
would get preferred addresses in 2001:db8:3::/64 and every RA from R2
would deprecate them.

I do believe that the default preferred lifetime is a bit longer that
it should be (and I have to tweak it all the time). So maybe we shall
change that.

> rule 8.

Sorry, I must be very slow today. Could you please elaborate on this
scenario?  I'm having difficulties figuring it out..
The draft is talking about deprecating prefixes on *another*
interface? I hope not..

Actually I've just realized that I could not find any clear definition
of what 'the same router' means. The same address installed as
'next-hop'?
The same combination of IPv6 address and L2 address?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 00:59:37 -0300

> introducing the complexity (and impact on other scenarios)  the draft

Could you elaborate on what's the complexity you are referring to and
what's the impact on other scenarios?  Having multiples addresses from
multiples prefixes is complex.

> that hosts shall stop using the addresses.

This is not the way the proposed algorithm work.

I'd agree with you that if you stopped receiving RAs, *that* wouldn't
necessarily warrant a prompt reaction.

However, the proposed algorithm reacts to *RAs from the same router*
(i.e. the router *is alive*) that do carry PIOs, but they happen to
advertise PIOs for different prefixes.

Once you receive four RAs with PIOs from the same router, all of them
including PIOs, but failing to advertise the stale prefix, you remove
the addresses.

> It does indeed in the

That's not correct. It takes two consecutive RAs for the prefixe to be
unpreferred. And another two consecutive RAs for the prefix to be
removed. In the scenario you describe, R1 would keep advertising the
prefix, and hence it would never be unpreferred or removed.

There's room for improvement and clarification, though: one may clarify
that. You might think of this problem as havinf a reference count on the
prefix. If there's only one router associated with the prefix, un-prefer
and remove the prefix. Otherwise, just dis-associate the prefix with
this particular router.

> it should be (and I have to tweak it all the time). So maybe we shall

Same applies to the Valid Lifetime. In the context of RFC8028 it doesn't
make sense for the Valid Lifetime of a prefix to span past the Router
Lifetime of a router.

> scenario?  I'm having difficulties figuring it out..

Example:

Say you have two network interfaces: If1 and If2.
Say If1, is configured with 2001:db8:1::/64, and If2 with 2001:db8:2::/64

Say the first default router is that associated with If1.

Say prefix 2001:db8:1::/64 stops being announced, or that you stop
receiving RAs on If1, but RAs on If2 keep arriving fine.

Based on the logic of your algorithm, one would expect that a new
connection uses 2001:db8:2::/64/If2 (since that's the "more recently
advertised information). However, Rule #5 would override that and make
you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on
the outgoing interface.

So as long as you have stale routes, in many cases that will override
any other rules for address selection. -- i.e., if your new rule for
RFC6724 comes after rule 5, you better get rid of stale routes, or
otherwise they will override you well-intended rule.

> The draft is talking about deprecating prefixes on *another*

Certainly not.

> The same combination of IPv6 address and L2 address?

My mental model (as long as this algorithm is concerned) is that the
router is uniquely identified by the (link-local) IPv6 address (the
combination of IPv6 and L2 would work, too, but it seems unnecessary).

We'll spell it out in the next rev.

Thanks!

Cheers,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Feb 2019 23:31:21 -0500

I was trying to think through what breaks if you do the below.
The one case I can see is if there is an open TCP connection using the 
prefix to be dropped.  If that TCP connection appears to be working, 
then dropping the prefix would seem harmful.  It would also seem that if 
the TCP connection is working that would be evidence that there is no 
need to drop the prefix.

Yours,
Joel

On 2/19/19 10:59 PM, Fernando Gont wrote:
,,,
> including PIOs, but failing to advertise the stale prefix, you remove
,,,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 01:52:32 -0300

> the TCP connection is working that would be evidence that there is no

That's of course correct. Now: can you think of a scenario where that
might occur? -- no routers are advertising the prefix anymore. Any new
nodes joining the network will not consider the corresponding prefix to
be on-link, will not configure prefixes for such address, etc.

That said, the above might make the removal of the address debatable,
but not the marking of the corresponding addresses as un-preferred, right?

---

From: Jen Linkova <[email-masked]>
Date: Wed, 20 Feb 2019 20:36:22 +1100

> and remove the prefix. Otherwise, just dis-associate the prefix with

yeah, see another email I've just sent ;)

> make sense for the Valid Lifetime of a prefix to span past the Router

Well, my ISP sent me a CPE which is configured to send RAs with router
lifetime of 30 seconds or smth (I sent it back so can not verify
anymore ;))
I would object if I can not listen to the music (which is stored at
the machine in the network) because my Internet connection goes down
(as it's been doing 5 times/day recently ;)

> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on

I'm even more confused now, sorry ;((

Both your draft and my draft talk about cases when *the given
interface* has addresses from the different prefixes and it would be
nice to make sure the host selects the correct one.
So in the case described above:
Time t0:
if1: has addresses from 2001:db8:1::/64, the default route -> if1
if2: has addresses from 2001:db8:2::/64

Time t1
an RA received on if1 containing PIO for 2001:db8:3::/64 (no PIO for
2001:db8:1::/64)

Time t2
if1: has addresses from 2001:db8:1::/64, 2001:db8:3::/64 the default
route -> if1. An RA received
if2: has addresses from 2001:db8:2::/64

Time t3:
the host is trying to send an IPv6 packet off-link.
It selects if1 and now needs to select one of addresses on the
outgoing interfaces. My algorithm suggests that address(es) from
2001:db8:3::/64
should be preferred as they are "freshest" ones. The same outcome as
deprecating  2001:db8:1::/64

> otherwise they will override you well-intended rule.

If the only routes are default routes  it does not matter, right?

> > The draft is talking about deprecating prefixes on *another*

It would be nice to make it clear IMHO...

---

From: Richard Patterson <[email-masked]>
Date: Wed, 20 Feb 2019 10:51:09 +0000

> (as it's been doing 5 times/day recently ;)

That's what having a stable ULA prefix is useful for!

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Feb 2019 11:08:50 +0000

> That's what having a stable ULA prefix is useful for!

Add some NAT on the CPE and this entire problem goes away!

Nick

---

From: Richard Patterson <[email-masked]>
Date: Wed, 20 Feb 2019 11:21:24 +0000

> Add some NAT on the CPE and this entire problem goes away!

Now why didn't I think of that? :)

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Feb 2019 12:22:56 +0100

Hi,

> Add some NAT on the CPE and this entire problem goes away!

NATs are good!

(Seriously, given what a train wreck IPv6 seems to become, NPT and
ULAs or IPv6 PI inside is increasingly looking more attractive...)

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Feb 2019 20:24:51 +0900

What a sacrilege!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Gert Doering <[email-masked]>
Fecha: miércoles, 20 de febrero de 2019, 20:23
Para: Nick Hilliard <[email-masked]>
CC: Fernando Gont <[email-masked]>, IPv6 Operations <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

    Hi,

    NATs are good!

    Gert Doering
            -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Feb 2019 20:26:08 +0900

Ok, so let's go for IPv6 PI for every household, business, etc. ...

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Gert Doering <[email-masked]>
Fecha: miércoles, 20 de febrero de 2019, 20:23
Para: Nick Hilliard <[email-masked]>
CC: Fernando Gont <[email-masked]>, IPv6 Operations <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

    Hi,

    NATs are good!

    Gert Doering
            -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Feb 2019 12:36:03 +0100

Hi,

> What a sacrilege!

There's so much wrong with current IPv6 standards and implementations
and processes that "just go with NPT" would save a lot of pain.

I'm no longer holding by breath for *useful* SoHo implementations
(like, full homenet multi-router / multi-homing support, with proper
firewalling, etc.) or useful client application behaviour.

> Ok, so let's go for IPv6 PI for every household, business, etc. ...

The PI part was more about "guaranteed uniqueness", which is important
for enterprise interconnections.  ULA-C would have nicely solved this
as well, but since we do not have it, ULA-L for "I have nothing in my
home which someone wants to reach over VPN" and PI for "VPN access
should be possible without address collisions".

OTOH, many large-enterprise VPNs use NAT today to work around the
duplicate-address problem, so whatever.  Just add NAT there.

(Quoting in the same style as everyone else does in this conversation
would be just so slightly more polite than blowing out two one-line-
full-quote mails in a properly quoted discussions.  Just sayin)

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Wed, 20 Feb 2019 13:02:45 +0100 (CET)

> and processes that "just go with NPT" would save a lot of pain.

Would you be interesting in making a list of what you think is wrong?
(I'm not disagreeing, I'm just curious...)

Steinar Haug, AS2116

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Feb 2019 15:42:22 +0100

Hi,

> (I'm not disagreeing, I'm just curious...)

Oh, that list will be long, so doing it in a useful way will take some
time.  Just a quick list of things that come to my mind right away

There's "protocol inherent" issues that turn out to be amazingly stupid
in retrospective

 - using IPv6 for ND/NA
    - "you cannot attack something from remote which is not IP"
    - usiing a mix of local and global addresses for ND/NA source/dest
      (so filtering "only accept those ND/NA packets that can correctly
      happen on *this link* and drop all else" is fairly tedious)

 - using multicast for core functionality
    - little benefit compared to broadcast in today's networks
    - lots of extra complexity in network drivers, switch forwarding planes,
      Wifi, ...
      -> lots of bugs and problems

 - replicating the ARP model of "neighbor solicitation when a packet comes
   in" instead of trying something akin to LANE, where you just register
   with "someone" who knows all the L2/L3 mappings for a given LAN segment
   on connection, and nobody has to probe -> "scan /64, exhaust ND" attacks
   totally defused

 - unbound chain of extention headers 

 - carrying link-local next-hop addresses in IPv6 BGP sessions that are
   connecting peers on the same LAN using their GUAs (so at least one
   major vendor installs a next-hop in the FIB that is different from 
   the BGP peer it is talking to - combine that with ND bugs galore, and
   you get blackholing due to LLA next-hop unreachability, while BGP
   thinks "all is good")

Then, there's market and IETF process fails

 - homenet protocol suite - this is something that could have been 
   insanely great, with "just plug in a second ISP into your home
   network, all machines understand that they have two options for
   'connect to the Internet' now, and users have full control"

   IETF process fail: stall this by haggling two years over "what sort
   of routing protocols should we have in the homenet protocol suite?
   we must have negotiations! options! flexibility!"

   market fail: CPEs have their implementations done.  Nobody (but OpenWRT)
   seems to be working on homenet implementations.

   double market fail: ISPs have no interest in requesting this from 
   their vendors (so, IETF fail again, because that way it never made it
   into the CPE requirements list...) - because it would empower their
   customers to more easily switch ISPs, while they would have to pay
   the development costs.

 - source address *failover* in case a machine has multiple source 
   addresses and one of them is broken.  We have happy eyeballs for 
   "multiple destinations", but as far as I'm aware (maybe I have 
   missed something) still no "we might want to probe multiple sources
   if the preferred best source seems to be non-working".  

   Actually this thread is fixing one of scenarios when this can happen
   (because your router went belly-up), but there's "you have two /64
   from two ISPs on your LAN, with two routers happily announcing their
   RAs, but one of them just cannot reach your preferred destination due
   to external breakage" - in which case you want to try the other source.

 - the whole "multiple /48 multihoming" debacle - combined with homenet, 
   this is a really great idea for SoHo environments, especially if you
   combine it with application smartness, so you can tell your web
   browser "I want to surf via MyCableNet now!" while your torrent client
   is filling YourDSL.ISP link...

   Instead of having nice things, what we *do* get is RFCs that explain
   "if your primary ISP goes belly-up, withdraw primary RA, send RA for
   secondary ISP"...  (sorry, Jen, but I think this is a bandaid for a
   much more fundamental flaw).

 - Firewalls on home routers - so, what do I need global IPv6 addresses
   in my home network if IETF keeps telling people "you better should not
   have these addresses reachable from the world!! because, security!!!"?

   Combined with "CPE market fails" I can now have native IPv6 at home
   (great), combined with a CPE that has severe limitations on what can
   be permitted in its ACL handling.  Well, after some 5 years, AVM *did*
   manage to permit IPv6 traffic to DHCPv6-PD-delegated prefixes, but 
   this is still unsatisfactory.

 - did I mention CPEs?  Like, AVM, which claims that there is no way
   to transport IPv4 over an IPv6-transported VPN, so their CPEs will not
   implement VPN over IPv6.  Great combination if you're sitting behind
   a ds-lite ISP and have no public v4 address at all...

   (bashing AVM is actually somewhat unfair, since most other CPE vendors
   are 10 years behind)

 - did I mention VPNs?  Like, Fortinet, who do support VPN over IPv6, and
   IPv6 over VPN.  And VPN over IPv4, and IPv4 over VPN.  But they do not
   support "IPv4 payload over IPv6 VPN", because, "where is the business
   case for that?" - like "I'm sitting behind a carrier-grade NAT IPv4 
   at home, but I have proper IPv6, and I want to reach my IPv4-only
   backend servers in the datacenter over your VPN"...

 - I *did* mention the dual-stack IPv6 socket API, did I, with lots of
   extra code paths everywhere and the amount of bugs this introduces?
   (in retrospective I can only applaud OpenBSD for refusing to implement
   it - I did not understand it back then, "because it is so much more
   convenient!", but I was wrong)

 - another market fail: 3GPP mandates IPv6 for UMTS.  3 out of 4 mobile
   ISPs in DE do not offer IPv6 at all... (nowadays it's no longer "3"
   since Telefonica bought E-Plus, but when 3G was rolled out, none of
   the 3 had any interest in v6...)

 - and of course, having to deploy IPv4 in 2019, because "The Internet"
   took over 20 years to not-deploy IPv6 widely enough that we could 
   finally start shutting down IPv4...  instead we have haggling and
   arguments galore over the last scraps of IPv4...

So, that was the unsorted "things that came to my mind" list - it might
be factually not correct if I missed interesting new developments, and
it might be unfair to people that had the best of intentions, but this
is where we are: in an annoying mess of half-done half-working things.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Feb 2019 16:03:11 +0100

Hi,

> Then, there's market and IETF process fails

Ooooh, I totally forgot the "RA vs. DHCPv6" train wreck.

Gert Doering
        -- NetMaster

---

From: j h woodyatt <[email-masked]>
Date: Wed, 20 Feb 2019 09:09:24 -0800

On Jan 31, 2019, at 03:00, Fernando Gont <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum

For the record, I agree with the authors that reducing the default values for AdvPreferredLifetime and AdvValidLifetime is an idea with merit.

The other changes seem less obviously good, as they resemble previous unsuccessful attempts to hammer the DHCPv6 and Router Discovery protocols into resembling a proper routing protocol, which they are not, and which I think we should admit they never will be. Having experienced the futility in attempting to improve Router Discovery and/or DHCPv6 to resemble a proper routing protocol, I would say I’ve seen better and more elegant solutions to these problems, which unfortunately all depend on host operating systems adopting the model that hosts sometimes have cause to participate in the network routing protocol. As this idea has never been taken seriously by the community, I think it’s probably best to leave it behind.

Shorter james: keep section 5.1.1 and drop sections 5.1.2, 5.1.3, 5.2 and 5.3.

--james woodyatt <[email-masked]>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 20 Feb 2019 20:19:47 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Gert Doering

Wait, whether that's partially said in jest or not, NPT was invented primarily to add the 16-bit Port ID to the limited 32-bit address space of IPv4. But with IPv6, a "basic NAT" would not need to also do port translation. Plenty of addresses available. And it would make addresses behind the NAT as stable as anyone could want. Just a 1:1 mapping, with the WAN addresses.

Doesn't that take away most of the pain, maybe all of the pain? And solve this problem?

(Sometimes, to solve a vexing problem, you have to do a "paradigm shift.")

Bert

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Feb 2019 20:30:02 +0000

Manfredi (US), Albert E wrote on 20/02/2019 20:19:
> Wait, whether that's partially said in jest or not, NPT was invented
> primarily to add the 16-bit Port ID to the limited 32-bit address
> space of IPv4. But with IPv6, a "basic NAT" would not need to also do
> port translation. Plenty of addresses available. And it would make
> addresses behind the NAT as stable as anyone could want. Just a 1:1
> mapping, with the WAN addresses.
> 

it certainly does, at the cost of very little technical innovation and a
quantity of pain that most people are already familiar with and are
happy to accept - or even welcome in some situations due to the 
perception of security benefits.

Nick

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Feb 2019 22:31:07 +0100

Hi,

On Wed, Feb 20, 2019 at 08:19:47PM +0000, Manfredi (US), Albert E wrote:
> Wait, whether that's partially said in jest or not, NPT was invented primarily to add the 16-bit Port ID to the limited 32-bit address space of IPv4. But with IPv6, a "basic NAT" would not need to also do port translation. 

My "NPT" was intended to be an acronym for "Network Prefix Translation",
so yes, exactly this.  Keep ports, keep host part (if desired), just
translate prefix.  We even have an RFC for that :-)

But then, I'm not using IPv4 NAT @ home...

Gert Doering
        -- NetMaster

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 20 Feb 2019 22:16:36 +0000

-----Original Message-----
From: Gert Doering <[email-masked]> 

Right. So, why shouldn't this NAT66 idea be taken more seriously? All of the advantages of the basic NAT come to bear, including the renumbering problem in enterprises, including no changes required to SLAAC timers, and sessions easily survive a reboot of the edge router, and yet none of the port translation kludge that made NATs useful in IPv4.

And the solution can be introduced gradually. For homenets, for example, you let things default back to IPv4 as they seem to do today, until the user acquires the CPE with NAT66, or ntil the ISP finishes updating all of the subscriber households. From then on, "it just works." And IPv4 can be retired.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2019 12:18:33 +1300

On 2019-02-21 11:16, Manfredi (US), Albert E wrote:
> Right. So, why shouldn't this NAT66 idea be taken more seriously? 

NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains.

> All of the advantages of the basic NAT come to bear, 

I'm not sure that that is true, but NPTv6 brings some, but not all,
of the disadvantages of NAT too, as also explained in RFC6296. It
isn't needed for enterprise renumbering, and it isn't needed for
enterprise security. This is all very old news. I mean, 10 years
old at least.

NPTv6 as a work-around for a defect in SLAAC when there is an
unplanned renumbering? That's a very large hammer applied to quite
a small screw, IMNSHO. Fixing SLAAC seems like a more scientific
approach.

In the context of homenets and HNCP, NPTv6 is even more pointless.

   Brian

> including the renumbering problem in enterprises, including no changes required to SLAAC timers, and sessions easily survive a reboot of the edge router, and yet none of the port translation kludge that made NATs useful in IPv4.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Feb 2019 08:43:21 +0900

On Thu, Feb 21, 2019 at 7:17 AM Manfredi (US), Albert E <
[email-masked]> wrote:

> Right. So, why shouldn't this NAT66 idea be taken more seriously? All of
> the advantages of the basic NAT come to bear, including the renumbering
> problem in enterprises, including no changes required to SLAAC timers, and
> sessions easily survive a reboot of the edge router, and yet none of the
> port translation kludge that made NATs useful in IPv4.
>

Because the advantages are for network operators have corresponding
disadvantages for application developers and thus for users. Application
complexity and brittleness due to NAT traversal. Battery impact of NAT
keepalives. Higher-latency due to relaying and rendezvous. And so on.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 21:55:14 -0300

On 20/2/19 06:36, Jen Linkova wrote:
[...]
> I'm even more confused now, sorry ;((

I was referring to the fact that some of the previous rules might
prevent the evaluation of the rule about freshness. e.g.:

* You have two network interfaces eth0 and eth1 (say each connected to a
different ISP)
* eth0 has stopped receiving RAs
* eth1 receives RAs as usual (hence all info associated with this
  interface is "fresher" than than corresponding to eth0)
* The default router employed by eth0 has precedence (whether because it
  had a higher preference value, because it was the first one that was
  learned, or whatever)
* When you evaluate the rules in RFC6724, rule 5 will say that the
  outgoing interface will be eth0, and thus you should pick an address
  associated with it --- however, as noted above, the addresses on eth1
  are fresher than those from eth1.

Other cases might be if an interface has a stale ULA address one one
interface, and a fresh one on another. You might end up using the stale
ULA becase the rules about scope and "use addresses from the outgoing
interface" take precedence over the rule about freshness.

I do agree that these might be considered corner cases which might be
unimportant for scenarios where we only deal with GUAs, or at least only
GUAs become stale.

Note (that I forgot to mention in a previous email): Many
implementations limit the number of prefixes they may use for address
configuration. I seem to recall that some implementations limit them to
16. If you don't do "garbage collection" for the stale addresses (remove
stale addresses when there's some sort of indication that they are
stale), then you might end up in a scenario where stale addresses take
all the available "slots" for address configuration, and you don't have
room for configuring addresses for the fresh prefixes. With the default
Valid Lifetimes of 1 month, this is certainly a concern: if the prefix
changes 16 times in a month, without explicit signaling to remove the
stale addresses, you might be unable to configure addresses for the
fresh prefixes.

Thanks,

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 21 Feb 2019 01:11:39 +0000

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 

> NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains.

Okay, NPTv6. No port translations. RFC 6296.

> I'm not sure that that is true, but NPTv6 brings some, but not all,
of the disadvantages of NAT too, as also explained in RFC6296.

Few of the disadvantages, I'd say. For example, use of IPsec AH is compromised. But many people objected to the mandatory use of IPsec in IPv6 already, because there are other ways of securing content that they prefer to deploy. I think that the wide deployment of NAPT in IPv4 has reduced the severity of the disadvantages of NPT, as application designers have long had to accommodate workarounds?

> NPTv6 as a work-around for a defect in SLAAC when there is an
unplanned renumbering?

I mentioned SLAAC timers as an example. What I should have said is, as far as I can tell, all of the problems we have been discussing in this thread would be solved with NPTv6. Privacy in home nets, renumbering, route aggregation, SLAAC, what else? I can't think of an issue mentioned here that NPTv6 wouldn’t solve.

It should not be all that surprising that the advantages of address independence have become entrenched in IP thinking, thanks to IPv4. So it should not be surprising if many have come to depend on these advantages, and don’t want to give them up.

Bert

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Feb 2019 17:12:01 -0800

>   are fresher than those from eth1.

Not receiving multicast RAs is not a condition you can really take any
action on.

PIO/RIO/default route/... timers expiring? Of course.

ND is_router goes from 1 to 0? Absolutely.

NUD says the router is gone? Most definitely.

Some kind of repeatedly beating on the router with unicast RSes... maybe...

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Feb 2019 17:17:27 -0800

On Wed, 20 Feb 2019 at 17:12, Manfredi (US), Albert E <
[email-masked]> wrote:

> Few of the disadvantages, I'd say. For example, use of IPsec AH is
> compromised. But many people objected to the mandatory use of IPsec in IPv6
> already, because there are other ways of securing content that they prefer
> to deploy. I think that the wide deployment of NAPT in IPv4 has reduced the
> severity of the disadvantages of NPT, as application designers have long
> had to accommodate workarounds?
>
> I mentioned SLAAC timers as an example. What I should have said is, as far
> as I can tell, all of the problems we have been discussing in this thread
> would be solved with NPTv6. Privacy in home nets, renumbering, route
> aggregation, SLAAC, what else? I can't think of an issue mentioned here
> that NPTv6 wouldn’t solve.
>
> It should not be all that surprising that the advantages of address
> independence have become entrenched in IP thinking, thanks to IPv4. So it
> should not be surprising if many have come to depend on these advantages,
> and don’t want to give them up.
>

As Lorenzo said, it "solves" some operational pain by pushing that pain
onto those that are not represented in the decision making process to
deploy any variety of NAT (i.e. apps, OSes, ...)

We've been here before <https://www.ietf.org/proceedings/74/6ai.html>, of
course.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 22:13:28 -0300

On 20/2/19 20:43, Lorenzo Colitti wrote:
> On Thu, Feb 21, 2019 at 7:17 AM Manfredi (US), Albert E
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     All of the advantages of the basic NAT come to bear, including the
>     renumbering problem in enterprises, including no changes required to
>     SLAAC timers, and sessions easily survive a reboot of the edge
>     router, and yet none of the port translation kludge that made NATs
>     useful in IPv4.
> 
> 

Given that RFC6092 recommends "only allow outgoing connections", and
that many IPv6 CPEs fail to implement UPnP for IPv6, I'm wondering that
what extent what you mention is actually true. (yes, we'd wish that was
the case... unfortunately, in many cases it isn't)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 22:40:44 -0300

Hi, James,

Thanks for thre great feedback! Comments in-line...

On 20/2/19 14:09, j h woodyatt wrote:
> For the record, I agree with the authors that reducing the default
> values for AdvPreferredLifetime and AdvValidLifetime is an idea with
> merit.
> 
> The other changes seem less obviously good, as they resemble previous
> unsuccessful attempts to hammer the DHCPv6 and Router Discovery
> protocols into resembling a proper routing protocol, which they are
> not, and which I think we should admit they never will be. Having
> experienced the futility in attempting to improve Router Discovery
> and/or DHCPv6 to resemble a proper routing protocol, I would say I’ve
> seen better and more elegant solutions to these problems, which
> unfortunately all depend on host operating systems adopting the model
> that hosts sometimes have cause to participate in the network routing
> protocol. As this idea has never been taken seriously by the
> community, I think it’s probably best to leave it behind.

Note: 5.1.3 allows for more timely recovery from the aforementioned
problem. (otherwise you'd have to wait longer, or reduce timers more
agressively)

5.1.2, 5.2, and 5.3 aims at network devices behaving nicely, possibly
allowing for timely recovery of hosts that don't implement 5.1.3.

> Shorter james: keep section 5.1.1 and drop sections 5.1.2, 5.1.3, 5.2

Seems folks wanted these bits about "how devices should play nice"...

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 22:44:12 -0300

Hi, Eric,

On 20/2/19 22:12, Erik Kline wrote:
> 
> 
> On Wed, 20 Feb 2019 at 17:07, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Agreed.

The main issue I see with incorporating an explicit rule in RFC6724
about "freshness" is that in multi-prefix scenarios, it's guaranteed
that the default SA will oscillate among the different prefixes, and
that if you only implement this workaround, you wouldn't be able to
communicate with hosts actively employing your stale prefix.

Thanks!

Cheers,

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Feb 2019 18:01:14 -0800

> communicate with hosts actively employing your stale prefix.

that's where rule 5.5 would help (wherever it is actually implemented;
alas...)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2019 15:22:07 +1300

On 2019-02-21 15:01, Erik Kline wrote:
> 
> 
> On Wed, 20 Feb 2019 at 17:49, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi, Eric,
> 
>     > On Wed, 20 Feb 2019 at 17:07, Fernando Gont <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     >> Example:
>     >     >>
>     >     >> Say you have two network interfaces: If1 and If2.
>     >     >> Say If1, is configured with 2001:db8:1::/64, and If2 with
>     >     2001:db8:2::/64
>     >     >>
>     >     >> Say the first default router is that associated with If1.
>     >     >>
>     >     >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop
>     >     >> receiving RAs on If1, but RAs on If2 keep arriving fine.
>     >     >>
>     >     >> Based on the logic of your algorithm, one would expect that a new
>     >     >> connection uses 2001:db8:2::/64/If2 (since that's the "more recently
>     >     >> advertised information). However, Rule #5 would override that and
>     >     make
>     >     >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes
>     >     addresses on
>     >     >> the outgoing interface.
>     >     >
>     >     > I'm even more confused now, sorry ;((
>     >
> that's where rule 5.5 would help (wherever it is actually implemented; alas...)

That's also why we made rule 5.5 a SHOULD in RFC 8028.

   Brian

---

From: j h woodyatt <[email-masked]>
Date: Wed, 20 Feb 2019 18:28:27 -0800

On Feb 20, 2019, at 17:13, Fernando Gont <[email-masked]> wrote:
> 
> Given that RFC6092 recommends "only allow outgoing connections”...

I certainly don’t remember writing that, and I just double-checked the text, and I’m pretty sure that recommendation is not in RFC 6092. The relevant portion is Section 3.4 Passive Listeners, I think, and it only goes so far as to say this:

   REC-49: Internet gateways with IPv6 simple security capabilities MUST
   provide an easily selected configuration option that permits a
   "transparent mode" of operation that forwards all unsolicited flows
   regardless of forwarding direction, i.e., not to use the IPv6 simple
   security capabilities of the gateway.  The transparent mode of
   operation MAY be the default configuration.

The recommendation to deny inbound flows to passive listeners by default, I believe, comes from RFC 4864, which says this on page 15:

   These should provide a default configuration where incoming traffic
   is limited to return traffic resulting from outgoing packets
   (sometimes known as reflective session state).

The reason this is important: RFC 6092 includes all that special requirements language despite being Informational category because IPv6 Ready and various other groups were asking for guidance by which they could write their own standards for IPv6 Simple Security requirements, and IETF wanted to give them that guidance. And so, RFC 6092 was written with that aim in mind. RFC 4864 is just an Informational document that offers some opinionated assertions on the topic, and I would say it’s worth what you paid for it.

As far as I know, IETF has not yet actually written a Standards Track RFC that says Internet gateways SHOULD (note well: requirements language) block inbound flows to passive listeners. I’d be interested to know if I’ve missed that news. In any case, my recollection is that it wasn’t the case when RFC 6092 was published.

Shorter james: don’t blame me for this. I didn’t do it.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 23:26:29 -0300

On 20/2/19 23:01, Erik Kline wrote:
[....]
> that's where rule 5.5 would help (wherever it is actually implemented;

Not sure what you mean. How would rule 5.5. prevent SA oscillation or
allow communication with the new "owner" of the stale prefix?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 23:41:41 -0300

On 20/2/19 23:28, j h woodyatt wrote:
> On Feb 20, 2019, at 17:13, Fernando Gont <[email-masked]
> I certainly don’t remember writing that, and I just double-checked the
> text, and I’m pretty sure that recommendation is not in RFC 6092. 

I quickly grep'ed RFC6092. Found this:

   If an inbound SYN packet is filtered, either because a corresponding
   state record does not exist or because of the filter's normal
   behavior, a filter has two basic choices: to discard the packet
   silently, or to signal an error to the sender.  Signaling an error
   through ICMPv6 messages allows the sender to detect that the SYN did
   not reach the intended destination.  Discarding the packet, on the
   other hand, allows applications to perform simultaneous-open more
   reliably.  A more detailed discussion of this issue can be found in
   [RFC5382], but the basic outcome of it is that filters need to wait
   on signaling errors until simultaneous-open will not be impaired.

   REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
   "Destination Unreachable" error code 1 (Communication with
   destination administratively prohibited) to any unsolicited inbound
   SYN packet after waiting at least 6 seconds without first forwarding
   the associated outbound SYN or SYN/ACK from the interior peer.

FWIW, I do agree with the advice.

> As far as I know, IETF has not yet actually written a Standards Track
> RFC that says Internet gateways SHOULD (note well: requirements
> language) block inbound flows to passive listeners. I’d be interested to
> know if I’ve missed that news. In any case, my recollection is that it
> wasn’t the case when RFC 6092 was published.
> 

Actually, I'm in favor of such advice ;-)  I do think that CPEs should
support UPnP for IPv6, such that apps can punch holes in the fw, as they
do for the IPv4 case.

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Feb 2019 18:52:01 -0800

> allow communication with the new "owner" of the stale prefix?

I don't know about "stale", but looking at it again now I think 5.5 doesn't
appear complete. I think an implementation would need to go further than
just select a srcaddr based on the next hop advertiser, but it would need
to remember to keep using that next hop for traffic originated with that
srcaddr until a router failure could be detected (NUD failure, is_router
flag flip, lifetime expiration, ...).  Non-trivial, actually.

---

From: j h woodyatt <[email-masked]>
Date: Wed, 20 Feb 2019 19:03:18 -0800

Hi Fernando,

It matters a lot what “unsolicited” means, c.f. the final prepositional phrase in this explanation from Section 2.3:

   The general operating principle is that transport layer traffic is
   not forwarded into the interior network of a residential IPv6 gateway
   unless it has been solicited explicitly by interior transport
   endpoints, e.g., by matching the reverse path for previously
   forwarded outbound traffic, or by matching configured exceptions set
   by the network administrator.

The use of a PCP server or the selection of the “transparent mode” configuration option *is* a solicitation of inbound flows to passive listeners. There is no recommendation for the default configuration of either a PCP server or the transparent mode. Under a strict interpretation of only RFC 6092 (without attempting to reference RFC 4864 normatively as one hopes external bodies would not do), it MAY be the case that inbound flows to passive listeners are solicited by DEFAULT until explicitly configured otherwise.

It’s RFC 4864 that recommends denying all inbound flows to passive listeners, and RFC 6092 was carefully written to remain neutral on that point. Precisely because we expected RFC 6092 to be input to external standards, and we expected that some bodies would require transparent mode by default.

> On Feb 20, 2019, at 01:59, Fernando Gont <[email-masked]> wrote:
> 
> On 20/2/19 06:32, Mark Smith wrote:
> [....]
>>>> - As Ole implied, TCP uses addresses as identifiers, so TCP expects
>>>> that the address will persist for the entire duration of the TCP
>>>> connection, regardless of how long that duration is.
>>> 
>>> Your are turning a kludge into a design principle.
>> 
>> It's been a design assumption and expectation rather than a principle,
>> and an expectation TCP has had since 1974 (see RFC675, 2.2  "Sockets
>> and Addressing"  (That's TCPv1, before IP was split off)).
>> 
>> <snip>
>> 
>>> 
>>> Clearly, with your model of TCP connections surviving interface up/downs
>>> and the default lifetimes, you really have a host that is unusable,
>>> except in very specific network conditions -- such as: the host never
>>> moves (quite unlikely these days)
>> 
>> A 2013 presentation that makes that observation and some others.
>> 
>> "The Rapid Rise of the Mobile Multihomed Host, and What It Might Mean
>> to the Network"
>> http://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf
>> 
>> 
>>> and nothing (including the CPE) fails
>>> (quite unlikely).
>>> 
>> 
>> I'm not saying these behaviours and expectations are necessarily correct today.
> 
> Besides "mobile" nodes, we have had RFC4941 for quite a long time now.
> Temporary addresses are preferred over stable addresses in RFC6724. --
> so short-lived addresses are more the norm than the exception for IPv6,
> I'd say.
> 
> 
> 
>> What I am saying is that they are and have been foundation design and
>> implementation assumptions that have been in place for multiple
>> decades. I think the longer a foundation assumption has been in place,
>> the more care and consideration you need to give to changing it,
>> because there can be unexpected impacts. Given those impacts, it may
>> be better to preserve them and design around them, compared to trying
>> to change them ("boiling the ocean"). The Mobile IP people, for
>> example, took this approach.
> 
> Based on the deployment level of Mobile IP, I'm not sure we want to
> follow that road ;-)
> 
> 
> 
>> People have said moving to multi-path transport layer protocols is
>> trying to boil the ocean.
>> 
>> Compared to providing stable PD prefixes within the BNG
>> infrastructure, I consider upgrading CPE to be boiling the ocean -
>> waiting on a CPE vendor to develop that firmware (depending on their
>> development priorities you may be waiting 3 to 6 months or possibly
>> longer), testing, and then deploying 100s of 1000s of CPE software
>> upgrades during many middles' of the night, with a risk of a
>> percentage of upgrades failing.
> 
> Note: me, I think that many CPEs will never store prefixes on stable
> storage. So, as far as *I* am concerned, the CPE advice is "this is what
> you should do if you want to be nice".
> 
> As noted before, a host cannot rely on the ISP to do stable prefixes,
> nor on CPEs to be nice. So if you want to be robust, the best place to
> improve such robustness is at the host.
> 
> 
> 
>> That's if you have managed CPE. If you
>> support BYO CPE (very common in Australia), then the time frame for
>> CPE functionality changes through upgrades is in the order of 5 years
>> or more, because people don't replace BYO CPE unless it stops working,
>> and they don't upgrade firmware either if it subjectively seems to
>> them to be working.
> 
> I agree with you in this respect. That's why I said you cannot rely on
> the CPE doing "the right thing" to get this problem solved.
> 
> 
> 
>> Upgrading ISP network infrastructure and back-end systems isn't easy
>> either, however it is within house so runs to your schedule and
>> resource availability, and all customers using that
>> infrastructure/system gain the benefit without having any changes made
>> to their equipment or configuration.
> 
> An ISP may have its own reasons for doing dynamic prefixes. A poll made
> by Jordi indicates that 37% of surveyed ISPs employ dynamic prefixes.
> That's a significant percentage... and you want host to be robust in
> such scenarios, too.
> 
> 
> -- 
> Fernando Gont
> SI6 Networks

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Feb 2019 08:35:30 +0100

Hi,

> keepalives. Higher-latency due to relaying and rendezvous. And so on.

NPTv6 does not need state, so no keepalives and battery impact.

Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to
learn how to deal with NAPT.  New protocols that embed IP addresses are 
killed by IPv4 NAPT anyway, so that ship has sailed - and everything that
doesn't care about embedded IP addresses will nicely work throug NPTv6.

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Feb 2019 10:41:47 +0000

On 21 Feb 2019, at 02:01, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, 20 Feb 2019 at 17:49, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Eric,

On 20/2/19 22:12, Erik Kline wrote:
>
>
> On Wed, 20 Feb 2019 at 17:07, Fernando Gont <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

Agreed.

Yeah.... we did add an explicit pointer to this in the Nodes Requirements -bis, fwiw (noting RFC 8028).

Tim

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 13:11:33 -0300

On 21/2/19 07:41, Tim Chown wrote:
>> On 21 Feb 2019, at 02:01, Erik Kline <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     > On Wed, 20 Feb 2019 at 17:07, Fernando Gont
>>     <[email-masked] <mailto:[email-masked]>
> Yeah.... we did add an explicit pointer to this in the Nodes
> Requirements -bis, fwiw (noting RFC 8028).

Probably an irrelevant question to ask now :-), but, anyway: any clues
why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you
cannot really do multi-prefix without RFC8028...

---

From: Timothy Winters <[email-masked]>
Date: Thu, 21 Feb 2019 11:14:32 -0500

On Thu, Feb 21, 2019 at 11:12 AM Fernando Gont <[email-masked]>
wrote:

> >>     >     >> advertised information). However, Rule #5 would override
> >>     that and
> >>     >     make
My memory of this was the working group wasn't convinced that every node
needed to support it.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 13:23:33 -0300

On 21/2/19 13:14, Timothy Winters wrote:
[...]
> My memory of this was the working group wasn't convinced that every node

If you support multiple prefixes (all nodes do), then you really need
RFC8028. Otherwise it is quite likely that you will be egress-filtered.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2019 08:59:48 +1300

> My memory of this was the working group wasn't convinced that every node

fwiw the text changed from "would therefore be applicable" to "SHOULD"
after IESG review of draft-ietf-6man-multi-homed-host-07, and specifically
following a comment from Alvaro Retana. I didn't find anything to indicate
that we discussed MUST at all.

But indeed, nodes that don't support rule 5.5 are at risk from egress
filtering.

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 21 Feb 2019 21:10:30 +0000

-----Original Message-----

That's my feeling about this too. NAPT in IPv4 has solved a lot of the application issues, and even more than necessary for NPTv6. Plus, we, I mean me, related to work, have dealt with very many IPv4 "basic" NAT firewalls, for years now, and they are really quite trouble-free. I think that the problems Fernando is concerned about should be manageable with NPTv6.

More to the point, I'm not sure how feasible it is, long term, to NOT have this level of address independence. From my point of view, it has sort of become part of the culture.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2019 10:14:39 +1300

> RFC8028. Otherwise it is quite likely that you will be egress-filtered.

But as I pointed out, RFC8028 only makes rule 5.5 a SHOULD. It's
SHOULDs all the way down.

Of course, SHOULD means "that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed...". In other words, do RFC8028 and Rule 5.5
unless there's a good reason not to.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2019 10:22:46 +1300

> More to the point, I'm not sure how feasible it is, long term, to NOT have this level of address independence. From my point of view, it has sort of become part of the culture.

Applications that recover smoothly from unexpected transport failures, including unexpected address failures or even unexpected changes between IPv6 and IPv4, have also become part of the culture. Masking NAPT glitches is only one of the things they do. In fact, they conceal NAPT glitches in most cases: we just have the odd RESTful transaction that fails from time to time with no explanation.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 22 Feb 2019 08:40:24 +1100

On Thu., 21 Feb. 2019, 18:36 Gert Doering, <[email-masked]> wrote:

> killed by IPv4 NAPT anyway, so that ship has sailed -

Getting it back in IPv6 is one of the things I hope we can get.

That's because applications that would be best performing, most robust and
more secure with a peer-to-peer communications model are forced to adopt an
absolute client-server model (where the server is a much more likely
performance bottleneck, the server becomes a SPOF for all clients using it
at the time, and the server is a natural interception point for a malicious
server operator).

Being forced to use a client-server communications model is like going to a
birthday party and having everybody have to conduct all of their
conversations via the birthday girl or boy, rather than directly with any
of the other attendees.

Another analogy to show the significance is that with NAT in the telephone
network, it wouldn't be possible for me to give you this phone's number to
call me. Would any of us accept that constraint on the usability of our
phones?

Regards,
Mark.

and everything that

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Feb 2019 22:53:02 +0100

Hi,

> at the time, and the server is a natural interception point for a malicious

Have you looked out there recently?  None of the big actors in the market
seem to have any particular interest in moving away from a "we are the cloud 
content players, you are just visiting clients" model.

(The gaming industry has, to some extent, but that doesn't seem to be
a really strong driver)

[..]
> call me. Would any of us accept that constraint on the usability of our

When did you do the last phone call on your mobile tablet-like computer 
thingie?

Gert Doering
        -- NetMaster

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 21 Feb 2019 21:53:37 +0000

From: Mark Smith <[email-masked]> 

> That's because applications that would be best performing, most robust and more secure with a peer-to-peer communications model are forced to adopt an absolute client-server model (where the server is a much more likely performance bottleneck, the server becomes a SPOF for all clients using it at the time, and the server is a natural interception point for a malicious server operator).

Even if it's only the prefix that changes? I don’t get that. Peer to peer can be made to work there too. I agree if you're talking about NAPT, though. Those basic NAT firewalls I alluded to previously support peer-peer quite nicely.

Bert

---

From: Mark Smith <[email-masked]>
Date: Fri, 22 Feb 2019 09:46:03 +1100

On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E
<[email-masked]> wrote:
> Even if it's only the prefix that changes? I don’t get that. Peer to peer can be made to work there too.

"made to work" implies work arounds. The IP layer has a peer to peer
nature - any node should be able to directly send to any other node,
just by having the other node's address. If a device has to send it's
packets through a third party to reach the actual party it wishes to
communicate with, it isn't a peer of the latter party. It is now a
client of the middle relay party.

This isn't the place to rehash the NAT discussion (because IPv6 + NAT
doesn't provide any benefits over IPv4 + NAT, and that makes IPv6
pretty much pointless.)

Have a look at the following presentation on NAT from a few years ago,
where I think I did something different to other NAT presentations - I
compared NAT to what I describe as a network operator's "Network
Critical Success Factors". Any questions/comments, we can discuss
off-list.

"The Trouble with NAT (Or why I care about IPv6)"
https://www.ausnog.net/sites/default/files/ausnog-2016/presentations/1.2_Mark_Smith_AusNOG2016.pdf

(APNIC asked me to write up a few blog articles on it if you want a
longer read - https://blog.apnic.net/author/mark-smith/)

> I agree if you're talking about NAPT, though. Those basic NAT firewalls I alluded to previously support peer-peer quite nicely.
>

So I think there's commonly a big different between works and works
well. NAT may work, however compared to stateless IPv6 (and IPv4)
forwarding, it doesn't work anywhere as near as well.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Feb 2019 15:04:26 -0800

> forwarding, it doesn't work anywhere as near as well.
Mark,

I agreee with that with one exception. I believe that NAT/IPv4 can
offer better privacy in addressing than IPv6 given current addess
allocation methods.

Tom

---

From: Mark Smith <[email-masked]>
Date: Fri, 22 Feb 2019 10:21:58 +1100

> content players, you are just visiting clients" model.

Generally it's in their business interests not to.

However, just like everybody else, they don't have a choice anyway,
even if they wanted to with IPv4 because of NAT.

Still, there are lots of little actors, and a peer-to-peer model can
allow them to scale their application without having to spend massive
amounts on server infrastructure (physical or virtual.)

> (The gaming industry has, to some extent, but that doesn't seem to be

Something significant happened in that regard recently.

"IPv6 on Xbox One"
https://support.xbox.com/en-US/xbox-one/networking/ipv6-on-xbox-one

"And—most useful for Xbox—the expansion removes the need for Network
Address Translation (NAT), which can interfere with multiplayer gaming
and chat over IPv4 networks."

"..., for the best possible experience, we recommend enabling IPv6 on
your network."

> When did you do the last phone call on your mobile tablet-like computer

Sunday (and I need to get back to my Uncle since). Previous weeks a
number of them organising a trip and updating expired credit card
number details.

I'll observe that you've still got your phone number in your email
signature below, so being able to convey your globally unique phone
number and receive calls to it isn't yet obsolete.

Regards,
Mark.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2019 10:44:45 +1100

> On 22 Feb 2019, at 10:21 am, Mark Smith <[email-masked]> wrote:
> 

Actually he doesn’t.  He has something that approximates a globally
unique phone number.  The (0) should not be there.  There is a standard
for writing phone numbers that start with + and it isn’t being used.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Feb 2019 15:49:27 -0800

> offer better privacy in addressing than IPv6 given current addess

Huh? Random 64 bit numbers are less private than semi-opaque translation of 32 bit numbers?

In today’s world (where CGN is fortunately still mostly the exception rather than the rule), the
32 bit public number (mostly) identifies the household on a transient basis.

In IPv6, the 64 bit prefix (or 60 or 56 or ideally 48) similarly identifies the household, though it
might be somewhat less transient than the IPv4 32 bit number. I’ve been using the same cable
company for transport of my GRE tunnels that provide my real connectivity for about 10 years
now. In that time, I’ve had roughly 4 address changes.

Now, the rate of change there isn’t particularly relevant to my privacy (mostly it’s just a rare
nuisance), but I think it probably isn’t an uncommon indicator of IPv4 address stability for
people remaining on the same network.

I’d say there’s not much privacy in a 32 bit space that remains persistent for more than a year.
I’d argue that even if it takes 10 years to cycle an IPv6 prefix on a subscriber, you’ve still got
roughly the same privacy model there at the household prefix level.

On the host level, assuming that the hosts are using RFC4941, RFC7217, or RFC7943
(which most hosts use by default these days), then I think that the host portion in IPv6
is significantly more private than anything one gains from IPv4 NAT even though one does
not need to sacrifice the peer-to-peer nature of the internet in order to use them (as is the
case with IPv4 NAT).

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2019 08:54:49 +0900

On Thu, Feb 21, 2019 at 10:35 AM Fernando Gont <[email-masked]>
wrote:

> Given that RFC6092 recommends "only allow outgoing connections",

RFC 6092 recommends no such thing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2019 08:57:57 +0900

> doesn't care about embedded IP addresses will nicely work throug NPTv6.

It has only sailed if we as an industry deploy NAT for IPv6 in a pervasive
way. If we do not, and NAT66 remains an uncommon configuration, then the
application breakage resulting from NAT66-only deployments will cause those
deployments to roll back to IPv4 and/or global IPv6.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Feb 2019 16:18:55 -0800

> 32 bit public number (mostly) identifies the household on a transient basis.
Owen,

Privacy in CGN effectively if the device lives behind a NAT with
thousands of user. So if the an external external third party observes
two different flows that share the same NAT address, then the observer
can not infer that the two flows are sourced form the same device or
user.

Tom

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Feb 2019 17:04:36 -0800

> On Feb 21, 2019, at 16:18 , Tom Herbert <[email-masked]> wrote:
> 

Sure, but today, CGN is the exception, not the rule… Hopefully it will remain that way for the
foreseeable future as CGN is really an awful awful thing for the end user.

Also, due to CALEA constraints, most CGN implementations are going to quasi-static port
reservations per household, so it’s not as private as you think it is. It will raise the bar
slightly, forcing the third party to track an extra 32 bits per flow (2xport number), but that’s
about it.

Owen

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Feb 2019 17:13:13 -0800

Owen,

To be clear, I was not advocating NAT. I was only pointing out that it
has some privacy properties to the extent that even law enforcement
has even expressed concerns about it. For those users for which
privacy is vital, I don't believe it's an adequate solution. If
privacy is essential then I believe we really want single use
untrackable addresses  (see
draft-herbert-ipv6-prefix-address-privacy-00).

Tom

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 22 Feb 2019 10:58:14 +0900

I'm for as much privacy as possible, however, not at the cost of things such as:
- Unnecessary complexity increase
- Moving from peer-to-peer to client-server for everything
- Single point of failure
- Increasing the attacks chances by reducing the surface to the servers
- Increase the complexity of app development
- Complexity to host services in "clients"
- Complexity to use "freely" and "efficient" DNS
- etc

So, using the "privacy" in the extreme as a repellent to simple peer-to-peer is like if we say "knives need to be forbidden because they can be used to kill people".

If protocols or tools are badly used, law should take care of that.

We should make protocols able to support privacy as much as possible, but never at the cost of an extreme complexity and losing or degrading all the other features.

Regards,
Jordi

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 22:09:51 -0300

> unless there's a good reason not to.

So... what would be the good reason? :-)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 22:21:22 -0300

On 20/2/19 23:28, j h woodyatt wrote:
> text, and I’m pretty sure that recommendation is not in RFC 6092. The
> relevant portion is Section 3.4 Passive Listeners, I think, and it only
> goes so far as to say this:
> 

So it may default to "on" or "off"? (i.e., default value left unspecified?)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 22:27:04 -0300

On 21/2/19 20:54, Lorenzo Colitti wrote:
> On Thu, Feb 21, 2019 at 10:35 AM Fernando Gont <[email-masked]

Yep, that seems to be the case, sorry.

That said, that seems to be the way many ISPs are rolling IPv6. I
understand that's how Comcast does it in the USA, and the last to IPv6
deployments I tested in my city also "only allowed outgoing
communications".  It was fine for me, until I realized there was no UPnP
support for IPv6. That meant that in scenarios where I couldn't change
the CPE configuration, I did need a rendezvouz point for IPv6 -- where
with IPv4, dynamic DNS plus UPnP to punch holes in the NAT did the trick.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 23:13:11 -0300

> - Complexity to use "freely" and "efficient" DNS

There are two protocols associated with NATs:
1) Apps that incorporate IP addresses and ports in the app protocol
require an ALG
2) Because of of the "only allow outgoing connections" side-effect of
NATs, you need UPnP to open holes in the NAT, or some NAT traversal
technique.

"1)" goes away when you remove the NAT.

"2)" does not if you replace the NAT with a stateful firewall that only
allows outgoing connections. -- the majority of the IPv6 deployments
I've seen use this policy/model. And, of course, this is also a single
point of failure, will also increase application complexity, etc., etc.,
etc.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Feb 2019 18:23:38 -0800

> point of failure, will also increase application complexity, etc., etc.,

So we need to eliminate stateful firewalls as well as NAT...

Tom

---

From: Kristian McColm <[email-masked]>
Date: Fri, 22 Feb 2019 02:25:45 +0000

Amen to that. Make the end user devices responsible for their own security.
________________________________
From: v6ops <[email-masked]> on behalf of Tom Herbert <[email-masked]>
Sent: Thursday, February 21, 2019 9:23:38 PM
To: Fernando Gont
Cc: IPv6 Operations; [email-masked]; JORDI PALET MARTINEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Feb 2019 18:53:50 -0800

> Amen to that. Make the end user devices responsible for their own security.
Kristian,

Devices and applications are already responsible for their own
security. No serious application or OS would ever rely on the presence
of an external firewall for its security.

However, there is still some benefit of stateful firewalls to protect
network resources from attack. So we want the functionality of a
stateful firewall in stateless solution without any of the annoying
limitations of stateful devices (like they only work with certain
protocols, force flows to traverse specific intermediate nodes, are
single points of failure, etc). FAST ( draft-herbert-fast-00) is one
proposal for this.

Tom

_______________________________

---

From: Kristian McColm <[email-masked]>
Date: Fri, 22 Feb 2019 03:31:23 +0000

Then by that same token, can the end user devices, network services and network devices not provide their own packet filtering and other security mechanisms rather than forcing all network traffic to traverse centralized security devices?

It won't be a popular opinion with network security folks and security appliance vendors, but I am a believer that the endpoint device is the right place to implement network security. Intermediary network devices should not, in my opinion be doing anything other than forwarding packets to their destination.
________________________________
From: Tom Herbert <[email-masked]>
Sent: Thursday, February 21, 2019 9:53:50 PM
To: Kristian McColm
Cc: Fernando Gont; IPv6 Operations; [email-masked]; JORDI PALET MARTINEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

Kristian,

Tom

---

From: Ca By <[email-masked]>
Date: Thu, 21 Feb 2019 21:08:01 -0700

On Thu, Feb 21, 2019 at 8:31 PM Kristian McColm <[email-masked]>
wrote:

> Then by that same token, can the end user devices, network services and
> network devices not provide their own packet filtering and other security
> mechanisms rather than forcing all network traffic to traverse centralized
> security devices?
>
> It won't be a popular opinion with network security folks and security
> appliance vendors, but I am a believer that the endpoint device is the
> right place to implement network security. Intermediary network devices
> should not, in my opinion be doing anything other than forwarding packets
> to their destination.
>

+1, i have had a good experience removing stateful devices for the majority
of flows from a large mobile network over the last 5 years as we
transitioned for 464xlat.   No downsides.

And, with larger ipv6 space and random iid, discoverability risk is very
low for 3rd parties / scans / botnets

CB

> ------------------------------
> *From:* Tom Herbert <[email-masked]>
> *Sent:* Thursday, February 21, 2019 9:53:50 PM
> *To:* Kristian McColm
> *Cc:* Fernando Gont; IPv6 Operations; [email-masked]; JORDI PALET MARTINEZ
>
> *Subject:* Re: [v6ops] NAT debate (Re: A common problem with SLAAC in
> "renumbering" scenarios)
>

---

From: Raymond Burkholder <[email-masked]>
Date: Thu, 21 Feb 2019 21:53:54 -0700

On 2019-02-21 8:31 p.m., Kristian McColm wrote:
> Then by that same token, can the end user devices, network services 
> and network devices not provide their own packet filtering and other 
> security mechanisms rather than forcing all network traffic to 
> traverse centralized security devices?
>
> right place to implement network security. Intermediary network 
> devices should not, in my opinion be doing anything other than 
> forwarding packets to their destination.

There is a grey area here, from my experience.  With virtualization and 
containers, hosts are becoming routers, with the host thus being an 
intermediary device.  And there is tooling available which allows the 
host to apply protection policies as well as segregation policies to the 
virtualized functions it hosts.

In other configurations, in a traditional vein, 'switches' connect hosts 
of various sorts, and in that same traditional vein, are intermediary 
devices and just forward packets.

But there are security flavours out 'there' where the switch is no 
longer just a switch.  For those end-points which are unable or are 
unwilling to handle their own security, there is a form of network 
topology where  the 'switch' becomes more intelligent and can perform 
security functions on ingress/egress at the port level. This provides a 
form of distributed nonSPOF style protection mechanisms.

In combining the concepts of the virtualization host I mentioned 
initially, and this edge 'protection switch', they are both sharing the 
concept of distributed nonSPOF security functionality (which I suppose 
is part of what Network Function Virtualization does).  As one specific 
example, I'll mention Cillium, which is highly IPv6 aware, and excels at 
providing this distributed routing/security/forwarding function in a 
distributed fashion.

So I think there is a happy medium: some end points devices just can't 
do their own security, and for paranoid network operators, you can't 
trust that they can, as well as from an endpoint developer perspective 
(think microservices), you don't want them to. Providing those services 
at the connecting port level is the next best thing for the consistent, 
distributed and reliable application of protection rules?

---

From: Kristian McColm <[email-masked]>
Date: Fri, 22 Feb 2019 05:15:54 +0000

What you describe is, unless I missed something, network segmentation. I absolutely agree that network segmentation, either physical or virtual, is an important concept in network security. Separating customer facing interfaces from management interfaces is one example that comes to mind.

But I believe in the context of this discussion we are taking about layer 3 and up, deep packet inspection, flow analysis, and packet filtering, etc.

Even still, one could argue layer 1 and 2 segmentation is still done at the host level. The host has different physical or virtual interfaces that can have different policy in terms of routing/switching. The switches provide the different segments but the host ultimately decides which interface to put an ethernet frame onto, and if one arrives, how it should be processed. Likewise, the owner of the host requests a port that will put the interface into an appropriate network segment.

In other words, the host still decides what resources it needs and how it uses them.

An important concept to understand is that networks do not create data, they are merely the conduit that hosts use to communicate with each other. So then, in my view, the creators and consumers of the data flowing across a given network should be the ultimate point of access control and auditing, not the conduit itself.

From: Raymond Burkholder <[email-masked]>
Sent: Friday, February 22, 2019 4:53:54 AM
To: Kristian McColm; Tom Herbert
Cc: Fernando Gont; IPv6 Operations; [email-masked]; JORDI PALET MARTINEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

There is a grey area here, from my experience.  With virtualization and containers, hosts are becoming routers, with the host thus being an intermediary device.  And there is tooling available which allows the host to apply protection policies as well as segregation policies to the virtualized functions it hosts.

In other configurations, in a traditional vein, 'switches' connect hosts of various sorts, and in that same traditional vein, are intermediary devices and just forward packets.

But there are security flavours out 'there' where the switch is no longer just a switch.  For those end-points which are unable or are unwilling to handle their own security, there is a form of network topology where  the 'switch' becomes more intelligent and can perform security functions on ingress/egress at the port level.  This provides a form of distributed nonSPOF style protection mechanisms.

In combining the concepts of the virtualization host I mentioned initially, and this edge 'protection switch', they are both sharing the concept of distributed nonSPOF security functionality (which I suppose is part of what Network Function Virtualization does).  As one specific example, I'll mention Cillium, which is highly IPv6 aware, and excels at providing this distributed routing/security/forwarding function in a distributed fashion.

So I think there is a happy medium: some end points devices just can't do their own security, and for paranoid network operators, you can't trust that they can, as well as from an endpoint developer perspective (think microservices), you don't want them to.  Providing those services at the connecting port level is the next best thing for the consistent, distributed and reliable application of protection rules?

---

From: Mark Smith <[email-masked]>
Date: Fri, 22 Feb 2019 18:35:27 +1100

Hi Tom,

<snip>

> offer better privacy in addressing than IPv6 given current addess

So I don't think addressing privacy via NAT is really all that
valuable if there are many other ways, some quite easy, to uniquely
identify an anonymity desiring end-point/end-user, whose effectiveness
aren't impacted at all by NAT.

For example, this website is coming over IPv4 for me, and I'm using
IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't
be able to tracked.

https://amiunique.org/

Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in
Incognito/Private windows mode on this host. It says the same about my
Android 9 phone with Chrome in Incognito mode.

Going into the detail of how, they don't seem to be using IP address
at all for any identification, it is all browser attributes.

We have IPv6 temporary addresses, which makes using addresses harder
to use to identify a node. I think that is a lot better than nothing.

However, I don't see how IPv6 NAT would improve it much, and it
introduces the other drawbacks of NAT.

Regards,
Mark.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Feb 2019 23:44:52 -0800

Debating the beauty of NAT on an IPv6 list is surely good fun for some,
but could we get some progress on the original issue, which could be
summed up as a "bug in SLAAC"? Fernando filed that bug 3 weeks ago, I
saw hundreds of messages on the mailing list, but I did not see much
progress.

Do we agree that this is indeed a bug, or do we think that having users
disconnected from the Internet after a home router reboots is just a
desirable feature of IPv6?

Do we agree that it would be good if routers that reboot could just
reacquire the same prefix from DHCPv6 PD? Do we also agree that there
will always be a significant fraction of deployment in which that won't
be possible?

Do we agree that the working group should actually start working on some
improvement in SLAAC that would mitigate the issue? Not excluding of
course solutions that would also mitigate related egress filtering issue?

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Fri, 22 Feb 2019 18:50:48 +1100

On Fri, 22 Feb 2019 at 15:08, Ca By <[email-masked]> wrote:
>
>
>
> On Thu, Feb 21, 2019 at 8:31 PM Kristian McColm <[email-masked]> wrote:
>>
> +1, i have had a good experience removing stateful devices for the majority of flows from a large mobile network over the last 5 years as we transitioned for 464xlat.   No downsides.
>

+1

Encryption plus multipath transport layer protocols like MP-TCP is
really going to screw up a lot of things a lot of people are used to
doing in the network.

Multipathing doesn't just mean via two network interfaces, it may mean
different IPv6 addresses (say, one older, one newer, during
transition) temporary addresses on the same network interface.

Jump to the Impacts section on slide 63 if you want to cut to the chase.

"The Rapid Rise of the Mobile Multihomed Host, and what it might mean
to the network"
https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf

Regards,
Mark.

> And, with larger ipv6 space and random iid, discoverability risk is very low for 3rd parties / scans / botnets
>
> CB
>>

---

From: Lencse Gábor <[email-masked]>
Date: Fri, 22 Feb 2019 11:26:52 +0100

Dear Cameron,

2/22/2019 5:08 AM keltezéssel, Ca By írta:

[...]
> +1, i have had a good experience removing stateful devices for the 
> majority of flows from a large mobile network over the last 5 years as 
> we transitioned for 464xlat.   No downsides.

However, 464XLAT also contains Stateful NAT64 (as PLAT). Have you 
experienced any problems with that? (E.g. bottleneck, no scale up, etc.)

Full disclosure:
- I am soliciting your experience for our draft "Pros and Cons of IPv6 
Transition Technologies for IPv4aaS", available at: 
https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02
- I personally think that 464XLAT is a good IPv4aaS solution, I am just 
playing the devil's advocate.

Best regards,

Gábor Lencse

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Feb 2019 12:36:55 +0000

> saw hundreds of messages on the mailing list, but I did not see much

There seems to be lack of consensus on whether this can be thrown into 
the "bug in SLAAC" category.

Ole declared that the root cause was "misconfiguration/error".

Fernando and others feel that it's the compound outcome of several 
independent protocol and design-choice behaviours, none of which, 
incidentally, is inherently broken per se.

> desirable feature of IPv6?

Most people feel the outcome is undesirable when it happens.  Some 
people feel that it's not worth getting too excited about because 
assignment stickiness tends to ensure that prefix assignments are 
long-lived enough that it probably won't cause too much difficulty. 
Others noted that long SLAAC lifetimes and lack of application 
workarounds (HE, etc) would make it a noticeable problem, when it 
happens, but didn't comment on how frequently it happened.

> reacquire the same prefix from DHCPv6 PD?

Most operators seem to provision their networks such that they will not 
commit to prefix stability over the lifetime of a customer contract 
unless the customer coughs up more money for it.  Hand in hand with 
this, static ip addressing is routinely handled differently to dynamic 
IP addressing on service provider networks.

> Do we also agree that there

This is a complex question which interplays with cost, network design 
and long term network complexity.  There is no easy answer to it.

> course solutions that would also mitigate related egress filtering issue?

Fixing or updating SLAAC is likely to take years to roll out and at 
least one person was of the opinion that SLAAC was basically unfixable 
in this regard.  This ignores whether it would be useful or viable for 
the IETF to issue advice to CPE vendors and service providers about how 
to avoid the problem from happening in the first place.

Ultimately, your email shows why the discussion ended up in a discussion 
about NAT.  There's no single cause of the problem and no quick fix; 
declaring the problem to be solely the domain of any particular 
stakeholder may cause CPE vendors to deploy NPTv6 in the long term to 
work around the issue, because this would make the problem mostly 
disappear from the point of view of the user. There is a cost, of 
course, but it's a cost which most end users are already familiar with, 
and accept.  It would be sad and unfortunate if this were to be the 
outcome of this discussion.

Nick

---

From: Ca By <[email-masked]>
Date: Fri, 22 Feb 2019 07:24:22 -0700

On Fri, Feb 22, 2019 at 3:27 AM Lencse Gábor <[email-masked]> wrote:

> majority of flows from a large mobile network over the last 5 years as we

Correct, that is why i said “majority” of flows

No, our NAT64 is the same box as the NAT44

This means that as soon as a client moves from ipv4 NAT44 to NAT64 the
client load on the box moves from 100% of traffic needing NAT44 to clients
only sending less than 35% of traffic to that box.

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Feb 2019 11:36:19 -0500

I think I have heard the following suggestions in this conversation. I 
hope that taken all together, rather than as individual spot solutions, 
they can be a consensus recommendation.

ISPs should, as much as possible, reissue the same prefix to customers. 
Some things ISPs can do to increase the chances of this:

 1.

    Share lease information between redundant DHCPv6 servers. Most ISPs
    probably have redundant servers, since this is critical provisioning
    infrastructure. It may be difficult to synch information between
    servers for millions of leases over tens of milliseconds of latency;
    see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe
    DHCP vendors can report.

 2.

    Aggregate above the provider edge device, so that grooming customers
    between Provider Edge boxes (PEs) doesn't force a renumbering. It's
    been a few years since I worked on CMTSs, but when I did they did
    not support MP-BGP well (if at all), so routes had to be aggregated
    on the PE, or leaked in the IGP which is bad for convergence time.
    Maybe PE vendors can report.

 3.

    Set DHCPv6 lease timers very low prior to grooming events. A short
    interval during the maintenance window will increase load on the
    DHCPv6 server until timers have been returned to normal values.

 4.

    In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild
    the routing table. I think all of the necessary information is in
    those responses. Again, last time I was working on CMTSs, this
    feature was not supported. Maybe PE vendors can report.

Networks should, as much as possible, be resilient to prefix changes. 
Some things networks can do to improve resilience:

 1.

    Write a learned prefix to non-volatile memory and issue a DHCPv6
    Renew for that prefix on reboot.

 2.

    Use dynamic DNS and shorter TTLs.

 3.

    Implement something like NETCONF to distribute prefix information to
    policy devices like firewalls or SD-WAN controllers. I think a
    separate document describing this application of NETCONF would make
    sense.

In the case of failures, it cannot be assumed that sessions will stay 
active. We try to build in redundancy and resilience where we can, but 
where there's a single point of failure (such as CE or PE), and it fails 
(such as an unplanned reboot), our expectations should be appropriate.

Is this a reasonable summary?

Lee

---

From: Christian Huitema <[email-masked]>
Date: Fri, 22 Feb 2019 08:44:55 -0800

> On Feb 22, 2019, at 4:36 AM, Nick Hilliard <[email-masked]> wrote:
> 
> There seems to be lack of consensus on whether this can be thrown into the "bug in SLAAC" category.
> 
> Fernando and others feel that it's the compound outcome of several independent protocol and design-choice behaviours, none of which, incidentally, is inherently broken per se.
> 
> Most people feel the outcome is undesirable when it happens.  Some people feel that it's not worth getting too excited about because assignment stickiness tends to ensure that prefix assignments are long-lived enough that it probably won't cause too much difficulty. Others noted that long SLAAC lifetimes and lack of application workarounds (HE, etc) would make it a noticeable problem, when it happens, but didn't comment on how frequently it happened.

I think that's a good summary: a problem that does not occur very often, but is very annoying when it does.

> Most operators seem to provision their networks such that they will not commit to prefix stability over the lifetime of a customer contract unless the customer coughs up more money for it.  Hand in hand with this, static ip addressing is routinely handled differently to dynamic IP addressing on service provider networks.
> 
> This is a complex question which interplays with cost, network design and long term network complexity.  There is no easy answer to it.

I think that your response to the previous question also sums up this side of the issue. Many operators do provision fairly stable prefixes. However, for a set of complicated reasons, not all of them will guarantee this stability, not all the time. The answer there could very well be to do nothing, and to not add another mandate to operators.

> Fixing or updating SLAAC is likely to take years to roll out and at least one person was of the opinion that SLAAC was basically unfixable in this regard.  This ignores whether it would be useful or viable for the IETF to issue advice to CPE vendors and service providers about how to avoid the problem from happening in the first place.

Anything we do in this space can take a long time to roll out, but it does not take forever. In many cases it probably takes less time than it takes to agree on a potential solution in the IETF. For example, security bugs in operating systems can get patched in a matter of weeks or maybe months. Not all devices can be patched quickly, but many can.

As usual, we don't want to see creative solutions popping in different devices. A common standard seems preferable. So, if a subset of the working group wants to work on the solution, we should be happy to let them do that.

-- Christian Huitema

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 Feb 2019 09:04:38 -0800

> Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:
> Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.
> Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.

If the prefix is written to nv men, wouldn’t it also be possible for implementers to send rapid deprecation RAs for any prefix not renewed?

In other words, after reboot, try to reacquire same prefix. If that doesn’t work, when you advertise the new prefix, you could also include the old prefix with a very short preferred and valid lifetime (e.g. 1 second) in the first RA, which should be sent to the all nodes on link multicast?

It doesn’t eliminate the problem, but 1 second additional duration would be barley noticeable amid the minute or so it takes most home gateways to reboot. 

Owen

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2019 12:05:13 -0500

Lee Howard <[email-masked]> wrote:
    > 2

    > between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a
    > few years since I worked on CMTSs, but when I did they did not support
    > MP-BGP well (if at all), so routes had to be aggregated on the PE, or
    > leaked in the IGP which is bad for convergence time. Maybe PE vendors can
    > report.

I don't understand this comment/concern about convergence time.

I was the architect at a PE vendor (PPPoE, not CMTS, but from the north-interface, it is
pretty similar) for a numbers of years.  [2012 to 2017, parttime].

We didn't support BGP; we got no call for it as an IGP.
We supported OSPF/OSPFv3, and we assumed aggregation above the provider edge
devices. We counselled our customers to make an OSPF area for this, and
so it naturally aggregated above, and the customer grooming did not leak out
of the area.
Few of our customers' IPv6 usage grew very much during this time, so I can't
say if this turned out to be a problem.

The customers for whom this was a problem architecturally had the problem
that their network was so small that they the "above" point was their EBGP
device anyway.    We're talking about rather small ISPs with O(10^3)
customers here :-) (that would be the entire country/island)

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Feb 2019 09:11:09 -0800

Mark,

Yes, but by that same rationale a simple substitution cipher is better
than nothing in cryptography!

What pretty much any conversation about privacy in addressing seems to
lacking is a quantitative description of privacy and any empiracal
data on the impact that privacy mechanisms, like those defined in
RFC4941, have had. You might say it "makes using addresses harder to
use to identify a node". But then the obvious question is _how_ much
harder? Is this really protecting anyone's privacy, or it is just a
minor inconvenience to attackers and only giving users a false sense
of security?

The irony is that CGN seems to have the best supporting evidence for
being a mechanism that impacts privacy, but it was never even intended
to be a privacy mechanism. The evidence is in the form of concerns
form law enforcement that the privacy side effect is too strong and
impedes their investigations
(https://www.theregister.co.uk/2017/10/18/europol_cgnat/).

So I don't think "Is addressing privacy via NAT really achieving much
compared to a privacy goal of anonymity?" is the right question. The
right question to ask is "Is addressing privacy via any IETF defined
mechanism achieving much compared to a privacy goal of anonymity?"

Tom

---

From: Tim Chown <[email-masked]>
Date: Fri, 22 Feb 2019 17:30:11 +0000

Hi,

On 22 Feb 2019, at 17:04, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:

  1.

  2.

  3.

That's similar in spirit to RAmond, which we used to use when seeing rogue RAs on our campus network.  It would auto-deprecate any prefixes that shouldn't be there. (http://ramond.sourceforge.net/)

The snag is that I suspect most OSes would ignore a valid timer of 1 second, given the 7200 second (2 hour) minimum defined in RFC 4862 (unless the RA is authenticated, somehow).  The preferred timer can be zero.  When RAmond was written, if we used a valid timer less than 7200 seconds it seemed that the deprecating RAs were ignored.  That was 10+ years ago though.  Perhaps Tim Winters has data on whether that rule is implemented today in practice; I'd assume the tests he runs might include that.

But I like Lee's analysis.

Tim

---

From: Timothy Winters <[email-masked]>
Date: Fri, 22 Feb 2019 12:43:30 -0500

On Fri, Feb 22, 2019 at 12:30 PM Tim Chown <[email-masked]> wrote:

> Hi,
>
> On 22 Feb 2019, at 17:04, Owen DeLong <[email-masked]> wrote:
>
> Networks should, as much as possible, be resilient to prefix changes. Some
> things networks can do to improve resilience:
>
>    1.
>
>    policy devices like firewalls or SD-WAN controllers. I think a separate
>    document describing this application of NETCONF would make sense.
>
>
> If the prefix is written to nv men, wouldn’t it also be possible for
> implementers to send rapid deprecation RAs for any prefix not renewed?
>
> In other words, after reboot, try to reacquire same prefix. If that
> doesn’t work, when you advertise the new prefix, you could also include the
> old prefix with a very short preferred and valid lifetime (e.g. 1 second)
> in the first RA, which should be sent to the all nodes on link multicast?
>
> It doesn’t eliminate the problem, but 1 second additional duration would
> be barley noticeable amid the minute or so it takes most home gateways to
> reboot.
>
>
> That's similar in spirit to RAmond, which we used to use when seeing rogue
> RAs on our campus network.  It would auto-deprecate any prefixes that
> shouldn't be there. (http://ramond.sourceforge.net/)
>
> The snag is that I suspect most OSes would ignore a valid timer of 1
> second, given the 7200 second (2 hour) minimum defined in RFC 4862 (unless
> the RA is authenticated, somehow).  The preferred timer can be zero.  When
> RAmond was written, if we used a valid timer less than 7200 seconds it
> seemed that the deprecating RAs were ignored.  That was 10+ years ago
> though.  Perhaps Tim Winters has data on whether that rule is implemented
> today in practice; I'd assume the tests he runs might include that.
>
So we test that IPv6 implementations set the address to two hours if the
address was higher then gets a low value (such as 1).   Currently there is
no way to make it less then two hours if a Rogue RA gets out and gives out
a longer address lifetime.

---

From: David Farmer <[email-masked]>
Date: Fri, 22 Feb 2019 11:53:56 -0600

Generally, I agree with what you are saying, but I'd like to see something
like the following added as well;

Even if an ISP intends to change the IPv6 prefix regularly in
the longer-term, say every few months or even each month at an extreme, in
the shorter-term IPv6 prefixes SHOULD be stable, for time periods of hours,
days, and maybe even weeks at a time.  Or, put another way, CPE devices
SHOULD NOT get a new IPv6 prefix every time they are rebooted.  Note: even
in locations where utility power is generally stable, power outages
frequently occur in clusters over a few hours or days.  This occurs when an
emergency repair is made to restore power and then more permanent repairs
cause short outages in the following hours or days. In this scenario, each
of these events in the cluster SHOULD NOT result in the CPE receiving a
different IPv6 prefix.

Conversely, when widespread power events occur, affecting thousands or even
tens of thousands of customers, it may not be practical or even possible
for an ISP to guarantee all CPE will receive the same IPv6 prefix they had
before.  Therefore to the extent possible, CPE and local networks SHOULD be
resilient to their ISP provided IPv6 prefix changing, sometimes even
unexpectedly changing.

Thanks.

On Fri, Feb 22, 2019 at 10:36 AM Lee Howard <[email-masked]> wrote:

>    infrastructure. It may be difficult to synch information between servers
>    for millions of leases over tens of milliseconds of latency; see RFC6853,
>    "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can
>    report.
>
>    2.
>
>    interval during the maintenance window will increase load on the DHCPv6
>    server until timers have been returned to normal values.
>
>    4.
>
>    In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the
>    routing table. I think all of the necessary information is in those
>    responses. Again, last time I was working on CMTSs, this feature was not
>    supported. Maybe PE vendors can report.
>
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Ca By <[email-masked]>
Date: Fri, 22 Feb 2019 11:06:20 -0700

> mechanism achieving much compared to a privacy goal of anonymity?"

1.  Network service providers cannot provide address anonymity.  LEA
requirements in the USA and many jurisdictions simply do not allow it, so
who is the customer of such a standard?  Who would make and deploy it?

2. Network address annonimity today is generally provided via Tor.  How
could the ietf provide something better than existiting tor solutions,
knowing that it will not be baked into the network — meaning it must be
over the top.

3. CGN is not private. It throw off per session logs of every transaction,
so this is a full click stream archived ... with varing levels of
intentional monetization and security from hackers.

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Feb 2019 13:43:23 -0500

On 2/22/19 12:53 PM, David Farmer wrote:
> Generally, I agree with what you are saying, but I'd like to see 
> something like the following added as well;
>
> the longer-term, say every few months or even each month at an 
> extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time 
> periods of hours, days, and maybe even weeks at a time. Or, put 
> another way, CPE devices SHOULD NOT get a new IPv6 prefix every time 
> they are rebooted.  Note: even in locations where utility power is 
> generally stable, power outages frequently occur in clusters over a 
> few hours or days.  This occurs when an emergency repair is made to 
> restore power and then more permanent repairs cause short outages in 
> the following hours or days. In this scenario, each of these events in 
> the cluster SHOULD NOT result in the CPE receiving a different IPv6 
> prefix.
>
> Conversely, when widespread power events occur, affecting thousands or 
> even tens of thousands of customers, it may not be practical or even 
> possible for an ISP to guarantee all CPE will receive the same IPv6 
> prefix they had before. Therefore to the extent possible, CPE and 
> local networks SHOULD be resilient to their ISP provided IPv6 prefix 
> changing, sometimes even unexpectedly changing.

What's the difference between what you said and "ISPs should, as much as 
possible, reissue the same prefix to customers."?

Lee

>
> Thanks.
>
> On Fri, Feb 22, 2019 at 10:36 AM Lee Howard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think I have heard the following suggestions in this
>     conversation. I hope that taken all together, rather than as
>     individual spot solutions, they can be a consensus recommendation.
>
>
>     ISPs should, as much as possible, reissue the same prefix to
>     customers. Some things ISPs can do to increase the chances of this:
>
>     1.
>
>         Share lease information between redundant DHCPv6 servers. Most
>         ISPs probably have redundant servers, since this is critical
>         provisioning infrastructure. It may be difficult to synch
>         information between servers for millions of leases over tens
>         of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy
>         Deployment Considerations." Maybe DHCP vendors can report.
>
>     2.
>
>         Aggregate above the provider edge device, so that grooming
>         customers between Provider Edge boxes (PEs) doesn't force a
>         renumbering. It's been a few years since I worked on CMTSs,
>         but when I did they did not support MP-BGP well (if at all),
>         so routes had to be aggregated on the PE, or leaked in the IGP
>         which is bad for convergence time. Maybe PE vendors can report.
>
>     3.
>
>         Set DHCPv6 lease timers very low prior to grooming events. A
>         short interval during the maintenance window will increase
>         load on the DHCPv6 server until timers have been returned to
>         normal values.
>
>     4.
>
>         In the case of a PE reboot, use DHCPv6 Bulk Leasequery to
>         rebuild the routing table. I think all of the necessary
>         information is in those responses. Again, last time I was
>         working on CMTSs, this feature was not supported. Maybe PE
>         vendors can report.
>
>
>     Networks should, as much as possible, be resilient to prefix
>     changes. Some things networks can do to improve resilience:
>
>     1.
>
>         Implement something like NETCONF to distribute prefix
>         information to policy devices like firewalls or SD-WAN
>         controllers. I think a separate document describing this
>         application of NETCONF would make sense.
>
>
>     In the case of failures, it cannot be assumed that sessions will
>     stay active. We try to build in redundancy and resilience where we
>     can, but where there's a single point of failure (such as CE or
>     PE), and it fails (such as an unplanned reboot), our expectations
>     should be appropriate.
>
>     [email-masked] <mailto:[email-masked]>
> David Farmer Email:[email-masked] <mailto:[email-masked]>

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Feb 2019 13:44:48 -0500

On 2/22/19 12:04 PM, Owen DeLong wrote:
>>     Implement something like NETCONF to distribute prefix information
>>     to policy devices like firewalls or SD-WAN controllers. I think a
>>     separate document describing this application of NETCONF would
>>     make sense.
>>
>
> doesn’t work, when you advertise the new prefix, you could also 
> include the old prefix with a very short preferred and valid lifetime 
> (e.g. 1 second) in the first RA, which should be sent to the all nodes 
> on link multicast?
>
> It doesn’t eliminate the problem, but 1 second additional duration 
> would be barley noticeable amid the minute or so it takes most home 
> gateways to reboot.

I like this suggestion; don't think I'd seen it before.

"Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew 
for that prefix on reboot. If renew fails, send new RAs for that prefix 
with a preferred lifetime of 0, and a valid lifetime of two hours."

Lee

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Feb 2019 10:55:52 -0800

On Fri, Feb 22, 2019 at 10:06 AM Ca By <[email-masked]> wrote:
> 1.  Network service providers cannot provide address anonymity.  LEA requirements in the USA and many jurisdictions simply do not allow it, so who is the customer of such a standard?  Who would make and deploy it?

The customer of this is political dissident that is speaking out
against injustice of a corrupt government. There is nothing that
prevents a solution that provides the privacy for the dissident, but
still allows their network provider to maintain records that correlate
address to identity is available to LEA for the local jurisdiction
under lawful order. This really isn't different than other areas of
privacy on the Internet (like the logs that Facebook or Google keep).
The point is that anonimity is needed to prevent unauthorized third
parties from breaking someones privacy.

>
> 2. Network address annonimity today is generally provided via Tor.  How could the ietf provide something better than existiting tor solutions, knowing that it will not be baked into the network — meaning it must be over the top.
>

I'm not sure what "provided via Tor" means.

> 3. CGN is not private. It throw off per session logs of every transaction, so this is a full click stream archived ... with varing levels of intentional monetization and security from hackers.
>
Yes, it is expected that the local provider has full view of all
associations of address to some device, that's pretty much a given and
we have to trust the local provider to some extent. What we're trying
to prevent is untrusted external parties from deducing identity or
location of users.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2019 16:21:56 -0500

> (https://www.theregister.co.uk/2017/10/18/europol_cgnat/).

Has anyone seen any well-written explanations of how anti-privacy CGN is?

It seems that due to the need to:

    > 3. CGN is not private. It throw off per session logs of every transaction, so
    > this is a full click stream archived ... with varing levels of intentional
    > monetization and security from hackers.

that CGN results in significantly higher privacy invasion than IPv6 (even
without privacy extensions). (which is your point)

But, how we can explain this easily to other less technical people?

---

From: David Farmer <[email-masked]>
Date: Fri, 22 Feb 2019 15:40:26 -0600

Yes, at a very high level, it boils down to the same thing.  However,
saying "as much as possible", set a very wide standard, providing few
parameters to set expectations seems useful and helpful in developing a
consensus. For example, if someone says it is impossible for their solution
to ever issues the same prefix, they need to be told they should probably
find a different solution. Where on the other hand, what if an ISP could
always provide the same prefix, this basically says that is what they
should do, where once they exceed some minimum I would want to give the ISP
flexibility to implement what makes sense for their business model.  Also,
it needs to be clear this is "in normal circumstances", it should be
acknowledged there will be situations where this is not a reasonable
expectation.

On Fri, Feb 22, 2019 at 12:43 PM Lee Howard <[email-masked]> wrote:

> possible for an ISP to guarantee all CPE will receive the same IPv6 prefix
> they had before.  Therefore to the extent possible, CPE and local networks
> SHOULD be resilient to their ISP provided IPv6 prefix changing, sometimes
> even unexpectedly changing.
>

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Feb 2019 17:01:56 -0500

On 2/22/19 4:40 PM, David Farmer wrote:
> parameters to set expectations seems useful and helpful in developing 
> a consensus. For example, if someone says it is impossible for their 
> solution to ever issues the same prefix, they need to be told they 
> should probably find a different solution.

Hmm. Has anyone said it's impossible to ever issue the same prefix?

And even if they did, is it in charter for us to say, "You bought the 
wrong gear, buy something else"?

We're kind of arguing the definition of "possible," I think.

> Where on the other hand, what if an ISP could always provide the same 
> prefix, this basically says that is what they should do, where once 
> they exceed some minimum I would want to give the ISP flexibility to 
> implement what makes sense for their business model.  Also, it needs 
> to be clear this is "in normal circumstances", it should be 

I was trying to figure out how to add this as a #5, but I kept getting 
stuck on #1. Is it possible to ensure that the same DHCPv6 server always 
responds to queries, and therefore always Renews the lease? Or is this 
specifically for Requests, not Renewals? The synchronization on #1 is 
still not something I'm sure about, and if that's not fixed (and maybe 
it is), I don't see any way to satisfy this proposal.

Lee

>
> On Fri, Feb 22, 2019 at 12:43 PM Lee Howard <[email-masked] 
>>     extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for
>>     time periods of hours, days, and maybe even weeks at a time.  Or,
>>     put another way, CPE devices SHOULD NOT get a new IPv6 prefix
>>     every time they are rebooted. Note: even in locations where
>>     utility power is generally stable, power outages frequently occur
>>     in clusters over a few hours or days.  This occurs when an
>>     emergency repair is made to restore power and then more permanent
>>     repairs cause short outages in the following hours or days. In
>>     this scenario, each of these events in the cluster SHOULD NOT
>>     result in the CPE receiving a different IPv6 prefix.
>>
>>     Conversely, when widespread power events occur, affecting
>>     thousands or even tens of thousands of customers, it may not be
>>     practical or even possible for an ISP to guarantee all CPE will
>>     receive the same IPv6 prefix they had before. Therefore to the
>>     extent possible, CPE and local networks SHOULD be resilient to
>>     their ISP provided IPv6 prefix changing, sometimes even
>>     unexpectedly changing.
>
>     What's the difference between what you said and "ISPs should, as
>     much as possible, reissue the same prefix to customers."?
>
>     Lee
>
>>
>>     Thanks.
>>
>>             Share lease information between redundant DHCPv6 servers.
>>             Most ISPs probably have redundant servers, since this is
>>             critical provisioning infrastructure. It may be difficult
>>             to synch information between servers for millions of
>>             leases over tens of milliseconds of latency; see RFC6853,
>>             "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP
>>             vendors can report.
>>
>>         2.
>>
>>             Aggregate above the provider edge device, so that
>>             grooming customers between Provider Edge boxes (PEs)
>>             doesn't force a renumbering. It's been a few years since
>>             I worked on CMTSs, but when I did they did not support
>>             MP-BGP well (if at all), so routes had to be aggregated
>>             on the PE, or leaked in the IGP which is bad for
>>             convergence time. Maybe PE vendors can report.
>>
>>         3.
>>
>>             Set DHCPv6 lease timers very low prior to grooming
>>             events. A short interval during the maintenance window
>>             will increase load on the DHCPv6 server until timers have
>>             been returned to normal values.
>>
>>         4.
>>
>>             working on CMTSs, this feature was not supported. Maybe
>>             PE vendors can report.
>>
>>
>>         In the case of failures, it cannot be assumed that sessions
>>         will stay active. We try to build in redundancy and
>>         resilience where we can, but where there's a single point of
>>         failure (such as CE or PE), and it fails (such as an
>>         unplanned reboot), our expectations should be appropriate.
>>
>>         Administrative Requests:
>>         https://www.ietf.org/mailman/listinfo/ipv6

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 Feb 2019 14:30:35 -0800

> On Feb 22, 2019, at 09:30 , Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 
>> On 22 Feb 2019, at 17:04, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:
> That's similar in spirit to RAmond, which we used to use when seeing rogue RAs on our campus network.  It would auto-deprecate any prefixes that shouldn't be there. (http://ramond.sourceforge.net/ <http://ramond.sourceforge.net/>)
> 

Actually, a preferred:0 valid:7200 probably would do the trick as well. It won’t salvage the sessions on the old address since they don’t route any more, but at least it will allow new sessions to use a valid address.

Owen

---

From: Ca By <[email-masked]>
Date: Fri, 22 Feb 2019 15:36:05 -0700

> I'm not sure what "provided via Tor" means.

Tor is this
https://www.torproject.org/about/overview.html.en

Tor is what people use today for address anonimity today

>
>
> > 3. CGN is not private. It throw off per session logs of every
> transaction, so this is a full click stream archived ... with varing levels
> of intentional monetization and security from hackers.
> >

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Feb 2019 14:58:40 -0800

> Tor is what people use today for address anonimity today

Thanks for the reference. It's interesting but then there's
https://www.esecurityplanet.com/open-source-security/the-trouble-with-tor.html.
In any case, I believe it's in IETF's best interest to continually
evaluate security and privacy in IP protocols. Privacy in IP
addressing seems to be an area of weakness in that regard.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 02:03:01 -0300

> Ole declared that the root cause was "misconfiguration/error".

I'm not sure that's Ole's view. Actually, it would seem to me that at
the very least he agrees that the "CPE crashes-and-reboots and network
continues using a stale prefix" is a problem to solve.

> incidentally, is inherently broken per se.

I'd disagree a bit.

e.g.,

* The current default values for the prefix lifetimes does not seem to
be the result of much of a "design choice".

* The underspecification of DHCPv6-PD/SLAAC is.. that... fault on our side

* As per RFC4862, it turns out that you cannot remove a stale prefix vy
sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards,
not even the CPEs can (even if they wanted to) do something to fix the
problem.

> long-lived enough that it probably won't cause too much difficulty.

This work was triggered from such (bad) experience by an ISP. As per a
survey referenced in our I-D, 37% of IPv6 deployment seem to offer
dynamic prefixes. The problem we are discussing may be masked via
IPv4/HE -- but I don't think we can or want to rely on that.

> to avoid the problem from happening in the first place.

May I ask why SLAAC is unfixable?

> outcome of this discussion.

Indeed.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 02:12:16 -0300

> ISPs should, as much as possible, reissue the same prefix to customers.

Actually, I think that we agreed on not to tell ISPs how to run their
networks!

[...]

Analysis of the tradeoffs between stable vs dynamic prefixes can be
valuable, as well as advice on how to achieve each of them. However,
that certainly doesn't solve the problem... and at the end of the day,
it's an ISP choice whether they do dynamic or stable prefixes. ANy such
advice should happen in a separate document.

>     DHCPv6 server until timers have been returned to normal values.

Please see the full discussion in our I-D. That said, as per RFC4862 you
cannot lower the Valid Lifetime any further than two hours. So this is,
unfortunately, mostly useless.

>     Renew for that prefix on reboot.

Ultimately, you can only improve resiliency by improving the host behaviour.

> active.

Of course.

> We try to build in redundancy and resilience where we can, but

I don't think so. Please check Sections 3 and 5 of our document. mY
working copy is at:
https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt
. Our plan is to publish a rev soon.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 02:21:28 -0300

On 22/2/19 13:44, Christian Huitema wrote:
> 
>>> Do we agree that this is indeed a bug, or do we think that having
>>> users disconnected from the Internet after a home router reboots
>>> is just a desirable feature of IPv6?
>> 
> I think that's a good summary: a problem that does not occur very
> often, but is very annoying when it does.

Everytime there's a power outage, this problem will happen. Similarly,
at least in these latitudes, whenever you call tech support at your ISP,
first question is "have you tried disconnecting and reconnecting the
router" -- that's the way most non-technical users (and also technical
users) first approach issues with their connectivity. Everytime this
happens, this problem may occur.

For the time being, as long as we have IPv4, IPv4/HE may mask the
problem. So, as long as this gets fixed before we go IPv6-only (which in
many places will not be anytime soon), that's pretty good timing to get
the problem solved.

[....]
> 
>> 
>>> Do we agree that the working group should actually start working
>>> on some improvement in SLAAC that would mitigate the issue? Not
>>> excluding of course solutions that would also mitigate related
>>> egress filtering issue?
>> 
>> least one person was of the opinion that SLAAC was basically
>> unfixable in this regard.  This ignores whether it would be useful
>> or viable for the IETF to issue advice to CPE vendors and service
>> providers about how to avoid the problem from happening in the
>> first place.
> 
> Anything we do in this space can take a long time to roll out, but it
> does not take forever.

Indeed. As one datapoint, we published RFC8064 in early 2017. And even
mid 2018 if you were to install a fresh copy of a modern OS, in most
cases it would implement RFC8064/RFC7217.

Particularly when you get implementers in the loop, and when they
realize that stuff makes sense, things don't take that long.

> In many cases it probably takes less time than
> it takes to agree on a potential solution in the IETF. For example,
> security bugs in operating systems can get patched in a matter of
> weeks or maybe months. Not all devices can be patched quickly, but
> many can.

Agreed.

> As usual, we don't want to see creative solutions popping in
> different devices. A common standard seems preferable. So, if a
> subset of the working group wants to work on the solution, we should
> be happy to let them do that.

Exactly. Some of those solutions have already popped (see the FRITZ
reference in our I-D). Ignoring the problem is simply asking for more
(and worse)

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 02:25:22 -0300

On 22/2/19 14:43, Timothy Winters wrote:
> 
> 
> On Fri, Feb 22, 2019 at 12:30 PM Tim Chown <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
[....]
>>
>>     If the prefix is written to nv men, wouldn’t it also be possible
>>     for implementers to send rapid deprecation RAs for any prefix not
>>     renewed?
>>
>>     In other words, after reboot, try to reacquire same prefix. If
>>     that doesn’t work, when you advertise the new prefix, you could
>>     also include the old prefix with a very short preferred and valid
>>     lifetime (e.g. 1 second) in the first RA, which should be sent to
>>     the all nodes on link multicast?
>>
>>     would be barley noticeable amid the minute or so it takes most
>>     home gateways to reboot. 
> 
>     That's similar in spirit to RAmond, which we used to use when seeing
>     rogue RAs on our campus network.  It would auto-deprecate any
>     prefixes that shouldn't be there. (http://ramond.sourceforge.net/)

IIRC, ramond debrecates the default router, not the advertised prefixes....

>     second, given the 7200 second (2 hour) minimum defined in RFC 4862
>     (unless the RA is authenticated, somehow).  The preferred timer can
>     be zero.  When RAmond was written, if we used a valid timer less
>     than 7200 seconds it seemed that the deprecating RAs were ignored. 
>     That was 10+ years ago though.  Perhaps Tim Winters has data on
>     whether that rule is implemented today in practice; I'd assume the
>     tests he runs might include that.  
> 
> address was higher then gets a low value (such as 1).   Currently there
> is no way to make it less then two hours if a Rogue RA gets out and
> gives out a longer address lifetime.

Yep. As per RFC4862.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 05:20:40 -0300

> We're kind of arguing the definition of "possible," I think.

We can (in a different, unrelated document, that has nothing to do with
the problem we are discussing :-) ) discuss trade-offs between stable vs
dynamic prefixes, and provide advice on how to achieve each.

Mandating one or the other is, at best, unrealistic. -- but not as much
as expecting to solve the problem being discussed by having ISPs to
change their existing deployments according to a "mandate" from our side....

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Feb 2019 08:00:00 -0500

So, who’s going to summarize this discussion in a presentation at IETF, and
will it be in 6man or v6ops?

---

From: Lee Howard <[email-masked]>
Date: Sat, 23 Feb 2019 09:34:16 -0500

⁣Sent from BlueMail ​

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 14:22:43 -0300

On 23/2/19 10:00, Ted Lemon wrote:
> So, who’s going to summarize this discussion in a presentation at IETF,
> and will it be in 6man or v6ops?

It is extremely likely that I will be requesting agenda myself for 6man.

If the v6ops chairs think it makes sense to do/present something in
v6ops, I'd be happy too.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Feb 2019 14:07:29 -0500

> If the v6ops chairs think it makes sense to do/present something in

Great, thanks!

---

From: Richard Patterson <[email-masked]>
Date: Mon, 25 Feb 2019 10:32:54 +0000

> not even the CPEs can (even if they wanted to) do something to fix the

The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
the Preferred Lifetime can.  So we can't invalidate the prefix, but we
can deprecate it so it's not used for new outbound sessions.   This is
what we've implemented in our CPEs, after an unavoidable change in
prefix, and it seems to have mitigated (or reduced the impact of) the
issue.

RFC4862 §5.5.3

e)  If the advertised prefix is equal to the prefix of an address
      configured by stateless autoconfiguration in the list, the
      preferred lifetime of the address is reset to the Preferred
      Lifetime in the received advertisement.

....

      Note that the preferred lifetime of the corresponding address is
      always reset to the Preferred Lifetime in the received Prefix
      Information option, regardless of whether the valid lifetime is
      also reset or ignored.  The difference comes from the fact that
      the possible attack for the preferred lifetime is relatively
      minor.  Additionally, it is even undesirable to ignore the
      preferred lifetime when a valid administrator wants to deprecate a
      particular address by sending a short preferred lifetime (and the
      valid lifetime is ignored by accident).

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Feb 2019 23:56:57 +1100

> prefix, and it seems to have mitigated (or reduced the impact of) the

It seems the Ubiquity Networks community have discovered the
DeprecatePrefix option of 'radvd' and are suggesting its use to mitigate
this issue.

https://community.ubnt.com/t5/EdgeRouter/Solution-for-client-losing-IPv6-connectivity-after-PPPoE-re/td-p/2019416

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Feb 2019 22:27:02 +0900

>       Lifetime in the received advertisement.

Have we considered simply removing this paragraph and allowing routers to
send RA lifetimes of 0? On an IPv6-capable network, an attacker that is
able to send RAs can do way more damage than just this sort of DOS attack -
they can collect/monitor traffic, selectively block destinations or
sources, etc. etc.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 25 Feb 2019 12:42:18 +0000

> > * As per RFC4862, it turns out that you cannot remove a stale prefix
> > vy sending an RA wiht a "Prefix Lifetime" of 0. SO, with current
> > standards, not even the CPEs can (even if they wanted to) do something
> > to fix the problem.
> 
> 
> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but the
> Preferred Lifetime can.  So we can't invalidate the prefix, but we
> what we've implemented in our CPEs, after an unavoidable change in prefix,
> and it seems to have mitigated (or reduced the impact of) the issue.
> 
> RFC4862 §5.5.3
> 

Per RFC 7084:
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero or b) the lower of the current
          Valid Lifetime and two hours (which must be decremented in
          real time) in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].

Barbara

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Feb 2019 15:29:40 -0300

Hello, Lorenzo,

On 25/2/19 10:27, Lorenzo Colitti wrote:
> On Mon, Feb 25, 2019 at 7:33 PM Richard Patterson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Have we considered simply removing this paragraph and allowing routers
> to send RA lifetimes of 0? On an IPv6-capable network, an attacker that
> is able to send RAs can do way more damage than just this sort of DOS
> attack - they can collect/monitor traffic, selectively block
> destinations or sources, etc. etc.

I completely agree.

And yes, we have considered that and will be incorporating that in the
next rev of the I-D.

If you want to peek at my working copy (upcoming version -02), it is
available at:
https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt
   (Section 5.1.1.2 proposes this, with the same rationale you suggested
above).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Feb 2019 15:36:23 -0300

> prefix, and it seems to have mitigated (or reduced the impact of) the

Agreed. That said, with the current default lifetime values, things
become tricky:
At least in theory, you should be sending such RAs for "Valid Lifetime"
seconds. With a default of one month, that means that, in theory, you
should be sending such RAs for a month. And if there are multiple
crash-and-reboot events, you should advertise each of the stale
prefixes. (I assume the CPE just records the last one)

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Feb 2019 09:17:03 +0000

> On 25 Feb 2019, at 18:36, Fernando Gont <[email-masked]> wrote:
> 

When / where was the default Valid Lifetime chosen to be one month?

Tim

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 06:33:44 -0300

Hi, Tim,

> When / where was the default Valid Lifetime chosen to be one month?

Section 6.2.1 of RFC 4861:

      AdvPrefixList
                     A list of prefixes to be placed in Prefix
                     Information options in Router Advertisement
                     messages sent from the interface.

                     Default: all prefixes that the router advertises
                     via routing protocols as being on-link for the
                     interface from which the advertisement is sent.
                     The link-local prefix SHOULD NOT be included in the
                     list of advertised prefixes.

                     Each prefix has an associated:

                        AdvValidLifetime
                             The value to be placed in the Valid
                             Lifetime in the Prefix Information option,
                             in seconds.  The designated value of all
                             1's (0xffffffff) represents infinity.
                             Implementations MAY allow AdvValidLifetime
                             to be specified in two ways:

                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified time
                                 in the future, or

                               - a fixed time that stays the same in
                                 consecutive advertisements.

                             Default: 2592000 seconds (30 days), fixed
                             (i.e., stays the same in consecutive
                             advertisements).

Cheers,

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Feb 2019 10:06:24 +0000

> On 26 Feb 2019, at 09:33, Fernando Gont <[email-masked]> wrote:
> 

So given that document is 12 years old, with that default copied from one that is 21 years old, is an update required?  

And if so, to what?

Tim

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Feb 2019 11:13:47 +0100

Fernando,

>                             (i.e., stays the same in consecutive

Red herring.

RA lifetimes cannot be longer than the DHCP PD lifetimes.
In the DHCP PD case they should also be counted down in real time.
And the lifetimes can be dynamically adjusted.

Cheers,
Ole

---

From: Richard Patterson <[email-masked]>
Date: Tue, 26 Feb 2019 10:35:21 +0000

> prefixes. (I assume the CPE just records the last one)

I get your reasoning, but I'm not sure if it's quite as dire as that,
a single RA update with PrefLifetime of 0 should in theory suffice,
but then we get in to discussing the reliability of ICMPv6 messaging.
(as you have done in draft-gont-6man-slaac-renum-02 )

In my head, an address with the higher Preferred Lifetime should be
selected over one with a lower value, however I couldn't find any
recommendation as such in RFC6724, is this stipulated anywhere else?
 If not, would an update to 6724 that introduces a Preferred Lifetime
comparison as a tie-breaker help?  i.e. When deciding between multiple
non-deprecated source addresses, always pick the address with the
highest Preferred Lifetime?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 07:39:23 -0300

> So given that document is 12 years old, with that default copied from one that is 21 years old, is an update required?  

That's my take.

> And if so, to what?

At the very least, never larger than the "Router Lifetime". Please see:
https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt
 (particularly Section 5.1.1)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 07:43:00 -0300

> RA lifetimes cannot be longer than the DHCP PD lifetimes.

I don't disagree with you.

> And the lifetimes can be dynamically adjusted.

They should. However, quite frequently the DHCPv6-PD part is a different
piece of software from the ra{d,dvd} part. Both pieces are glued by some
script, and the lifetime is *not* dynamically adjusted.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 07:58:34 -0300

Hello, Richard,

> (as you have done in draft-gont-6man-slaac-renum-02 )

That aside, if you don't get rid of the addresses/routes, you could not
communicate with the new "owners" of the addresses/prefixes.

> recommendation as such in RFC6724, is this stipulated anywhere else?

It is not.

> highest Preferred Lifetime?

Not really. If you were to follow that road, then fore each
prefix/router you should keep a new "Last Advertised" timer and use that
as a tie breaker.  Using the Preferred Lifetime would not be safe since,
while there are default values, you don't really know what values the
CPE will use for them.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 Feb 2019 22:09:07 +1100

> script, and the lifetime is *not* dynamically adjusted.

There is a knob in 'radvd' to do and suit that, the PD triggered/driven
script just needs to do a bit of radvd.conf modification, stopping,
starting, and signalling.

*DecrementLifetimes* *on*|*off*

This option causes radvd to decrement the values of the preferred and valid
lifetimes for the prefix over time. The lifetimes are decremented by the
number of seconds since the last RA. If radvd receives a SIGUSR1 signal, it
will reset the values of the preferred and valid lifetimes back to the
initial values used by radvd when it started. If radvd never receives a
SIGUSR1 signal, it will continue to decrement the lifetimes until the
preferred lifetime reaches zero. After a final RA with a zero value
preferred lifetime, radvd will cease to announce the prefix. If a SIGUSR1
signal then causes the lifetimes to be reset, the prefix will then
re-appear in the RAs.

This option is intended to be used in conjunction with a DHCPv6 client that
is using the Identity Association for Prefix Delegation (IA_PD) option to
acquire a prefix from a Delegating Router for use by a Requesting Router.
In this scenario, the prefix(es) from within the delegated prefix that are
announced by radvd would age in parallel with and at the same rate as the
delegated prefix, and expire at approximately the same time, if the
delegated prefix's life isn't extended.

See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol
(DHCP) version 6".

Default: off

---

From: Richard Patterson <[email-masked]>
Date: Tue, 26 Feb 2019 11:16:52 +0000

> while there are default values, you don't really know what values the

I don't think that or anything else is required to change on the CPE
router.  The onus is on the end host to track the Preferred Lifetime
counter (it already does), and to adjust its source address selection.
  It doesn't really matter what the default values are, as long as the
CPE router continues to send out RAs with that PIO to keep the timer
refreshed.

Although what I do think might be an issue is in a multi-homed
environment, an end host might flip flop outgoing connections between
prefixes depending on which PIO was refreshed last.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Feb 2019 07:53:58 -0500

> script, and the lifetime is *not* dynamically adjusted.

Yes, that script you mention was a quick hack to make it work from 2007.
I think that we can do (and can require) people to do better today.

From what I understand, OpenWRT already does better, having integrated both
sides into one program.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2019 14:31:07 +0100 (CET)

> script, and the lifetime is *not* dynamically adjusted.

In OpenWrt they are, and I definitely think this should be the default.

I also tries to deploy two upstreams in my home and this failed because 
the lifetime of my less preferred ISP was higher than my most preferred 
ISP, which meant the one with the highest lifetime was always used.

So there should be some kind of configurable cap that the HGW uses, so 
that this isn't a problem. It might also make sense to not have 24 hour or 
a week lifetimes on the LAN, even if the PD leasetime is this high. But 
these are two different problems, and I would like to see the LAN 
lifetimes lowered to more sane values, so that it's capped to 24 hours 
max. Maybe it should be even lower.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2019 23:19:56 +0900

On Tue, Feb 26, 2019 at 7:59 PM Fernando Gont <[email-masked]> wrote:

> > So given that document is 12 years old, with that default copied from
> one that is 21 years old, is an update required?
>
> That's my take.
>
> > And if so, to what?
>

Disagree that prefix lifetimes must never be larger than the router
lifetime, particularly because 0 is a perfectly valid default lifetime.

Also looking at section 5.1.1, the default MaxRtrAdvInterval of 5 minutes
violates the best practices in RFC 7772.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2019 23:27:46 +0900

FWIW, from a host implementer perspective, DecrementLifetimes is a bad idea
since it makes it harder to drop duplicate RAs in firmware and thus has
substantial battery impact.

True story: many ISP routers use a maximum advertisement interval of 3
seconds in order to fix unreachability and IPv6 brokenness problems. In
order to avoid draining the battery after 12 hours of this, phone
manufacturers reacted by either dropping all RAs (or even all IPv6
packets!) when the screen is off, or putting RA filtering in firmware. Then
some routers decided to use DecrementLifetimes as well. Firmware RA
filtering couldn't match the RAs any more and the phone manufacturers
probably reacted by dropping all RAs again.

In order to fix this problem on Android we had to write a bytecode
interpreter and get wifi chipset manufacturers to insert it into their
firmware so we could push filtering rules to the chipset at runtime. Many
chipset manufacturers still haven't adopted this though.

Please don't do this if you care about mobile devices having correct IPv6
implementations and acceptable battery life.

On Tue, Feb 26, 2019 at 8:09 PM Mark Smith <[email-masked]> wrote:

> This option causes radvd to decrement the values of the preferred and
> valid lifetimes for the prefix over time. The lifetimes are decremented by
> the number of seconds since the last RA.. If radvd receives a SIGUSR1
> signal, it will reset the values of the preferred and valid lifetimes back
> to the initial values used by radvd when it started. If radvd never
> receives a SIGUSR1 signal, it will continue to decrement the lifetimes
> until the preferred lifetime reaches zero. After a final RA with a zero
> value preferred lifetime, radvd will cease to announce the prefix. If a
> SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then
> re-appear in the RAs.
>
> This option is intended to be used in conjunction with a DHCPv6 client
> that is using the Identity Association for Prefix Delegation (IA_PD) option
> to acquire a prefix from a Delegating Router for use by a Requesting
> Router. In this scenario, the prefix(es) from within the delegated prefix
> that are announced by radvd would age in parallel with and at the same rate
> as the delegated prefix, and expire at approximately the same time, if the

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 12:51:38 -0300

Hello, Lorenzo,

On 26/2/19 11:19, Lorenzo Colitti wrote:
> On Tue, Feb 26, 2019 at 7:59 PM Fernando Gont <[email-masked]
>     > So given that document is 12 years old, with that default copied
>     from one that is 21 years old, is an update required? 
> 
>     That's my take.
> 
>     > And if so, to what?
> 

How does a Lifetime of 0 fit in RFC8028?

> Also looking at section 5.1.1, the default MaxRtrAdvInterval of 5
> minutes violates the best practices in RFC 7772.

Thanks for the pointer!

Looking at RFC7772, it says:

      Thus, the minimum lifetimes for
      RA configuration parameters such as default router lifetime might
      reasonably be 5-10 times the RA period, or roughly 45-90 minutes.

Question: I'm trying to parse this paragraph. It would seem that, in
order to ahve an appropriate RA frequency, you need to have a Default
Router Lifetime of 45-90 minutes, but the default is actually 30 minutes.

Am I missing something?

And, how do you get the 45'-90' numbers?

FWIW, with the default values in RFC4861 you get, for the *average*
case, ~ 6.6 RAs /hour, and a DEfault Lifetime of 30 minutes...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 13:07:45 -0300

Hello, Lorenzo,

On 26/2/19 11:27, Lorenzo Colitti wrote:
> FWIW, from a host implementer perspective, DecrementLifetimes is a bad
> idea since it makes it harder to drop duplicate RAs in firmware and thus
> has substantial battery impact.

Well... it would be incorrect for these Lifetime values to span past the
DHCPv6-PD lease time --- so either you set the lifetimes to a small
value (that is never larger than the DHCPv6 lease time, and hence can be
constant), or you have to dynamically adjust the Lifetimes.

If you're filtering RAs in firmware, it would seem to me that the first
option would be better.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Feb 2019 10:50:57 -0600

On Fri, Feb 22, 2019 at 4:59 PM Tom Herbert <[email-masked]> wrote:

> >> > 2. Network address annonimity today is generally provided via Tor.
> How could the ietf provide something better than existiting tor solutions,

+1

We with Dirk are pursuing this kind of activity in pidloc list
[email-masked] more in the context of Identifier locator separation
protocol context.
Please join pidloc.

 Regards,
Behcet

---

From: 神明達哉 <[email-masked]>
Date: Tue, 26 Feb 2019 09:16:25 -0800

At Tue, 26 Feb 2019 07:43:00 -0300,

> script, and the lifetime is *not* dynamically adjusted.

It's a clear violation of Section 18.2.10.1 of RFC8415:

      If the client uses a delegated prefix to configure addresses on
      interfaces on itself or other nodes behind it, the preferred and
      valid lifetimes of those addresses MUST be no longer than the
      remaining preferred and valid lifetimes, respectively, for the
      delegated prefix at any time.  In particular, if the delegated
      prefix or a prefix derived from it is advertised for stateless
      address autoconfiguration [RFC4862], the advertised preferred and
      valid lifetimes MUST NOT exceed the corresponding remaining
      lifetimes of the delegated prefix.

while we cannot completely ignore non-compliant implementations (if
any) in practice, IMO the existence of violators shouldn't be the
primary reason for tweaking the protocol.

Besides, I'm actually not so sure if it's so difficult to comply with
today's tools.  RFC4861 has the concept of dynamically decrementing
the advertised lifetimes as a protocol parameter (with a MAY):

                        AdvValidLifetime
[...]
                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified time
                                 in the future, or
[...]
                        AdvPreferredLifetime
[...]
                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at a specified time in
                                 the future, or

and I suspect that non-negligible number of implementations support
this concept.  BSD's rtadvd does, apparently so does Linux radvd.
For these implementations, it's just a matter of configuration, even
if the DHCP-PD client and RA advertisement are implemented as
different pieces of software: a "script" takes the lifetimes from
DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes to
that values that decrement in real time.

I don't necessarily oppose to the idea of revising the default prefix
lifetimes currently specified in RFC4861.  The growing deployment of
mobile environments may justify an update, for example.  But the
discussion should be based on accurate understanding of what's
possible with the current specification and actual implementations,
rather than speculative "red herring".

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 14:35:20 -0300

Hello, Jinmei,

On 26/2/19 14:16, 神明達哉 wrote:
> Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 

Which specific tweak are you referring to?

> that values that decrement in real time.

I haven't been following developments in this area... but I do remember
 scripts to put the two pieces together, and others doing the same.

> rather than speculative "red herring".

Tee only thing that I mentioned is that the CPE should be prepared to
"deprecate" a prefix for "Valid Lifetime". -- a local ISP recently
reported that they employ DHCPv6-PD times of over a month. IN those
cases, the spec you reference is complied with, and what I mention above
is the case: -- if there-s a carsh-and-reboot scenario, the CPE should
(in theory) be prepared to deprecate a prefix for "Valid LIfetime". --
whether in practice you can get away with firing a few RAs is a
different thing.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 26 Feb 2019 11:13:29 -0800

At Tue, 26 Feb 2019 14:35:20 -0300,

> Which specific tweak are you referring to?

Changing the default value of AdvPreferredLifetime and
AdvPreferredLifetime currently defined in in RFC4861.

>> For these implementations, it's just a matter of configuration,
>> even if the DHCP-PD client and RA advertisement are implemented as
>> DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes
>> to that values that decrement in real time.

> scripts to put the two pieces together, and others doing the same.

The question is specifically how those script put the pieces together.
As long as the "RA piece" supports the "decrement in real time" part
of RFC4861, not using it is a mere bug of those scripts (in that it at
least violates Section 18.2.10.1 of RFC8415).  My point here is that
the existence of buggy implementation (if it exists at all) doesn't
seem to be a strong justification of updating the spec.

> whether in practice you can get away with firing a few RAs is a

In that case I'd rather see a point in what Ole keeps saying: either
the ISP should use a much shorter DHCPv6-PD prefix lifetimes in the
first place or they shouldn't change the delegated prefix.  I'm not
saying this to argue there's nothing we can/should do for such a broken
operation.  But this case seems weak as a justification to change the
default lifetime values in RFC4861.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Feb 2019 03:45:00 -0300

> AdvPreferredLifetime currently defined in in RFC4861.

The rationale for that it's what's in the I-D, namely:

   RATIONALE:

      *  In the context of [RFC8028], where it is clear that use of
         addresses configured for a given prefix is tied to using the
         next-hop router that advertised the prefix, neither the
         "Preferred Lifetime" or the "Valid Lifetime" of a PIO should
         never be larger than the "Router Lifetime" (AdvDefaultLifetime)
         of Router Advertisement messages.

      *  As a result, this document updates [RFC4861] such that the
         default Valid Lifetime (AdvValidLifetime) and Preferred
         Lifetime (AdvPreferredLifetime) of PIOs are specified as a
         function of the "Router Lifetime" (AdvDefaultLifetime) of
         Router Advertisement messages.

      *  This document reduces the maximum time between unsolicited RAs
         (MaxRtrAdvInterval), which indirectly specifies the minimum
         time between unsolicited RAs (MinRtrAdvInterval) and the Router
         Lifetime (AdvDefaultLifetime), to improve the ability of hosts
         to recover from fault scenarios.

      *  Lacking RAs that refresh information, addresses configured for
         advertised prefixes become un-preferred in a timelier manner,
         and thus Rule 3 of [RFC6724] causes other configured addresses
         (if available) to be used instead.

      *  Reducing the Valid Lifetime and Preferred Lifetimes of PIOs
         limits the amount of time hosts may use stale prefixes, and
         also limits the amount of time that a stale prefix needs to be
         advertised with a lifetime of "0" on the local network (see
         Section 12 of [RFC4861]).

[....]
> seem to be a strong justification of updating the spec.

Agreed. As noted above, *that* is *not* the motivation.

> the ISP should use a much shorter DHCPv6-PD prefix lifetimes in the

in the order of... how many minutes?

> default lifetime values in RFC4861.

The justification is noted above.  Regarding "broken operation"... the
survey referenced in our I-D notes that 37% of the surveyed ISPs do
dynamic prefixes. Blaming the ISPs is not really going to improve user
experience...

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Feb 2019 08:38:00 -0800

> On Feb 26, 2019, at 02:35 , Richard Patterson <[email-masked]> wrote:
> 

I think you’re leaving out the fact that there are two lifetimes…

There’s a preferred lifetime and a valid lifetime.

I’d argue that a prefix which is no longer valid on the link should
(ideally) be advertised for some period with a valid_lifetime of 0.
After all, if the prefix is no longer valid, there’s no benefit whatsoever
to allowing hosts on the link to continue to believe that it is, regardless
of the amount of time remaining in the timer on a previous RA.

I believe (someone will surely correct me if I am wrong) that a host
receiving an RA with different lifetime values is obliged to apply those
new values overriding any time remaining on the old values, regardless
of whether that increases or decreases the remaining time in the
lifetime values.

As such, 

> highest Preferred Lifetime?

Selected for what? Source of a new session originated from the host?

(That’s the only case of selection I can think of). That’s governed by the
source address selection rules in RFC-6724 (obsoletes RFC-3484) in
the case where the application doesn’t bind a specific source address
to the socket. In the case where the application does bind a specific
source address, then, the source address selection methodology is
entirely in the hands of the application developer and/or any runtime
configuration said developer chooses to consider.

I guess all else described in RFC6724 being equal, one could use
longest remaining preferred lifetime as a tie-breaker, but I have yet
to encounter a network where you would reach such a tiebreaker
without arriving at a single prefix first by another method.

I do think it might be worth considering a change to how hosts process
Was wherein we keep track of the address of the router from which we
received the lifetime values currently being counted down and if we
receive a new RA from the same router that no longer includes
one of the prefixes we are counting down, we reduce the preferred
lifetime to zero while continuing to count down the valid lifetime.

I’m hard pressed to think of harm that comes from an invalid prefix
remaining on an interface so long as it is not preferred in most cases.
The one case that comes to mind is that hosts retaining that prefix
will be unable to reach hosts to which that prefix has been newly
assigned while they still retain it as a valid prefix.

Owen

---

From: Richard Patterson <[email-masked]>
Date: Wed, 27 Feb 2019 18:20:48 +0000

Hi Owen,

> There’s a preferred lifetime and a valid lifetime.

The valid lifetime was intentionally omitted from my response as we
previously discussed that it cannot be lowered below 2 hours or the
RemainingLifetime.

> of whether that increases or decreases the remaining time in the

As above, we can deprecate the use of a prefix with Preferred Lifetime
today, but to do the same with Valid Lifetime would require updating
4862.
Fernando documents this in 3.2 here:
https://raw.githubusercontent.com/fgont/draft-slaac-renum/master/draft-gont-6man-slaac-renum-02.txt
The second bullet-point in 3.2 triggered the below thought on how else
we could work-with-what-we've-got (the source address selection
process), to make things more robust.

> Selected for what? Source of a new session originated from the host?

Yes, I did include RFC6724 for context. :)

> lifetime to zero while continuing to count down the valid lifetime.

This is just a passive host-side version of the above approach. This
would still require changing all end-host behaviour, where the above
(sending an RA with PIO Preferred Lifetime 0) can be done centrally on
the CPE today without any change to current behaviour of the
end-hosts.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 27 Feb 2019 11:02:03 -0800

At Wed, 27 Feb 2019 03:45:00 -0300,

> The rationale for that it's what's in the I-D, namely:

To be clear, I didn't oppose to the idea of this change.  I just
pointed out that the existence of buggy "script" didn't seem to be
a convincing reason for the change.  My interpretation of this message

https://mailarchive.ietf.org/arch/msg/ipv6/Fa89c-WmpEzBFqnpcZQsTZ5q2Z8

is that it's in the context of changing the default value of
AdvPreferredLifetime and AdvPreferredLifetime, referring to the
DHCP-PD CPE case.  Ole pointed out it's a red herring, and you

>> script, and the lifetime is *not* dynamically adjusted.

This looked to me like that we should consider changing the default
AdvXXXLifetimes because of this (buggy) piece of software.  It didn't
make much sense to me, hence my comment.

> dynamic prefixes. Blaming the ISPs is not really going to improve user

I don't think we are on different pages regarding "blaming the ISPs" -
see my second sentence above.  It's all about whether that can justify
changing a particular part of the protocol.

BTW, in the original context of changing the default of
AdvXXXLifetimes, it wouldn't help anyway against the mixture of broken
ISP operation and buggy piece of software: regardless of the protocol
default, that piece of software would simply copy the delegated prefix
lifetimes and keep using them.

--
JINMEI, Tatuya