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

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 1 Feb 2019 19:14:35 +0100

Hi,

On 31/01/2019 13:11, Fernando Gont wrote:
>> Doesn't RFC7084 already say this? L-13.
> 
> Yes, and we missed this (thanks!). -- that said, we added this bullet
> for completeness sake. The case we care about in this doc is the reboot
> scenario.

However, RFC7084 is Informational and not Standard. I think this should 
make it into Standard. I've seen many CPE vendors saying "we found 
relevant standard documents and implemented whatever was a MUST and 
shipped the product."

A bit irresponsible in my view, but still a "valid" behaviour.

That being said - we need to be cautious that most probably just a MUST 
requirements will make it into CPEs at the end of the day.

>> 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...

Exactly. We've observed all possible sort of behaviour in different 
stack implementations and lifetime is rarely taken into account.

If lifetime is > 0 then the address is valid, if lifetime == 0 then it's 
invalid and removed.

Not very useful in our case ;)

>> So while I am generally sympathetic to this draft and what it tries to
>> achieve (especially the part where it ties the router announcing
>> something to what it's later announcing, and lack of something means
>> it's implicitly zero preferred time for that), we need to figure out a
>> few more things first. RFC7084 was informational which made it fairly
>> easy to get through, now you're proposing a standards track document so
>> we need to make sure everything works. Changing all hosts is a big thing.
> 
> FWIW, I personally think the way to go is the host-side fix. You do want
> hosts to get smarter about this, and obviously cannot rely on the CPE to
> solve this for you.

Both places needs to be fixed. At the end of the day - CPE is in most 
cases your only device that is forwarding/routing packets towards the 
world and you need to rely that even old and ancient devices behind it 
can still function properly.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 1 Feb 2019 19:19:03 +0100

On 31/01/2019 13:12, Mikael Abrahamsson wrote:
> On Thu, 31 Jan 2019, Sander Steffann wrote:
> 
>> A flash cell is at least capable of 1000 to 3000 erase/write cycles. 
>> Even if the prefix would change every single day that gives a lifetime 
>> of 3 to 9 years. And prefixes shouldn't change that often anyway. When 
>> looking at more realistic estimates line a change on average once a 
>> week you'l get to 20 years. Seems more than enough for low end extra 
>> cheap devices. I don't see this driving cost up, except for spending a 
>> few hours on properly engineering this.
> 
> There are places where they flap your WAN (PPPoE session for instance) 
> every day to renumber you. I have personally experienced this.
> 
> So it might be possible to do what you're saying but only writing 
> partial information of the prefix, so skip writing lifetimes, and just 
> keep the actual prefix. This is not what a typical DHCP server/client 
> does today, it re-writes the file every time the lease is renewed so it 
> knows about it. Some kind of compromise might be where a "hint" file is 
> written and the only time this is re-written is when the prefix is changed.

This is basically the idea. Write PD when first received, read when 
received again, compare, if not the same -> send RAs with lifetime 0 and 
write new prefix to that storage. Easy ;)

Cheers, Jan

---

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: Michael Richardson <[email-masked]>
Date: Sat, 02 Feb 2019 12:19:00 -0500

Jan Zorz - Go6 <[email-masked]> wrote:
    >> for completeness sake. The case we care about in this doc is the
    >> reboot scenario.

    > However, RFC7084 is Informational and not Standard. I think this should

Additionally, when it comes to what the CPE can expect from the ISP, 7084 is
essentially a set of heuristics, and there is no document about what the
*ISP* can expect from the CPE.

We need to turn both in standards, with a clear palette of behaviours.

For instance, I'd like to see standardized support for:
Scenario A:
   a) do *not* number the PPP(oE) link in IPv6. (use LL only)
   b) ISP delegates /60 or bigger and the CPE uses an address out of it.

Scenario B:
   a) do *not* number the PPP(oE) link in IPv6. (use LL only)
   b) ISP delegates exactly a /64, and the CPE uses an address out of it,
      and uses the rest for tethering, single link.

Scenario C:
   a) number the PPPoE link with RA and/or DHCPv6.
   b) Use rfc6603 to clearly exclude the link prefix

Scenario D:
   a) number the link with a /64
   b) provide another /60+ if the CPE asks for it later on.

For ISPs, there is a major win to having the all of the customer prefixes in
a single prefix (routing entry), but it's hard to know which scenario is
going to occur.

There is not enough in RFC7084 for an ISP to provide requirements to PPPoE
termination vendors (DSLAM) or to CPE vendors.    In the work I did at
Finepoint, I basically had to invert 7084 to make my requirements, but I
couldn't be sure what CPEs would support which scenarios.

The Broadband Forum TR-187 is useful, but still has too much wiggle room.

I would be willing to co-author a document.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 02 Feb 2019 19:42:32 +0100

When I started the work in RFC7084-bis (now draft-ietf-v6ops-transition-ipv4aas, waiting for the final IESG "go"), I was always thinking that it must become a standard, but the discussions in the WG didn't went that way.

I will be happy also to co-author if more work is needed in this direction.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Michael Richardson <[email-masked]>
Fecha: sábado, 2 de febrero de 2019, 18:19
Para: Jan Zorz - Go6 <[email-masked]>
CC: <[email-masked]>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    

    
    Scenario B:
    
    Scenario C:
    
    Scenario D:

    

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

**********************************************
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: 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.
> 
> --

---

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.

---

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: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 11:54:19 +0100

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

Ole, in theory, I agree with you.

In practice - "if it hurts, stop doing it" means that ISPs declares IPv6 
as not functioning and switch it off for good.

Is this what we want?

CPE power-cycle is something that ISP has no control of. Now, if 
provisioning vendors would play our game, then they would never 
implement a provisioning mechanism that allows flash renumbering, as you 
call it.

Ole, I would ask you a favour. Can you ask internally at your employer 
why provisioning at BRAS allows creating "pools" of IPv6 addresses and 
dynamic prefix delegations? Basically, this is the core root of a 
problem and if we can fix it in provisioning platforms, then we are all 
set and there is no need for changing CPE or host.

But I'm afraid that the answer that you'll get will be "customers 
demanded this and we had to implement it". Money talks. Do you think we 
can change that? Talk VendorC, VendorJ, VendorX and all others into 
turning their behaviour into one that actually give ISPs even an option 
to honour their "contract" with a customer, even in case of unintended 
event with the CPE?

Should we write a Standard RFC that neatly defines all the MUSTS for 
provisioning platforms?

If yes - good. If not - then we have to change the host and CPE.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 11:58:20 +0100

> *ISP* can expect from the CPE.

Hey,

I think that this is partially described in RIPE-690 BCP document.

>     b) provide another /60+ if the CPE asks for it later on.

Maybe we can combine the wisdom agreed by operators in RIPE-690 and 
specify it in more detailed way, as you propose above.

> a single prefix (routing entry), but it's hard to know which scenario is

This one is the most optimal possible, but now we need CPE vendors to 
start supporting it.

> I would be willing to co-author a document.

Excellent!!! Please, read RIPE-690 and see if we can get something out 
of there as a start ;)

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 11:58:52 +0100

> I will be happy also to co-author if more work is needed in this direction.

Excellent!!!

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:01:11 +0100

Dear Fred,

On 03/02/2019 04:47, 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...

I'm not sure that my grandmother would be able to do that, nor I'm 
convinced that many other average Internet users would be interested in 
all this hassle :)

Internet access is becoming a simple utility that people use, let's keep 
it that way...

Cheers, Jan

>>> 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....
>> 
>> 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.
>> 
>> 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]
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:10:47 +0100

On 03/02/2019 13:27, Ole Troan wrote:
>> Ideally, the CPE will advertise that the contract is void. But it
>> is 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.
Ok, so this is clear. As already suggested - should we write a Standards 
document for provisioning providers vendors and say that they MUST only 
write code that can sets a prefix lifetime to something longer than the 
lifetime of their business contract with their customer and also that 
they MUST NOT allow operators to assign to their customers a different 
prefix during that lifetime and break their contract with this?

This would be an easy fix. Number of provisioning providers vendors is 
much smaller than CPE providers and hosts to fix on the planet. :)

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:18:26 +0100

On 03/02/2019 17:01, Fernando Gont wrote:
> are not valid anymore. 

...and this described behaviour is already implemented in Fritz Box CPEs 
and is solving this issue in real life on real networks.

Running code? There you have it, and not just running code - it's 
production. We just need others to do the same, hence the Standards 
document.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:24:10 +0100

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

100% agree and I've been saying this to all government types of folx 
that tried to persuade me about privacy enhancements of changing the 
prefixes regularly (that was a good laugh, btw ;) )

Until end host has a completely unique digital footprint (regardless of 
what IP they are coming from), changing addresses and prefixes doesn't 
help with anything.

See https://panopticlick.eff.org/ for more explanation and test your 
digital footprint ;)

> are virtual, e.g. PPPoE, rather than physical.

So, in other word - again - we need to fix and standardize provisioning 
vendors to limit the set of options that providers have in order not to 
break their customers IPv6.

Is that what I hear from your words?

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:27:51 +0100

On 03/02/2019 18:14, Mikael Abrahamsson wrote:
> we cover this in any documents? 

Very good point, actually. I've never seen that covered and it is as 
important as the issue that we are already trying to solve.

> The result to end systems is the same 

Yup.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:26:21 +0100

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

Exactly and precisely that!

Cheers, Jan

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Feb 2019 12:28:18 +0100

Jan,

> In practice - "if it hurts, stop doing it" means that ISPs declares IPv6 as not functioning and switch it off for good.
> 
> Is this what we want?

One doesn’t follow from the other.
Neither do we want an IPv6 deployment where TCP connections break arbitrarily or IPv6 users cannot conveniently run servers in their homes.
Short lived, arbitrary changing prefixes dumps most of the baby out with the bath water (ouch that put some awful pictures in my head).

> CPE power-cycle is something that ISP has no control of. Now, if provisioning vendors would play our game, then they would never implement a provisioning mechanism that allows flash renumbering, as you call it.

Of course no mechanism here has ever been contingent on the CPE rebooting or not.
One reason we have RFC4649 for example, for deployments where the interface ot user binding isn’t obvious.

> 
> Ole, I would ask you a favour. Can you ask internally at your employer why provisioning at BRAS allows creating "pools" of IPv6 addresses and dynamic prefix delegations? Basically, this is the core root of a problem and if we can fix it in provisioning platforms, then we are all set and there is no need for changing CPE or host.
> 
> But I'm afraid that the answer that you'll get will be "customers demanded this and we had to implement it". Money talks. Do you think we can change that? Talk VendorC, VendorJ, VendorX and all others into turning their behaviour into one that actually give ISPs even an option to honour their "contract" with a customer, even in case of unintended event with the CPE?
> 
> Should we write a Standard RFC that neatly defines all the MUSTS for provisioning platforms?

The provisioing platforms have all that they require. This is only policy.
Now, I know there are cases where huge swats of users are moved from one aggregation point in the network to another, where routing would end up very messed up if customer weren’t renumbered, and also that in those cases that flash renumbering is a lot easier to do, but those are typically known events.

> If yes - good. If not - then we have to change the host and CPE.

If we want to keep the benefits of IPv6, and solve the problem of arbitrary addresses being ripped out from underneath the host stack, we need to do quite a bit more than what is proposed in this draft. The reason why we need to push against this kind of network behaviour is that the transport protocols, host stack and applications aren’t ready, and they’re not going to be for a while.

Ole

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:38:20 +0100

> without realising there are different and avoidable consequences?

Yes.

> IPv4, and their employer assumes or expects, possibly implicitly, to

Yes.

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

Yes.

> 4. to suit occasional flash renumbering?

Yes.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 12:43:20 +0100

On 04/02/2019 12:28, Ole Troan wrote:
> Jan,
> 
>>>> 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.
>>> 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”.
>> 
>> In practice - "if it hurts, stop doing it" means that ISPs declares
>> IPv6 as not functioning and switch it off for good.
>> 
>> Is this what we want?
> 
> One doesn’t follow from the other. Neither do we want an IPv6
> deployment where TCP connections break arbitrarily or IPv6 users
> cannot conveniently run servers in their homes. Short lived,
> arbitrary changing prefixes dumps most of the baby out with the bath
> water (ouch that put some awful pictures in my head).

:)

I agree with you. So fixing the provisioning part should be our answer?

>> implement a provisioning mechanism that allows flash renumbering,
>> as you call it.
> 
> Of course no mechanism here has ever been contingent on the CPE
> rebooting or not. One reason we have RFC4649 for example, for
> deployments where the interface ot user binding isn’t obvious.
> 
>> 
>> Ole, I would ask you a favour. Can you ask internally at your
>> employer why provisioning at BRAS allows creating "pools" of IPv6
>> addresses and dynamic prefix delegations? Basically, this is the
>> core root of a problem and if we can fix it in provisioning
>> platforms, then we are all set and there is no need for changing
>> CPE or host.
>> 
>> demanded this and we had to implement it". Money talks. Do you
>> think we can change that? Talk VendorC, VendorJ, VendorX and all
>> others into turning their behaviour into one that actually give
>> ISPs even an option to honour their "contract" with a customer,
>> even in case of unintended event with the CPE?
>> 
> The provisioing platforms have all that they require. This is only
> policy. Now, I know there are cases where huge swats of users are
> moved from one aggregation point in the network to another, where
> routing would end up very messed up if customer weren’t renumbered,
> and also that in those cases that flash renumbering is a lot easier
> to do, but those are typically known events.

Not to end users... and they expect their Internet connection to work 
night and day :)

> If we want to keep the benefits of IPv6, and solve the problem of
> arbitrary addresses being ripped out from underneath the host stack,
> we need to do quite a bit more than what is proposed in this draft.
> The reason why we need to push against this kind of network behaviour
> is that the transport protocols, host stack and applications aren’t
> ready, and they’re not going to be for a while.

Agreed :)

Again - impose a Standards document with lots of MUSTS on provisioning folx?

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 13:06:56 +0100

Joel,

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

5) Because there is no information in CPE about previous prefix - it 
does not send an RA with lifetime 0 for previous prefix to hosts, 
telling them to stop using addresses from that prefix.

Cheers, Jan

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 4 Feb 2019 13:34:41 +0100 (CET)

On Mon, 4 Feb 2019, Ole Troan wrote:

> Now, I know there are cases where huge swats of users are moved from one 
> aggregation point in the network to another, where routing would end up 
> very messed up if customer weren’t renumbered, and also that in those 
> cases that flash renumbering is a lot easier to do, but those are 
> typically known events.

My current ISP has stated that their intention is to make sure people keep 
the same prefix as long as their HGW is alive, and they even provide a 7 
day life time of the lease. So unless your HGW is alive once every 7 days, 
you get to keep the lease. This makes a lot of sense to me and is a decent 
tradeoff between different realities.

Now, there is nothing in the contract that regulates this so they're free 
to change whenever (and they do in case they need to move people around 
between aggregation routers, but this is a rare event).

Trying to demand that ISPs keep the same /56 for the duration of the 
contract is not going to work because that's not what real life looks 
like. I'd say we should take the fight about perhaps about lifetimes and 
definititely about delegation sizes (I still run into people with only /60 
or /64), but contract-length stable prefix isn't something I'd advocate to 
fight for. It's too far out even for me.

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Feb 2019 13:54:43 +0100

Mikael,

> My current ISP has stated that their intention is to make sure people keep the same prefix as long as their HGW is alive, and they even provide a 7 day life time of the lease. So unless your HGW is alive once every 7 days, you get to keep the lease. This makes a lot of sense to me and is a decent tradeoff between different realities.
> 
> Now, there is nothing in the contract that regulates this so they're free to change whenever (and they do in case they need to move people around between aggregation routers, but this is a rare event).
> 
> Trying to demand that ISPs keep the same /56 for the duration of the contract is not going to work because that's not what real life looks like. I'd say we should take the fight about perhaps about lifetimes and definititely about delegation sizes (I still run into people with only /60 or /64), but contract-length stable prefix isn't something I'd advocate to fight for. It's too far out even for me.

“real life looks like”…
Why wouldn’t it? If the ISP has a routed interface directly towards the customer, then having a fixed /56 PD configured on that customer facing interface, that sure looks like real life to me.
Or a fixed mapping of remote-id to a /56 in a DHCP PD database…

Sure, there are ISPs that use DHCP PD servers that allocate from pools. But I have a hard time seeing why that should be easier, cheaper, more managable than a static mapping table.

(and don’t get me wrong, I’m all in favour of making CPEs and hosts more robust. I’m just trying to emphasize the point, that you can hardly blame the CPEs not working well, in a network that’s by some definition misconfigured. I am still on the fence if the way to achieve that is through an IETF document or something else though).

Ole

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 4 Feb 2019 13:30:13 +0000

Mikael Abrahamsson wrote on 04/02/2019 12:34:
> definititely about delegation sizes (I still run into people with only 
> /60 or /64), but contract-length stable prefix isn't something I'd 
> advocate to fight for. It's too far out even for me.

I think you and Ole are talking about different meanings of the word 
"contract".

Unless I'm mistaken, Ole is saying that a dhcp6-pd lease for time period 
X is a contract for time period X, during which the ISP should retain 
enough state that if the CPE issues another dhcp request within time 
period X, they will receive the same prefix.  However, when time period 
X elapses, the ISP is fully within their rights to assign a different 
prefix.

Maintaining static leases for the duration of a legal contract with a 
customer involves hassle and pain.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 4 Feb 2019 14:43:02 +0100 (CET)

> Or a fixed mapping of remote-id to a /56 in a DHCP PD database…

So while I have actually designed services that look like that (individual 
single /56 pool per interface) most people do not do that. Some don't want 
to for commercial reasons, to differentiate betwee this and other 
services.. or some other reason. Same thing some don't give customers /56.

We're not the protocol police and we've not been successful in getting /56 
PD sizes to everybody, so I don't see how we're going to mandate this that 
is even more commercial angle on things.

> Sure, there are ISPs that use DHCP PD servers that allocate from pools. 
> But I have a hard time seeing why that should be easier, cheaper, more 
> managable than a static mapping table.

Just because you and me think something makes sense doesn't mean it make 
sense to others.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 04 Feb 2019 14:47:43 +0100

>X elapses, the ISP is fully within their rights to assign a different 

The way I understand DHCP leases is that for the duration of the lease, 
the party that obtained the lease has exclusive use of the address or prefix.
So it is a requirement on the DHCP server to avoid giving the lease to another
party.

As far as I know it never said anything about getting the same address or 
prefix if you do a DISCOVER.

A related point, and that's where it starts getting complicated, is that 
over time DHCP got used for access control. Initially DHCP was just a way
for making sure that everybody got a unique address, but you could just
use any address you liked at the risk of collision.

These days access routers restrict source addresses to whatever was offered in
a DHCP lease. And this is where it gets messy. 

In theory we could specify how access routers could do the right thing. And then
get CPEs to do the right thing as well.

But I think it would be more productive to make hosts more robust.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 4 Feb 2019 13:53:19 +0000

> But I think it would be more productive to make hosts more robust.

making hosts more robust is a good deal more difficult and error prone 
than making ISP provisioning systems more aware of maintaining state.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Mon, 04 Feb 2019 15:44:48 +0100

>than making ISP provisioning systems more aware of maintaining state.

It seems to me that setting the preference time to zero for all addresses
derived from a PIO from a particular router that are not covered by
the PIOs in a received RA would basically solve the issue for common
use cases.

The way I see it, there is a relatively simple interaction between a host 
and a CPE. Something we can understand. There a lot of weird stuff surrounding
access routers making it unlikely that all of that gets fixed. Even
in simple cases with static prefixes, access routers (and surrounding 
infrastructure) already do lots of weird things. Getting support for rolling
prefixes properly is an uphill battle.

At the same time, for IPv4, NAT will hide most of these issues. We can only
hope that CPE vendors will not add some kind of IPv6 NAT to deal with this
problem.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 4 Feb 2019 15:41:14 +0000

> relevant standard documents and implemented whatever was a MUST and

RFC7084 has no business being labeled an "Internet Standard", and its ability to impact CE router vendor development decisions is completely unrelated to how it is labeled.

It has no business being an "Internet Standard" because CE router requirements are derived/designed based on access architecture. CE router requirements do not, cannot, and will not ever drive access architecture. Whenever access architecture changes, CE router requirements change. Some of the changes that we saw from RFC6204 to RFC7084 were because ISPs decided they wanted to do different things in their access networks than what they originally thought (DS-Lite, 6rd, and some other items). So the requirements had to adjust. Now we have ISPs not agreeing on "IPv6aas" architecture. So the CE router is being asked to do all of them. What if 5G/wireline convergence becomes a reality? CE router requirements will change. Trying to standardize something that is outside IETF's control is unrealistic.

CE router vendors (and ISPs) really don't care whether something is labeled as "Standard" or "Informational". If it's well-defined and useful, that's all that's needed. L2TP is "Standards Track". PPPoE is "Informational". Which one do ISPs use in the access network, and which is implemented in CE routers? PPPoE. Why? It was a good tool for what was needed, and the RFC is easy to read and implement. L2TP was not the right tool.

Are there any major CE router vendors who haven't tried to implement all the "MUST" requirements of RFC7084? Not that I'm aware of. Some may not have done it right, but that's not the same as not trying.

I'm opposed to any attempt to turn CE router requirements into a "Standard". It's unrealistic and the status would have no impact on whether it's implemented.
Barbara

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 17:06:46 +0100

On 04/02/2019 13:34, Mikael Abrahamsson wrote:
>> Now, I know there are cases where huge swats of users are moved from 
>> one aggregation point in the network to another, where routing would 
>> end up very messed up if customer weren’t renumbered, and also that in 
>> those cases that flash renumbering is a lot easier to do, but those 
>> are typically known events.
> 
> My current ISP has stated that their intention is to make sure people 
> keep the same prefix as long as their HGW is alive, and they even 
> provide a 7 day life time of the lease. So unless your HGW is alive once 
> every 7 days, you get to keep the lease. This makes a lot of sense to me 
> and is a decent tradeoff between different realities.

This is a behaviour that would be expected from a good ISP. However, not 
every ISP is like that, unfortunately :(

> 
> Now, there is nothing in the contract that regulates this so they're 
> free to change whenever (and they do in case they need to move people 
> around between aggregation routers, but this is a rare event).
> 

That was exactly the reason for writing RIPE-690 :) That soon became an 
agreed-among-operators "norm" for sizes, so I hear lately ;)

I think prescribed 7 days lease-time and "delegate always the same 
prefix if checked in during that time" would make the world a much 
better place.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 4 Feb 2019 17:33:44 +0100

On 04/02/2019 13:54, Ole Troan wrote:> “real life looks like”… Why 
wouldn’t it? If the ISP has a routed
> interface directly towards the customer, then having a fixed /56 PD
> configured on that customer facing interface, that sure looks like
> real life to me. Or a fixed mapping of remote-id to a /56 in a DHCP
> PD database…

This is rarely a real life scenario. More common is a PPPoE or one of 
the derivatives, where you create a virtual layer over the physical 
layer and the other endpoint can be terminated wherever ISP feels like 
on this particular day. Moving people around BRAS-es is not uncommon.

However, I always advocated ISPs to put static IPv6 PDs in Radius (or 
whichever AAA mechanism they use), so that the same user always gets the 
same PD.

This approach is good until you have a requirement to do multiple PPPoE 
sessions per username. Then things get messy and that's the reason why 
people think of dynamic PDs ;)

My suggestion is to have separate dynamic /64 prefixes to number the WAN 
link (it works for multiple PPPoE sessions and also it gives IPv6 access 
to a very simple PPPoE client that doesn't do a PD request, like 
end-host machine with Windows or something) and fixed PD that just the 
first PPPoE session is able to get. This usually covers most of the 
scenarios. For the corner cases then ISP needs to solve them case by 
case, but at least for majority of clients that's the solution.

> 
> Sure, there are ISPs that use DHCP PD servers that allocate from
> pools. But I have a hard time seeing why that should be easier,
> cheaper, more managable than a static mapping table.

ISPs actually thinks that.

<sarcasm>
It's easy to deploy, it works in lab scenario, dynamic worked for IPv4 
and hey, users will never notice it as in case of issues they fall-over 
to IPv4 anyway ;) #happyEyeballsToTheRescue
</sarcasm>

> 
> (and don’t get me wrong, I’m all in favour of making CPEs and hosts
> more robust. I’m just trying to emphasize the point, that you can
> hardly blame the CPEs not working well, in a network that’s by some
> definition misconfigured. 

It is misconfigured :) But stuff happens without you wanting it to 
happen and then you need the edge to react properly.

<analogy>
It's the same as if you would be walking down the street and all of a 
sudden there is a gunfire around you. Now you have two options:
- react and hide from the bullets
- continue walking, saying that this street was not supposed to be under 
fire, city is not treating you well and there were no bullets flying 
around a minute ago.
</analogy>

Now you pick what you would do ;)

I personally would react to the new situation regardless of what I think 
the situation would have to look like - and so I think that CPEs and 
end-hosts needs some mechanism to adopt if things go wrong...

> I am still on the fence if the way to
> achieve that is through an IETF document or something else though).

Any idea of what something else could be? IETF could be the right place 
to address that...

Cheers and thnx, Jan

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Feb 2019 00:49:04 -0300

On 4/2/19 08:28, Ole Troan wrote:
[....]
> If we want to keep the benefits of IPv6, and solve the problem of arbitrary addresses being ripped out from underneath the host stack, we need to do quite a bit more than what is proposed in this draft. 

What we want to do here is improve the robustness of hosts when such
scenarios do happen. We can do other things, including boiling the
ocean. However, that's, for the most part, orthogonal to what we are
trying to do with this document.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Feb 2019 00:51:03 -0300

On 4/2/19 09:34, Mikael Abrahamsson wrote:
> keep the same prefix as long as their HGW is alive,

So.. what happens when the CPE crashes and reboots?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Feb 2019 00:52:14 -0300

> Sure, there are ISPs that use DHCP PD servers that allocate from pools. But I have a hard time seeing why that should be easier, cheaper, more managable than a static mapping table.

That's a valid, but different question.

What we are trying to do is improving robustness when such scenarios do
happen.

---

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: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Feb 2019 07:04:48 +0100 (CET)

> So.. what happens when the CPE crashes and reboots?

Since the lease is still valid you get the same lease again when doing 
SOLICIT.

---

From: Richard Patterson <[email-masked]>
Date: Tue, 5 Feb 2019 10:15:47 +0000

> So.. what happens when the CPE crashes and reboots?

The lease state is stored on the BNG/DHCP server.  If the CPE uses a
stable DUID, hasn't sent a Release, and returns within the valid
lifetime, then it should receive the same PD.   Some BNG vendors also
track an additional lease lifetime longer than the valid lifetime, to
keep old leases in a reserved/held state allowing a CPE to retain the
same PD even after the valid lifetime has expired.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Feb 2019 11:31:00 +0100 (CET)

> same PD even after the valid lifetime has expired.

There are also DHCP servers that can be configured to always find the 
oldest expired lease and hand that out if there are no never-used 
resources. If a device shows up 2 months after the lease expired with the 
same DUID and nobody has used that lease in between, then they get the 
same PD again that they had 2 months prior.

If the device has permanent storage then it could ask for the previous PD 
it had, and if that's free then it'd get it. So as discussed earlier in 
the thread, having the HGW just store the last PD it had could be helpful 
even if it never updates it with information as long as it's the same.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 11:41:20 +0100

> prefix if you do a DISCOVER.

That seems to be the core of the problem, me think :) BRAS-es with 
defined IPv6 pools assigning PD-s randomly, regardless of anything and 
everything.

> get CPEs to do the right thing as well.

I'm starting to think that we should make all 3 places (access router, 
CPE and host) more robust and binding to some defined standard.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 11:42:20 +0100

> hope that CPE vendors will not add some kind of IPv6 NAT to deal with this

sssshhh... don't say that again, please :)

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 11:42:56 +0100

> Since the lease is still valid you get the same lease again when doing 

That's a theory. In practice...

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 11:49:25 +0100

Hi,

On 04/02/2019 16:41, STARK, BARBARA H wrote:
>>  Trying to standardize something that is outside IETF's control is unrealistic.

Interesting sentence. Very interesting one. Makes me think about what's 
inside and what's outside IETF's control.

I think it's an important thought to think about and the answer to that 
basically answers what we actually *CAN* do.

Cheers, Jan

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Feb 2019 11:50:30 +0100

>even if it never updates it with information as long as it's the same.

The problem starts when the ISP wants to change prefixes. As far as I know,
there is no documentation on how that should be done. I also think it is 
unlikely that the majority will get it right.

If the device has permanent storage then it can also announce the old prefix
with preferred and valid lifetimes set to zero. However that doesn't work
when a CPE vendor doesn't want to write that information to flash storage.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 11:59:14 +0100

Dear Barbara,

On 04/02/2019 16:41, STARK, BARBARA H wrote:
>> However, RFC7084 is Informational and not Standard. I think this
>> should make it into Standard. I've seen many CPE vendors saying "we
>> found relevant standard documents and implemented whatever was a
>> MUST and shipped the product."
> 
> RFC7084 has no business being labeled an "Internet Standard", and its
> ability to impact CE router vendor development decisions is
> completely unrelated to how it is labeled.
> 
> It has no business being an "Internet Standard" because CE router
> requirements are derived/designed based on access architecture. CE
> router requirements do not, cannot, and will not ever drive access
> architecture. Whenever access architecture changes, CE router
> requirements change. Some of the changes that we saw from RFC6204 to
> RFC7084 were because ISPs decided they wanted to do different things
> in their access networks than what they originally thought (DS-Lite,
> 6rd, and some other items). So the requirements had to adjust. Now we
> have ISPs not agreeing on "IPv6aas" architecture. So the CE router is
> being asked to do all of them. What if 5G/wireline convergence
> becomes a reality? CE router requirements will change. Trying to
> standardize something that is outside IETF's control is unrealistic.

Agree, to some degree. BRAS/BNG behaviour and CPE behaviour when 
assigning IPv6 PDs is the same and should be predictable wherever you go 
and whichever transport technique you use. Mobile/3gp is outside of the 
scope of this conversation. For others we could standardize how things 
should look like. After that - it doesn't matter how access changes, the 
principle is always the same.

> 
> CE router vendors (and ISPs) really don't care whether something is
> labeled as "Standard" or "Informational". If it's well-defined and
> useful, that's all that's needed. L2TP is "Standards Track". PPPoE is
> "Informational". Which one do ISPs use in the access network, and
> which is implemented in CE routers? PPPoE. Why? It was a good tool
> for what was needed, and the RFC is easy to read and implement. L2TP
> was not the right tool.

True. However what I see with many CE vendors (and not just CE vendors) 
is that they implement just MUSTs from Standards tracks and ship the 
product. Some of them actually sees RFCs as something that they must do 
to satisfy that grumpy customers that senselessly demands standards and 
interoperability. Yes, some of them do that, and the cheaper the CE 
gets, more they see RFCs and MUSTs as a burden to their creativity and 
imagination in solving access problems.

That's where the desire for Standards document comes from. Otherwise 
it's just a good wish. There are exceptions, but very rare (like PPPoE, 
as you mentioned).

> 
> Are there any major CE router vendors who haven't tried to implement
> all the "MUST" requirements of RFC7084? Not that I'm aware of. Some
> may not have done it right, but that's not the same as not trying.

RFC7084 is a great document and could easily be a Standards track.

> 
> I'm opposed to any attempt to turn CE router requirements into a
> "Standard". It's unrealistic and the status would have no impact on
> whether it's implemented. Barbara

What's a difference for you?

Cheers, Jan

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Feb 2019 22:49:52 +1100

> defined IPv6 pools assigning PD-s randomly, regardless of anything and

I don't know about other implementations, however Cisco IOS XE can source
stable prefix information for the BNG DHCPv6 server from RADIUS per RFC4818.

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Feb 2019 23:01:12 +1100

On Tue., 5 Feb. 2019, 21:50 Philip Homburg <[email-masked]
wrote:

> The problem starts when the ISP wants to change prefixes.

How often will they really need to do that?

I think a lot of this need in IPv4 has come from IPv4 addresses being
precious and expensive resources. Consequently, it has been worth the
expense and effort of fine grained management of them.

In IPv6, that level of management isn't needed. Addresses are plentiful and
cheap, so you can throw lots of address space at problems.

As far as I know,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Feb 2019 13:10:21 +0100

>cheap, so you can throw lots of address space at problems.

Ideally every customer just gets a static /48. There is no technical reason
why this can't be made to work.

Reality is that ISPs have lots of reasons to do things differently. I don't
think we are in position to tell ISPs that they are doing it wrong. Reality
is also that in lots of markets there is little competition. So if an ISP
does something weird, customers are stuck with it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Feb 2019 13:26:06 +0100 (CET)

> cheap, so you can throw lots of address space at problems.

It's sometimes from re-farming of things. ISPs tend to today build largish 
access-routers and call them BNG. So when a 10GE interface is full, you 
need to split the customer load to two interfaces, or move some to a 
completely different router.

So if you move half of the subscribers of that port to a different router, 
now you have a problem because typically you'll have a set of 
addreses-space dedicated for that router and part of that now needs to go 
to another router. Typically you don't want this type of de-aggregation.

---

From: Richard Patterson <[email-masked]>
Date: Tue, 5 Feb 2019 12:30:21 +0000

> why this can't be made to work.

Not all network topologies can ensure a subscriber will always land on
the same BNG, and I'm not super keen on redistributing millions of
/48s all over the place.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Feb 2019 00:15:53 +1100

> completely different router.

Yes, I know, I don't like big BNGs with 10s of 1000s of sessions on them
because they cause massive outages when they fall over or need to be
upgraded. I much rather scale out with a number of more commodity hardware
BNGs carrying far fewer sessions per BNG.

> to another router. Typically you don't want this type of de-aggregation.

Why not?

Where is the requirement that the individual BNG must be the route
aggregation boundary for subscriber routes?

That's been tradition, however I don't think it is a requirement, and I
suspect one of the original and primary reasons for it was to stop dial-up
session fluctuations causing routing protocol reconvergence events on other
routers.

If your BNGs are using BGP, how many routes and how many BNGs can you have
in a group (with no aggregation) before you run into BGP scaling limits,
when you customers are always online, and customer link fluctuations are a
fault now rather than normal expected behaviour?

My guess for typical BNG hardware is that it is at least in the order of
100 000 routes or more, and 20 or more BNGs. That may be conservative given
that BGP can cope with Internet scale routing.

You may need to deploy route aggregation, however you would do it at the
edge of your BNG group/cluster, rather than within it.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Feb 2019 00:21:04 +1100

> the same BNG, and I'm not super keen on redistributing millions of

Route aggregation boundary placement is not a binary choice of at the BNG
or none.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 16:39:56 +0100

On 05/02/2019 12:49, Mark Smith wrote:
> I don't know about other implementations, however Cisco IOS XE can 
> source stable prefix information for the BNG DHCPv6 server from RADIUS 
> per RFC4818.

That is clear and that works quite well. Problem is that this requires 
quite some work for operators to implement (extend the radius database, 
fill in all the prefixes, make all your provisioning and billing systems 
aware of that change and so on...), so many of them cuts the corners and 
simply assigns a big IPv6 prefix to that BNG/BRAS as a "pool" where 
BNG/BRAS allocates prefixes to customers "at it's will". It's fast, it's 
simple and works in a lab environment.

That's the behaviour that needs to stop.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 16:44:04 +0100

> why this can't be made to work.

Agreed 100% :)

> think we are in position to tell ISPs that they are doing it wrong. 

Hmm. We could be in a position to tell them they are doing it wrong - if 
they are doing it wrong :) And clearly - they are doing it wrong, 
otherwise things would work and we would not have this conversation ;)

We need to make sure operators stop cutting corners and dragging bad 
practices from IPv4 into IPv6 world and things will get better.

> Reality

We need to fix this before people start pulling IPv4 out of their 
networks. Today we have another protocol that saves our day if things 
goes wrong, but when IPv4 is out of our backbones and access networks - 
all this little failures will show much more prominently.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 16:45:02 +0100

> the same BNG, and I'm not super keen on redistributing millions of

Indeed... otherwise you end up with completely overblown IGP table.

Cheers, Jan

---

From: Richard Patterson <[email-masked]>
Date: Tue, 5 Feb 2019 17:28:11 +0000

> That's the behaviour that needs to stop.

Why?

---

From: Lee Howard <[email-masked]>
Date: Tue, 5 Feb 2019 12:54:39 -0500

Before I plonk this thread. . .

>> why this can't be made to work.

I cordially invite you to go build your own network, so you will 
actually be able to tell somebody how to build their network.

> Hmm. We could be in a position to tell them they are doing it wrong - 
> if they are doing it wrong :) And clearly - they are doing it wrong, 

I checked the charter for 6man, and that is out of scope.

The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications. The working group will address protocol
limitations/issues discovered during deployment and operation.  It will
also serve as a venue for discussing the proper location for working on
IPv6-related issues within the IETF.

6man is the design authority for extensions and modifications to the
IPv6 protocol.  The working group may, at its discretion, review any
document produced in another working group that extends or modifies the
IPv6 protocol and, in consultation with the responsible ADs of both
working groups, may recommend to the IESG that 6man working group
consensus is needed before any of those documents can progress for
publication.

To be thorough, I also checked the charter of v6ops:

1. Solicit input from network operators and users to identify
operational issues with IPv6 networks, and determine solutions or
workarounds to those issues.

2. Solicit input from network operators and users to identify
operational interaction issues with the IPv4 networks, and determine
solutions or workarounds to those issues.

3. Solicit discussion and documentation of the issues and opportunities
in IPv6-only operation, and of the resulting innovations.

4. Operational solutions for identified issues should be developed in
v6ops and documented in informational or BCP drafts.

5. Document operational requirements for IPv6 networks.

These documents should document IPv6 operational experience, including
interactions with IPv4, in dual stack networks, IPv6 networks with IPv4
delivered as an overlay or translation service, or IPv6-only networks.

[continued]

"Telling operators they're doing it wrong" is out of scope for the IETF.

> goes wrong, but when IPv4 is out of our backbones and access networks 
> - all this little failures will show much more prominently.

The right answer is not to make prevent addresses from changing, but to 
make changing painless. Otherwise we are locked into a permanent 
topology, and that is not resilient, it's brittle and doesn't scale.

Unfortunately, no one is paying me to re-open the 6renum working group. 
I regret closing it. Maybe others can do this work.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 18:54:47 +0100

>> That's the behaviour that needs to stop.

Here I'll have to repeat what Ole said at the beginning of this 
conversation. If you setup a lifetime of prefix delegation and assign it 
to CPE, then CPE expects to get the same prefix back at least for that 
period of time. That doesn't mean that you can assign prefixes at will 
at any time you want. You are breaking the "contract" to your customer 
(CPE). That's exactly the point where things break.

If you set a lifetime of assigned prefix to 24 hours and then change it 
- well, that's your decision, but you are not suppose to break the 
timers that you set yourself.

Cheers, Jan

---

From: Richard Patterson <[email-masked]>
Date: Tue, 5 Feb 2019 19:00:58 +0000

> timers that you set yourself.

That's fine, except it doesn't really have anything to do with your
previous statement.  I can (and do) assign a single large prefix to each
BNG for the DHCPv6 server to assign dynamic PDs from, and still respect the
above assertions.

We use 1 hour lease times.  If a CPE hasn't sent a Release, has the same
MAC address and DUID, it will continue to get the same PD after a
[hard|soft]-reboot.  In fact it can return anytime up to an arbitrary value
(7 days in my network), and still receive the same PD, if the BNG/DHCPv6
server is configured to keep state for longer.

As just mentioned by Lee, we should be making sure that these protocols are
resilient to change, not dictating rigid network designs.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 21:08:53 +0100

Richard,

On 05/02/2019 20:00, Richard Patterson wrote:
> BNG for the DHCPv6 server to assign dynamic PDs from, and still respect 
> the above assertions.

I said "where BNG/BRAS allocates prefixes to customers "at it's will"". 
I didn't say "after the lifetime has expired". But, nevertheless, I 
think you and I already had this conversation, didn't we?

You deeply understand what you are doing, you fixed your home-brew CPE 
(or vendors CPE for your use, it doesn't matter), implemented 
across-reboot PD memory and things work. Well done, congratulations!

But you are one operator on a big planet, where many other operators 
doesn't get nowhere near to your understanding of how to build that 
stuff and implement IPv6 in a proper way.

BTW, on a side note, hopefully you can come to SINOG this year and 
explain to our operators how you did exactly things that we are 
discussing here ;) (let's talk offline...)

> [hard|soft]-reboot.  In fact it can return anytime up to an arbitrary 
> value (7 days in my network), and still receive the same PD, if the 
> BNG/DHCPv6 server is configured to keep state for longer.
> 
> As just mentioned by Lee, we should be making sure that these protocols 
> are resilient to change, not dictating rigid network designs.

I'm with you. If we manage to fix CPE and host to be able to follow that 
dynamic topology changes - that would be a good thing to do anyway. I'm 
not at all encouraging operators to deploy dynamic PDs from many 
reasons, but if topology changes then CPE and hosts needs to be able to 
follow that change.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 5 Feb 2019 21:11:14 +0100

> actually be able to tell somebody how to build their network.

I did. Many times.

He said "Ideally". I agree with that :)

Cheers, Jan

---

From: Lee Howard <[email-masked]>
Date: Tue, 5 Feb 2019 16:46:41 -0500

>> actually be able to tell somebody how to build their network.

And yet when somebody says "I built my network for reasons that were 
compelling to me at the time" you tell them they did it wrong. It's 
tiresome.

Even when someone does engage in conversation and begin explaining 
reasons, it always becomes a rathole of all of the unique considerations 
of that network with those vendors and this budget and some other 
requirements at the time in question. Rebuilding a functioning network 
is costly and breaks things.

If you were a network operator reading the latter part of this thread, 
would you be inclined to participate in this working group or in the IETF?

> He said "Ideally". I agree with that :)

Static? That was fine when there were few enough nodes that you could 
manually configure changes. Addressing is dynamic, which is why we have 
dynamic routing protocols.

Jan, I'm replying to you because we're friends and I know we will remain 
so. When I say "you" here, I don't just mean you.

Lee

---

From: Christian Huitema <[email-masked]>
Date: Tue, 5 Feb 2019 12:10:02 -1000

> compelling to me at the time" you tell them they did it wrong. It's

+1. I am always amazed at how long threads can become on the IPv6
mailing list. It seems that the problem is rather simple:

1) For some reason, the router gets reconnected, and the new connection
comes with a different IPv6 prefix.

2) At that point, all IPv6 addresses allocated to hosts on the network
become stale, and may remain so for some potentially long time.

3) We want to transition rapidly to a new state in which hosts acquire
addresses based on the new prefix and can communicate again.

Lots of the discussion centers on denial. "Don't worry about that, the
router's prefix should not change." Really? There are tons of scenarios
in which stuff happens, such as for example a router dialing up a back
up cellular connection if the land line connection broke. Or the various
events in which the back-haul network configuration changes. These
events are obviously painful, as all existing TCP connections are going
to break. The providers probably strive to make them rare, because
inflicting pain on customers is not a great business plan. But rare does
not mean "never". Denying that is going to cause tons of frustration.

-- Christian Huitema

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Wed, 6 Feb 2019 00:28:46 +0100

On 05/02/2019 22:46, Lee Howard wrote:> And yet when somebody says "I 
built my network for reasons that were
>  compelling to me at the time" you tell them they did it wrong. It's

I'm not sure I said that. My network - my rules. Your network - your rules.

However, it seems not very useful to me if networks are built in a way 
that breaks and people attributes that to "broken IPv6".

> reasons, it always becomes a rathole of all of the unique
> considerations of that network with those vendors and this budget and
> some other requirements at the time in question. Rebuilding a
> functioning network is costly and breaks things.

Agreed.

> 
> If you were a network operator reading the latter part of this
> thread, would you be inclined to participate in this working group or
> in the IETF?

I hope so. We finally started a discussion how networks are built and 
how to improve them and I find this valuable.

You and I know each other for quite some years now and you know that I 
spent considerable amount of time around the world talking to many 
operators (from small to large ones) that thought about implementing 
IPv6 and some of them did that. I even helped some of them doing so in 
many ways, but too many times hit the same issue - or burden - if you 
wish... the one that at the end of the day resulted in RIPE-690 BCOP 
document. I've seen that around the world countless times and that's the 
reason why I would like to see that confusion sorted out once for all. 
We did some "damage control" in RIPE-690, but that advice there is just 
a response to a situation that we found ourself in due to lack of very 
precise instructions how to do access part, how to do CPE and how to put 
all this stuff together that it works. There are exceptions that fixed 
this stuff for them, but mostly they are quiet and don't share their 
solutions.

So, what can we do to make this better?

>  manually configure changes. Addressing is dynamic, which is why we
> have dynamic routing protocols.

<shrug>

It still would be ideal :) People running servers at home, etc, etc... a 
bit utopia, but still ideal :)

> 
> Jan, I'm replying to you because we're friends and I know we will
> remain so. When I say "you" here, I don't just mean you.

I know, and that's why I got engaged in this discussion. This is a topic 
that is very close to my heart, I've been working on it for many years 
now and I would really like it to be improved and give some right 
guidance to people that are deploying IPv6 around the world - not just 
people on this mailing list.

Cheers, Jan

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Feb 2019 17:26:53 -0300

[....]
> topology, and that is not resilient, it's brittle and doesn't scale.

That's my take as well.

> I regret closing it. Maybe others can do this work.

Let's not try to boil the ocean now. WHat this document addresses is a
very self-contained problem.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Feb 2019 11:46:16 +1100

> are resilient to change, not dictating rigid network designs.

This isn't the WG that can solve the idenitifer/locator problem.

It's today's primary transport layer protocol that is requiring address
stability for the duration of its connections.

If TCP or some other new transport layer protocol stops imposing that
requirement on IPv6, then PD prefix stability across CPE reboots becomes
irrelevant.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 6 Feb 2019 10:15:51 +0000

Christian Huitema wrote on 05/02/2019 22:10:
> router's prefix should not change." Really?

We know the router's prefix will change.  The challenge is transferring 
the state information from one domain to another, so that when it 
changes, the end devices can recover as quickly as possible.

Mark is spot on to note that TCP and UDP require addressing stability. 
Changing from TCP and UDP is boiling the ocean, which means that if we 
want to deal with this problem, we need to work with what we have.

The choices seem to be:

1) ensuring that if a device is disconnected and then reconnects to the 
same network, the device will be given the same lease,

2) the intermediate device remembers the old lease, compares it with the 
new lease and if they're different, invalidates the old prefix by 
issuing an updated PIO,

3) pushing the smarts down to the host layer and detecting / monitoring 
whether any particular prefix is still valid

4) ???

Fernando's suggestion is workable but requires CPE vendors to get on 
board with the idea of storage of addressing information.  Getting ISPs 
to change DHCPv6 assignment policies is also workable, but requires 
centralised provisioning and dynamic routing.

None of these is ideal and all of them require compromise and some 
change in behaviour in a way that has side effects.

This is because the core problem is about how to deal with transfer of 
state information.  Managing state is always a monumental headache.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Feb 2019 08:31:05 +1300

> same network, the device will be given the same lease,

In the general case we can't "ensure" that. Firstly it may be against
business policy or privacy policy for some ISPs. Secondly even if it
was the intended policy, there can always be failure scenarios. Thirdly,
a host might be disconnected from one LAN and reconnected to another
one without knowing it. So even if this is the recommended practice,
no host can rely on it.
 
> new lease and if they're different, invalidates the old prefix by 

Again, we can't rely in this, due to legacy equipment and the possibility
of failures or reconnections.
 
> whether any particular prefix is still valid

https://tools.ietf.org/html/rfc6059 ?

In any case, because neither of the preceding options is guaranteed,
I think there is no choice: hosts must be able to recover from
dead addresses.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Feb 2019 03:53:52 +0100

Brian E Carpenter <[email-masked]> wrote:
    >> The choices seem to be:
    >> 
    >> 1) ensuring that if a device is disconnected and then reconnects to
    >> the same network, the device will be given the same lease,

    > was the intended policy, there can always be failure
    > scenarios.

Yes, but we know how to planned renumbering.

And, if we can get the prefix written to stable storage (as has been pointed
out, it only needs to be written when it actually changes), then we can deal
with the problem.

The only other thing that I can think of is to create a new option which is
something like "previous prefix"... or maybe "obsolete prefixes"

ISPs that
     a) control the CPE devices,
     b) want to use devices with no stable storage,
     c) also want to do flash renumbering
     d) and don't want to use really short lifeimes
can implement such a thing.

    > Thirdly, a host might be disconnected from one LAN and
    > reconnected to another one without knowing it. So even if this is the
    > recommended practice, no host can rely on it.

Yeah, but users mostly understand that this breaks things already.
Maybe this happens in WIFI more frequently than desired without user
intention, but in that case, both networks involved are probably pretty
fragile already.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Feb 2019 23:43:39 -0300

> Christian Huitema wrote on 05/02/2019 22:10:
[....]>
> same network, the device will be given the same lease,

We can provide advice to make this happen where possible.. however, this
is not enforceable....

> new lease and if they're different, invalidates the old prefix by

Same here.

> whether any particular prefix is still valid

This is the part that makes more sense to me -- although it doesn't mean
we don't do 1) and 2).

Exactly.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Feb 2019 23:46:28 -0300

On 6/2/19 16:31, Brian E Carpenter wrote:
[....]
> https://tools.ietf.org/html/rfc6059 ?

Not really. Actually, the tricky part in this case is that the network
-- from the host pov -- is the same.

Agreed.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Feb 2019 17:44:13 +0100

Jan Zorz - Go6 <[email-masked]> wrote:
    > whichever AAA mechanism they use), so that the same user always gets
    > the same PD.

...

    > My suggestion is to have separate dynamic /64 prefixes to number the
    > WAN link (it works for multiple PPPoE sessions and also it gives IPv6
    > access to a very simple PPPoE client that doesn't do a PD request, like

This creates two routes per customer.
That's why I advocate to use the prefix exclude option if you can,
or better, just don't number the WAN link.

I've had customers complain that they can't have so many routes, and why is
IPv6 not like IPv4, and I ask them how many ARP cache entries they have.
At that point, they look confused for a moment, but most figure out that IPv4
and IPv6 work exactly the same at that point.  They just didn't remember that
IPv4 was hiding the same state in what they think of as layer 2.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Feb 2019 18:03:28 +0100

Mikael Abrahamsson <[email-masked]> wrote:
    >> In IPv6, that level of management isn't needed. Addresses are
    >> plentiful and cheap, so you can throw lots of address space at
    >> problems.

    > It's sometimes from re-farming of things. ISPs tend to today build
    > largish access-routers and call them BNG. So when a 10GE interface is
    > full, you need to split the customer load to two interfaces, or move
    > some to a completely different router.

    > So if you move half of the subscribers of that port to a different
    > router, now you have a problem because typically you'll have a set of
    > addreses-space dedicated for that router and part of that now needs to
    > go to another router. Typically you don't want this type of
    > de-aggregation.

With VDSL2 speeds approaching 100Mb/s, and FTTH going way higher (while
sometimes still using PPPoE), 10GE ports don't carry that many subscribers.

You don't want to dedicate address space for a specific BNG.
I've seen two situations: the BNGs are cheapish, and you run n+1 redundancy
on them, and just keep growing n.  The ISP puts a L3 router in front, and
*that* router gets the big prefix.  Radius can allocate from a pool for
that location, and then lock it down in a database.

One needs to use a routing protocol between the BNGs and the router,
but in OSPF terms, one should make that an area, so /48s don't leak all over
the place.  Maybe we need a BCP that explains all of this?
Seems like more of a RIPE thing?

The other way is that BNGs are expensive silicon filled boxes with multiple
100GE ports, and they are typically limited in terms of number of sessions.
This solution sucks if you are doing 7Mb/s ADSL, because you are limited
by sessions.  It's typically still expensive on a per-customer basis though.
And you have have n+1 redundancy, and having two BFRs per POP is probably
too expensive.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 Feb 2019 09:23:54 +0000

> one without knowing it. So even if this is the recommended practice,

It's not ensuring that the customer gets the same lease all the time; 
it's ensuring that if a customer is disconnected where their previous 
lease is still active, and then they reconnect within the lifetime of 
that lease, that they can still use that lease for as long as it's active.

In other words - as some other people put it - it's about ensuring that 
ISP leases are honoured even if a customer disconnects and reconnects.

This is probably the least difficult option but requires a level of 
centralised provisioning, so will mean some push-back from service 
providers.  This option also has the smallest footprint.

> of failures or reconnections.

I don't necessarily see why we can't rely on this to work in most cases.

> I think there is no choice: hosts must be able to recover from

This is potentially the boil-the-ocean option.  It's hard not to think: 
"perfect is the enemy of good enough".

Nick

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 7 Feb 2019 12:42:34 +0100

> This creates two routes per customer.

Ya, I know... Usually this has been handled with creating a pool of IPv6 
addresses per each BRAS/BNG where /64-s were allocated for each 
connecting CPE to number the WAN link. Experience shows that dynamic 
changing of the WAN addressing does not bring much pain, as does 
changing of addressing in the networks behind CPE. In this way you have 
just one route towards BRAS/BNG for that pool of "WAN link" addresses.

> or better, just don't number the WAN link.

I was surprised to discover how many people still connects to the 
internet with one host that does the PPPoE connection (Windows, etc) and 
in this case - not numbering the WAN link would leave this hosts without 
any IPv6 addresses.

However, to be honest, I never tried what happens if you connect with a 
single host PPPoE client that can't do PD and the system on the other 
end does just prefix exclude option. Would that host still remain 
without any IPv6 addresses? Hmm...

> IPv6 not like IPv4, and I ask them how many ARP cache entries they have.

<giggle>

> IPv4 was hiding the same state in what they think of as layer 2.

Good point ;)

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 7 Feb 2019 12:44:13 +0100

> I think there is no choice: hosts must be able to recover from

Agreed 100%.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 7 Feb 2019 12:47:12 +0100

> ISP leases are honoured even if a customer disconnects and reconnects.

That should be the default behaviour ;)

> "perfect is the enemy of good enough".

Not necessarily. Let's define this as a network stack requirement and 
then whoever implements it - the world gets better - even if just one 
does it. Can't be worse than it is now, so any change is good in this case.

Cheers, Jan

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Feb 2019 09:20:14 -0300

Hello, Nick,

> ISP leases are honoured even if a customer disconnects and reconnects.

Maybe the lease is still valid, but if the user asks for a new lease, he
just gets that? WHat if, say, DUID is randomized and the user requests a
new prefix?

[....]
> I don't necessarily see why we can't rely on this to work in most cases.

Well... if you connect to a network that just does not happen to
implement this, your dead. -- OTOH, if the host implements some smarts,
you can workaround this issue even if the network does not play nice.

ZN analogy would be happy eyeballs: you could request that the network
does not have crappy connectivity... but the best way to avoid the cases
where that happens is to implement smarts on the host.

> "perfect is the enemy of good enough".

RFC6059 might be -- although it does not really apply here, since the
network is the same (i.e., you will *not* detect that the network has
changed... quite the contrary).

The host-behaviour that we propose in our I-D is quite simple -- and the
benefits for the hosts implementing it is straightforward...

---

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

> -- from the host pov -- is the same.

The definition of "the same" is: "The combination of the link-layer address
and the link-local IPv6 address of a router is unique" according to RFC6059.

Maybe a CE router should change its own link-local address when it gets
a new prefix? That would automatically break any attempt to use obsolete
RA information.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Feb 2019 15:04:55 -0500

> just one route towards BRAS/BNG for that pool of "WAN link" addresses.

So half dynamic, and half-static via PD.
It's not a bad a solution, particularly because it feels more efficient
From an address point of view if you have a lot of these single-host
networks:

    > internet with one host that does the PPPoE connection (Windows, etc)
    > and in this case
    > - not numbering the WAN link would leave this hosts without any IPv6
    > addresses.

    > single host PPPoE client that can't do PD and the system on the other end
    > does just prefix exclude option. Would that host still remain without any
    > IPv6 addresses? Hmm...

I don't know either.
That's why I think we need to single the network scenario at the IP6CP,
thus the document that we have been discussing in a private thread.

    > Good point ;)

Also, by "hiding", I also mean: not making the state visible, auditable,
or easily monitored as to how full it is.  While the ARP cache is a *cache*,
and can be reconstructed, if it's full, and you have >cache number of
customers, then each time a customer gets more traffic, a different
customer goes offline.  It's usually completely invisible to network
operations.

Stupid layer-2 tricks that IPv6 eliminates.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Feb 2019 18:14:03 -0300

> a new prefix? That would automatically break any attempt to use obsolete

I don't think that would be a good idea. Among the multiple reasons,
because if, say, the concatenation of the router's link-layer address
and router's link-local address is considered the "Network_ID", and
hence this value is used as input into RFC7217, then addresses would not
be stable anymore.

In reality, it is the same network, just with some different parameters.
-- e.g., the ULA prefix employed would not change.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 8 Feb 2019 12:46:07 +0100

>  From an address point of view if you have a lot of these single-host

This solution saved the day to many ;) However, instead of going around 
the problem - we need to fix it. And that's what we propose in our I-D.

> thus the document that we have been discussing in a private thread.

That would be a very useful document. I suggest that we continue that 
thread and get some experienced operators onboard ;) Prague?

> Stupid layer-2 tricks that IPv6 eliminates.

Yup, yup ;)

Cheers, Jan

---

From: Mark Smith <[email-masked]>
Date: Mon, 11 Feb 2019 10:58:26 +1100

On Thu, 7 Feb 2019 at 18:34, Michael Richardson <[email-masked]> wrote:
> ....

There are some advantages to numbering the wan link with a GUA /64.

For troubleshooting, customers' can plug a PC directly into the
service to test it, isolating the CPE as a fault cause. This is a
little bit more important in BYO CPE markets than it would be in ISP
provided/managed CPE.

Although probably becoming less common, for a customer with a single
device, a CPE isn't necessary saving them money.

The decision on for the production residential IPv6 broadband
deployment I worked on back in 2010 was to do dynamic GUA /64s on the
PPPoE session/link, and a static/stable PD prefix provided via RADIUS.
So outside the BNG, there was only 1 PD route per customer.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Feb 2019 10:11:43 +0100 (CET)

On Mon, 11 Feb 2019, Mark Smith wrote:

> The decision on for the production residential IPv6 broadband deployment 
> I worked on back in 2010 was to do dynamic GUA /64s on the PPPoE 
> session/link, and a static/stable PD prefix provided via RADIUS. So 
> outside the BNG, there was only 1 PD route per customer.

For IPoE this is not great as you don't want the ND table growing 
potentially large. Most people I see do this with an optional IA_NA on WAN 
and then PD. The two examples I have available at home neither announces 
any PIO on WAN but instead have M=1 and one of them only offers single 
IA_NA plus /56 PD (DOCSIS ISP with modem in bridge mode), the other one 
(my FTTH AE IPoE provider) just offers IA_PD with unnumbered WAN.

I think both models are fine.

With PPPoE of course the ND scalability problem doesn't exist so just 
routing the /56 down it and using PD exclude for a /64 for WAN that is 
then announced in RA+PIO seems like a perfectly sensible thing to do.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Feb 2019 13:07:52 -0500

> There are some advantages to numbering the wan link with a GUA /64.

I agree.

    > little bit more important in BYO CPE markets than it would be in ISP

This is a big one plus in my opinion.

    > So outside the BNG, there was only 1 PD route per customer.

Is there a document a RIPE or Broadband forum or ??? that details this decision?

--
]               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: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 11 Feb 2019 21:10:43 +0100

> This is a big one plus in my opinion.

Indeed... and also numbering a single-host access with IPv6 if that is 
the case.

> Is there a document a RIPE or Broadband forum or ??? that details this decision?

Not (yet). We touched this in principle in RIPE-690, but nothing 
detailed. I think we should do that.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 11 Feb 2019 21:12:58 +0100

On 11/02/2019 10:11, Mikael Abrahamsson wrote:
> potentially large. Most people I see do this with an optional IA_NA on 
> WAN and then PD. The two examples I have available at home neither 
> announces any PIO on WAN but instead have M=1 and one of them only 
> offers single IA_NA plus /56 PD (DOCSIS ISP with modem in bridge mode), 
> the other one (my FTTH AE IPoE provider) just offers IA_PD with 
> unnumbered WAN.
> 

Sure.

> then announced in RA+PIO seems like a perfectly sensible thing to do.

Still wondering what happens if a single end-host with PPPoE client that 
can't do PD (for example a windows station) connects to the internet and 
tries to get IPv6. Would it fallback to SLAAC?

Cheers, Jan

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Feb 2019 17:59:09 -0500

Jan Zorz - Go6 <[email-masked]> wrote:
    >>> The decision on for the production residential IPv6 broadband deployment I
    >>> worked on back in 2010 was to do dynamic GUA /64s on the PPPoE
    >> IA_NA plus /56 PD (DOCSIS ISP with modem in bridge mode), the other one (my
    >> FTTH AE IPoE provider) just offers IA_PD with unnumbered WAN.
    >>

    >> routing the /56 down it and using PD exclude for a /64 for WAN that is then
    >> announced in RA+PIO seems like a perfectly sensible thing to do.

    > tries to get IPv6. Would it fallback to SLAAC?

Unless it's been configured to ignore RAs, if the ISP sent an RA with M=0,O=0,
then the host would configure with SLAAC.

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Feb 2019 11:42:02 +1100

> Is there a document a RIPE or Broadband forum or ??? that details this decision?

I'm not aware of any, and it was back in 2010, so probably quite early
for residential IPv6 deployments.

I don't know the rational, I joined the project in after a trial had
been run (via a special RADIUS realm and L2TP hopping to trail IPv6
BNGs), and those decisions had already been made. I myself may have
suggested different ones if I'd been involved (for example, I'd do
/48s for literally everybody rather than /56s, because once there is a
single universal value for a parameter it is now a constant that can
only be wrong or right.)

I was thinking earlier today that dynamic /64s on the PPPoE virtual
link would also suffer from the same issues that dynamic PD prefixes
does, and therefore thinking that I'd do static /64s on the PPPoE link
too (and aggregate them upstream of the group of BNGs).

However, different prefixes across link disconnect/reconnect is
probably less of an issue when the device is a host itself - the
disconnect/reconnect is most likely going to be caused by the host
being rebooted/powered off/powered on, so the all of the transport
layer and application state that would be disrupted by a re-addressing
is discarded anyway.

Still, if the link is flakey or interrupted somehow, then a dynamic
/64 prefix on the host to BNG link would still be disruptive to the
host and its applications. For the best customer/end-user experience
it would be best to have stable/static /64 prefixes on the WAN link
too.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Feb 2019 08:45:02 +0100 (CET)

> tries to get IPv6. Would it fallback to SLAAC?

Windows Vista could do PD, you're saying newer Windows cannot? One had to 
turn on ICS - Internet Connection Sharing, though.

But yes, this is the case why one of my ISPs have stated that they have 
IA_NA on WAN, to support the "connect a computer and it should just work" 
case.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 12 Feb 2019 13:36:25 +0100

> too (and aggregate them upstream of the group of BNGs).

Surprisingly, this is not causing major problems. Similar to IPv4, where 
changing the public IPv4 address on the CPE that is doing NAT to the 
internal LAN doesn't have considerable effect on the hosts inside (well, 
some sessions could drop on change, but that's the price you pay with 
NAT). In IPv6, if source and destination address is the same - if 
network in between changes and re-establishes quick enough - that should 
work (and it works in deployments out there ;) )

> layer and application state that would be disrupted by a re-addressing

Indeed.

> it would be best to have stable/static /64 prefixes on the WAN link

That (in theory) would be ideal, but reality sometimes needs some 
compromises ;)

Cheers, Jan

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Feb 2019 06:53:03 -0800

Jan,

> On 12 Feb 2019, at 04:36, Jan Zorz - Go6 <[email-masked]> wrote:
> 
> Surprisingly, this is not causing major problems. Similar to IPv4, where changing the public IPv4 address on the CPE that is doing NAT to the internal LAN doesn't have considerable effect on the hosts inside (well, some sessions could drop on change, but that's the price you pay with NAT). In IPv6, if source and destination address is the same - if network in between changes and re-establishes quick enough - that should work (and it works in deployments out there ;) )

“Not considerable effect”?
It breaks all existing connections. 
It requires updating DNS for services. 
It might require updating static NAT entries and filtering rules. 
...

If we accept that IPv6 will work no better than IPv4 behind a NAT. I challenge you to give me one good reason to do IPv6 at all. 

Ole

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 12 Feb 2019 16:19:44 +0100

On 12/02/2019 15:53, Ole Troan wrote:
>> Surprisingly, this is not causing major problems. Similar to IPv4,
>> where changing the public IPv4 address on the CPE that is doing NAT
>> to the internal LAN doesn't have considerable effect on the hosts
>> inside (well, some sessions could drop on change, but that's the
>> price you pay with NAT). In IPv6, if source and destination address
>> is the same - if network in between changes and re-establishes
>> quick enough - that should work (and it works in deployments out
>> there ;) )
> 
> “Not considerable effect”? It breaks all existing connections. It
> requires updating DNS for services. It might require updating static
> NAT entries and filtering rules. ...
> 
> If we accept that IPv6 will work no better than IPv4 behind a NAT. I
> challenge you to give me one good reason to do IPv6 at all.

Not entirely true. If the address on WAN link changes and PD stays the 
same - then nothing changes on the host itself, but it's just a change 
in network topology "in the middle". In IPv6 you are not using your WAN 
address of CPE in DNS for services, do you? I usually put in DNS 
addresses of hosts behind CPE :)

Consider this (as end-user) as topology change that can occur in every 
part of the network and does not affect your network behind the CPE.

Cheers, Jan

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Feb 2019 07:31:01 -0800

>>> to the internal LAN doesn't have considerable effect on the hosts

This is the quote I was replying to. 
I am glad I misunderstood you. 

Ole

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 12 Feb 2019 16:48:55 +0100

> I am glad I misunderstood you.

I'm glad too. I would not like to bring bad habits and hacks from IPv4 
into IPv6 at all, no matter what the cost! :)

Cheers, Jan

---

From: Lee Howard <[email-masked]>
Date: Tue, 12 Feb 2019 16:55:09 -0500

Seems like I may still disagree about the architecture of the Internet. . .

> It breaks all existing connections.

This is packet switching, not circuit switching. Be resilient.

> It requires updating DNS for services.
Yes. We have dynamic DNS for that.
> It might require updating static NAT entries and filtering rules.

Static what entries? ;-)

Filtering rules... you mean firewall rules? Yes, there should be a 
mechanism to update firewall rules when addresses change. PCP can do it. 
Or if we're in a Homenet context, the god box can glean it's PD and make 
that a variable in the firewall, or filter prefix first, and then 
evaluate host rules.

> If we accept that IPv6 will work no better than IPv4 behind a NAT. I challenge you to give me one good reason to do IPv6 at all.

IPv4 address prices continue to climb, and entry into the IPv4 Internet 
is cost prohibitive (anti-competitive) in many places. Even if you 
concede the need for translation to the legacy Internet, with IPv6 only 
the legacy fraction of traffic needs translation.

With many layers of NAT4444... the odds of something changing midway in 
the topology climb pretty high, so the problems you cite are worse in 
IPv4 than in IPv6.

Lee

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Feb 2019 11:43:25 +1100

> This is packet switching, not circuit switching. Be resilient.

The questions are where and where best to implement that resilience?

IP layer? Within transport layer protocols? Within the transport
layer/application API? Within each application?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Feb 2019 14:04:58 +1300

> layer/application API? Within each application?

All of the above. Seriously. Resilience to "things that should never happen" is basic good software engineering. The trick is to make sure that the resilience costs nothing when things are normal, if possible.

    Brian

---

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: Fernando Gont <[email-masked]>
Date: Wed, 13 Feb 2019 01:12:51 -0300

On 12/2/19 11:53, Ole Troan wrote:
[....]
> If we accept that IPv6 will work no better than IPv4 behind a NAT. I challenge you to give me one good reason to do IPv6 at all. 

There are scenarios where it's actually worse: in normal deployments,
the IPv6 CPE does stateful firewalling such that "only outgoing
connections are allowed) (and yes, that's what we recommend in RFC6092).

Many of these devices do not implement upnp for IPv6. So it's not
feasible to run IPv6 services on IPv6, while it's actually easier to run
services on IPv4. (since they do support upnp for ipv4, and hence you
can punch holes on the NAT).

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Feb 2019 15:50:39 +0100

> On Tue, 5 Feb 2019, Richard Patterson wrote:
[...]
> If the device has permanent storage then it could ask for the previous 
> PD it had,

Yes, it could be done with a DHCPv6 message called 'CONFIRM' - it's sent 
by the Client to the Server, and it 'confirms' the intention to use an 
address that was allocated earlier.  It was specified for when like 
waking up from standby mode.  It's specified for allocating Addresses, 
so it would work the same when specified for prefixes.

Alex

  and if that's free then it'd get it. So as discussed earlier
> in the thread, having the HGW just store the last PD it had could be 
> helpful even if it never updates it with information as long as it's the 
> same.
>

---

From: Richard Patterson <[email-masked]>
Date: Wed, 13 Feb 2019 14:59:58 +0000

> so it would work the same when specified for prefixes.

It could also just include it as a hint in the first SOLICIT.

Storing the old lease to persistent storage also gives the CPE
visibility if the prefix does change.  If it does, it can then send
RAs with lifetime 0 to deprecate the old prefix on the LAN side.  This
seems to have resolve all of the issues for us, as far as we can tell.

-Rich

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Feb 2019 16:02:39 +0100

> comes with a different IPv6 prefix.

For this problem:

In one ADSL IPv6 connection (Free.fr) one gets always a guaranteed same 
/56 prefix from provider.  It looks hardcoded, cant change even after 
two weeks of off time.  But it's a form of IPv6-with-IPv4.

In other home ADSL operators, I guess the problem mentioned (router gets 
reconnected, come with a different IPv6 prefix) exists in _some_ ADSL 
operators - which?

In some cellular operator, which uses DHCPv6 Prefix Delegation, the 
mobile gets a new prefix at some re-connection events (not all): 
operator Orange, in France, DHCPv6-PD trial testing, re-connection 
involving around 30min off.  Which other cellular operator uses DHCPv6-PD.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Feb 2019 16:44:33 +0100

Le 13/02/2019 à 15:59, Richard Patterson a écrit :
> RAs with lifetime 0 to deprecate the old prefix on the LAN side.

Which lifetime?  Prefix Information Option's (PIO's) Valid Lifetime or 
Preferred Lifetime?

I doubt this deprecation work straightforwardly on stacks of user's 
laptops (Windows) on LAN side, unless one tries, of course.

I am saying it because recently confronted with linux absence of visible 
lifetime fields in Neighbor Cache, otherwise urgently needed for other 
contexts.

Alex

---

From: Richard Patterson <[email-masked]>
Date: Wed, 13 Feb 2019 15:57:54 +0000

> lifetime fields in Neighbor Cache, otherwise urgently needed for other

The preferred lifetime of the old prefix in a PIO.
I'm not aware of issues using this method to deprecate an address on
any of the common host implementations.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 13 Feb 2019 12:38:21 -0300

> seems to have resolve all of the issues for us, as far as we can tell.

It may solve the issues when/if implemented. For obvious reasons, you
cannot rely on this functionality being deployed -- hence it does nto
relieve us from improving the robustness of hosts.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Feb 2019 17:07:21 +0100

> any of the common host implementations.

not sure I can see two lifetimes (Valid, Preferred) of routes in routing 
table in host implementation linux with ip -6 r command.  Despite that, 
deprecation of addresses as you suggest may indeed work.

Alex

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Wed, 13 Feb 2019 17:38:12 +0100

> relieve us from improving the robustness of hosts.

Correct, I see the benefit in making host more robust and resilient - 
and making this a standard can only and just improve things, can't make 
them any worse.

However, CPE is also an important part of the game here. As said before 
and as heard from Richard, some huge operators are already deploying 
this "hack" where they write a PD to persistent storage and compare 
prefixes after reboots and this solves a lot of problems. Why not making 
this easy fix a recommended thing to do for everyone?

When talking about the provisioning part - IETF can't tell operators how 
to run networks (obviously), but what we can do here is to say "when 
assigning IPv6 prefix to a customer, identified by the same DUID, we 
must not assign a different prefix to the same DUID before the lifetime 
of PD that we set doesn't expire, otherwise you are breaking the 
protocol standards."

If somebody decides (for some bizzare reason) that it's a good idea to 
make CPEs with randomized DUID after every reboot, then they shall 
implement memorizing PDs in persistent storage across reboots and send 
ICMP packets after reboot to deprecate old prefix(es)

I think that extending a scope of our I-D to this three "advices" would 
bring at least some hope for improvement, as currently it can't be 
worse. Of course, things are easy for huge operators with home-brew CPEs 
and a lot of knowledge, but there are other, smaller and less deep-tech 
educated ISPs that could benefit from improved defaults.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Wed, 13 Feb 2019 17:40:34 +0100

On 13/02/2019 03:37, Fernando Gont wrote:>> 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.

Seriously? Same DUID should get the same PD inside the lifetime cycle 
(whatever lifetime is set, 1h or 30 years).

No requirement? Well, then we need one, do we?

Cheers, Jan

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 13 Feb 2019 17:43:38 +0000

> No requirement? Well, then we need one, do we?

Maybe it would be helpful to place such a requirement on the network equipment implementations, rather than the ISPs? It's really hard for an operator to meet "requirements" when the equipment either doesn't make it possible, makes it difficult, or increases cost (e.g., if this capability is enabled, this equipment will only be able to handle half as many customers). I'm not saying that is or isn't the case for any particular implementations for prefix delegation. But in my experience, the capabilities of deployed equipment play a *huge* role in an operator's deployment decisions and configurations.
Barbara

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Wed, 13 Feb 2019 19:58:43 +0100

On 13/02/2019 18:43, STARK, BARBARA H wrote:
>> Seriously? Same DUID should get the same PD inside the lifetime
>> cycle (whatever lifetime is set, 1h or 30 years).
>> 
> Maybe it would be helpful to place such a requirement on the network
> equipment implementations, rather than the ISPs? It's really hard for
> an operator to meet "requirements" when the equipment either doesn't
> make it possible, makes it difficult, or increases cost (e.g., if
> this capability is enabled, this equipment will only be able to
> handle half as many customers). I'm not saying that is or isn't the
> case for any particular implementations for prefix delegation. But in
> my experience, the capabilities of deployed equipment play a *huge*
> role in an operator's deployment decisions and configurations. 
> Barbara
> 

Dear Barbara,

Exactly right, you hit the nail on the head.

Operators would use whatever vendors implement and make available in 
configurations. If we make such a requirement a must in standard 
document, then I believe we place this requirement on vendors first, 
right? If vendors would build stuff that doesn't allow breaking the 
protocol, then life would be better.

However... I've seen many operators (also the ones that I worked for or 
with) placing feature requirements towards vendors and some of them 
were... well... strange, to be polite.

At this point if a request to do weird things with PDs comes from 
operator to vendor - a vendor should be in position to say "well, we 
like your request, but we can't do it because it's against the standard 
and would break the protocol".

Cheers, Jan

---

From: Lee Howard <[email-masked]>
Date: Wed, 13 Feb 2019 17:34:50 -0500

On 2/13/19 11:38 AM, Jan Zorz - Go6 wrote:
> However, CPE is also an important part of the game here. As said 
> before and as heard from Richard, some huge operators are already 
> deploying this "hack" where they write a PD to persistent storage and 
> compare prefixes after reboots and this solves a lot of problems. Why 
> not making this easy fix a recommended thing to do for everyone?
>
> When talking about the provisioning part - IETF can't tell operators 
> how to run networks (obviously), but what we can do here is to say 
> "when assigning IPv6 prefix to a customer, identified by the same 
> DUID, we must not assign a different prefix to the same DUID before 
> the lifetime of PD that we set doesn't expire, otherwise you are 
> breaking the protocol standards."
"you are breaking the protocol standards" only matters if it breaks 
interoperability. Otherwise you're trying to be protocol police.
> ICMP packets after reboot to deprecate old prefix(es)
Well, CPEs do get some strange ideas of what a DUID should look like. 
When I had the ability to influence CPE features, I told them how to 
build their DUID so it was predictable to me. (I forget which version I 
specified, but it included link layer address). Still didn't help with 
the mass of retail devices.
>
> I think that extending a scope of our I-D to this three "advices" 
> would bring at least some hope for improvement, as currently it can't 
> be worse. Of course, things are easy for huge operators with home-brew 
> CPEs and a lot of knowledge, but there are other, smaller and less 
> deep-tech educated ISPs that could benefit from improved defaults.

My perception is that lack of support for IPv6 at all, followed by lack 
of support for IPv6 transition mechanisms, is a much larger problem in 
CPE. This will simply become another RFC they aren't implementing.

Lee

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Feb 2019 10:33:46 +1100

> deprecation of addresses as you suggest may indeed work.

If you want to experiment, try the 'DeprecatePrefix' option of 'radvd'.

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Feb 2019 15:46:42 +1100

Hi Brian,

> All of the above. Seriously. Resilience to "things that should never happen" is basic good software engineering. The trick is to make sure that the resilience costs nothing when things are normal,…

(So I'm sure you know how to suck eggs ... c.f. RFC 1958 :-) )

I'm all for robustness, however there are also diminishing returns and
duplication of implementations and corresponding costs to avoid.

If this problem was a solved within each application (i.e. the problem
of unexpectedly failing transport layer connections caused by
unexpected IP address changes), it doesn't need to be solved at any of
the lower layers. Of course, trouble is, that imposes the recovery
mechanism implementation cost on each and every application that wants
or needs it.

I also think it is better to solve problems where or as close to where
their root cause is. The further away from the cause, the less
effective the solution may be, and also it may cost more to solve it.

The root cause of this issue is ISPs not providing a static/stable PD
prefix across CPE reboots, or reconnection to a different BNG caused
by link failure (e.g. landing on a different BNG after PPPoE PADI).

An ISP can eliminate that cause by providing customers with stable PD
prefixes. They may already have something quite similar if they've
supported IPv4 routed prefixes to customers via RADIUS/Framed-Route
(typically SOHO customers). They just need to build an IPv6 version of
it and use it for all of their customers.

The CPE proposal in this draft is an imperfect mitigation, distant
from where the cause exists. I don't disagree with it, however it
depends on CPE firmware developers, rather than something the ISP
itself can do.

When the CPE firmware is developed, it has to be tested and deployed.
If the ISP provides managed CPE, which can be a luxury compared to
some markets, then there will need to be 10s of 1000s if not 100s of
1000s of CPE firmware upgrades performed, outside of normal usage
hours. It the ISP doesn't provide managed CPE, then the lag on
deployment is in the order of years, because it depends on when
customers replace their, what they perceive to be perfectly
functioning harder until it fails, CPE. It's a lot of effort, and
conditional on the level of administrative control over CPE the ISP
has. It seems to me that an ISP solving it at the backend would be
easier, cheaper and more universal, meaning regardless of CPE type and
version.

So to me, the cheapest and best solution is for the an ISP to provide
a static/stable PD prefix to the customer (even though I've written
code to try to mitigate it i.e. . DeprecatePrefix and
DecrementLifetimes in radvd in the past.)

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 14 Feb 2019 10:01:18 +0000

> DecrementLifetimes in radvd in the past.)

Mark,

Largely, I agree with your rationale on this.  The problem is that ISPs 
will be loath to commit to a stable prefix for the lifetime of a 
customer account.  This approach doesn't scale for larger providers 
because it commits them to making routing compromises for the lifetime 
of customer accounts, e.g. injecting dynamically assigned prefixes into 
their routing tables.  Accretion of configuration fossils causes long 
term complexity problems.

Stepping back though, connectivity loss due to stale PDs is caused not 
by failure of a single component, but by a cascade of failures and 
miscommunications between multiple discrete components;  the core 
problem is how to deal with the transfer of state.   Most of the 
discussion in this thread has been centered around three ideas: changing 
SLAAC, state survival in CPEs, and suggesting that SPs implement design 
changes.  My take is that we should make suggestions about fixing all 
three problem areas, i.e. add a section to slaac-renum about SP design. 
Whether this would belong in a standards track document is open to 
question, though.  Perhaps it would be useful to document the proposed 
SLAAC changes in a ST document and have a separate document describing 
the stale PD problem, with guidelines for CPE vendors and SPs as to how 
the problem can be worked around.

Modifying SLAAC would be likely to take years to roll out to end hosts.

The other two suggestions - behavioural changes to CPEs and design / 
implementation changes on service provider networks - will require 
buy-in from cpe vendors and service providers.  Barbara's comments about 
equipment implementation limitations are spot on, and I think we will 
see some push back from SPs on this.

Regarding the discussion on DUIDs, it's hard to imagine why a CPE which 
can provide a persistent DUID and which has an active lease on a 
particular prefix would be provided with a different PD reply if it 
issues a request or renew after a reboot. There's an argument to make 
that SPs should refrain from punishing their customers with the 
limitations of their provisioning platform, particularly in a situation 
which can kill v6 connectivity for extended periods of time like this.

Conversely, a different DUID means different lease parameters, so the 
correct behaviour would be for the SP to assign a different dhcp reply, 
assuming the original lease was still active.  A SP can't generally 
second-guess the intentions of the CPE if it requests different parameters.

tl;dr: complex problem; no single solution.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Feb 2019 11:21:45 +0100

Mark,

Why not? This is already happening in IPv4. I've got from a major operator in Spain (and other operators in other countries do the same), the same IPv4 address for decades! I'm talking about residential services, with both DSL and GPON. Not to mention business services were you actually pay for that static address a monthly fee.

Any contract can have special clauses, that clearly indicate that "in case of major technology or network changes or similar events, renumbering can happen and in those situations the customers will be alerted with a minimum of 1 month" (this is just an example, I can think in many alternative wordings).

---

From: Richard Patterson <[email-masked]>
Date: Thu, 14 Feb 2019 10:40:19 +0000

> Any contract can have special clauses, that clearly indicate that "in case of major technology or network changes or similar events, renumbering can happen and in those situations the customers wil…

If we're ignoring the network topology issues, then the next obvious
issue is privacy and tracking.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Feb 2019 11:51:42 +0100

There are many other ways to track people. I don't really think that having a different prefix, even if it changes every few minutes, will avoid anyone to be tracked.

In addition to that, I think it is easy for operators to implement a policy such as a configuration web page for your connectivity where you can choose a non-persistent prefix to be changed in your network every "n" hours. Up to the ISP to decide if the default policy is "persistent" or "non-persistent".

Up to each ISP to decide if they allow the customer to choose the number of hours of persistence.

If I'm the one designing this web page, I will make sure to warn the users in the "non-persistent" option, with some text in the line of: "when your prefix is replaced, your network is shortly interrupted, so running transactions may break. In addition to that, it may happen that when the prefix is replaced due to a power out-age, reboot or reset of the router or other network devices, some other devices in your network may remember the old prefix for some time, and you may experience connectivity difficulties during that period".

So it is up to each user to balance if they want a "false privacy feeling" or "network stability and the ability to run services which not depend on crappy dynamic DNS service, which most of the time you also need to pay extra for, and are slower to reach".

Regards,
Jordi

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 14 Feb 2019 11:07:25 +0000

JORDI PALET MARTINEZ wrote on 14/02/2019 10:21:
> Why not? This is already happening in IPv4. I've got from a major
> operator in Spain (and other operators in other countries do the
> same), the same IPv4 address for decades! I'm talking about
> residential services, with both DSL and GPON. Not to mention business
> services were you actually pay for that static address a monthly
> fee.

The ietf isn't going to get operator buy-in for mandating static v6 
prefix assignments.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Feb 2019 12:11:21 +0100

I'm not saying that.

I was responding to "this approach doesn't scale ....".

Regards,
Jordi

-----Mensaje original-----
De: Nick Hilliard <[email-masked]>
Fecha: jueves, 14 de febrero de 2019, 12:07
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Mark Smith <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    
    Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 14 Feb 2019 11:23:02 +0000

> I was responding to "this approach doesn't scale ....".

"X doesn't scale" is shorthand for rfc 1925, section 2.3.

Nick

---

From: Richard Patterson <[email-masked]>
Date: Thu, 14 Feb 2019 11:38:05 +0000

> There are many other ways to track people. I don't really think that having a different prefix, even if it changes every few minutes, will avoid anyone to be tracked.

I agree that there are better ways, but IP addresses are still
considered personal data from a GDPR perspective, and courts also
generally agree that they are sufficient from a copyright infringement
enforcement perspective.
There's a bare minimum period of time a provider would have to
relinquish subscriber information when a copyright holder/enforcer
comes knocking, but not over and above that period.   If the rights
holder can infer that a subscriber had that IP/prefix indefinitely,
that may open up that subscriber to legal action for the entire
lifetime of them being a customer.

> In addition to that, I think it is easy for operators to implement a policy such as a configuration web page for your connectivity where you can choose a non-persistent prefix to be changed in your…

That's an additional platform and development work, on top of the
already non-trivial work required to extend the RADIUS platform to be
topology aware and integration with an IPAM or another method to
assign address/prefixes.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 14 Feb 2019 12:47:53 +0100

> generally agree that they are sufficient from a copyright infringement

Hmm... does that mean that also every enterprise network with staff 
accessing the Internet from their network should have dynamic prefixes 
and change all the time? I don't think that network people at all those 
companies would agree. It's similar to saying that your house number and 
street name are private information and needs to change every day. Or 
car registration plate number.... every time you start your car - your 
registration plate number must change, otherwise people can track you 
around your town as they know your registration number.

There has to be a limit somewhere in how much insanity someone would 
implement.

GDPR folx needs to understand that IPv6 was just not made for what they 
wish for and with irrational requests they are breaking it. What I 
suspect is that problem in this case is lack of technical understanding 
of privacy/GDPR folx how IPv6 works in reality and what the current 
limitations are. I've been telling them this for years now, but 
apparently not successfully enough :( Maybe someone else can also try ;)

Cheers, Jan

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Feb 2019 12:52:59 +0100

I know that IP addresses are considered personal data, but that doesn't mean they must be non-persistent. Only means that third parties (not the ISP) can't store that data without customer consent, and that the ISP can't provide that data to third parties. This is not different if is a non-persistent prefix!

If that's the case, we will have the same problem with employees in a business using persistent prefixes.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 14 Feb 2019 12:55:01 +0100

> The ietf isn't going to get operator buy-in for mandating static v6 

This is clear and understandable. Do you think they would buy-in the 
advice, that they need to honor the lifetime of a prefix to same DUID 
and give the same PD until it expires, unless there is an urgent network 
design change (moving customers to different BNG, emergency re-route 
because of outage, etc...) and at the same time make sure that CPE sends 
out RA packets with decrementing lifetime on LAN side, according to 
lifetime of PD?

Because at it stands now (if you are not the one with home-brew CPE 
where you fixed this with persistent storage of PD across reboots) - the 
only option that actually works on the field is to give users persistent 
prefixes and that's a fact that operators at large agreed about in 
RIPE-690 document.

So, at the end of a day, it may be in operators interest that we somehow 
fix the whole spaghetti chain between ISP and customer and give the 
advice how to make all 3 points in the network more robust and better 
cooperating between each other when it comes to IPv6...

Cheers, Jan

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 14 Feb 2019 12:10:32 +0000

> cooperating between each other when it comes to IPv6...

Pretty much.  The IETF can't demand that service providers change their 
design models.  What we can do, however, is to document known failures 
modes for common design choices and work with the various stakeholders 
to try to get these addressed.

Nick

---

From: Richard Patterson <[email-masked]>
Date: Thu, 14 Feb 2019 12:20:07 +0000

On Thu, 14 Feb 2019 at 11:48, Jan Zorz - Go6 <[email-masked]> wrote:
> companies would agree.

Bit of a different dynamic there, we have a moral obligation to
protect our customers, I imagine employers would have a different
feeling on the matter.

My point was rather that there are often reasons why an operator has
built things in such a way, and it's not always just because they
didn't understand IPv6 very well.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Feb 2019 08:13:02 +1300

Mark,

> the lower layers.

Logically that's true of course. But I'm not suggesting that every app
should watch out for this specific cause. I am suggesting that every app
should be written to recover from failing transport layer connections.
As far as I can see, that's already the case in most cases. (Coming
to you via Thunderbird, which seems highly resistant to transport
failures.)

Regards
   Brian

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 14 Feb 2019 20:23:53 +0100

On 14/02/2019 13:10, Nick Hilliard wrote:
>> So, at the end of a day, it may be in operators interest that we 
>> somehow fix the whole spaghetti chain between ISP and customer and 
>> give the advice how to make all 3 points in the network more robust 
>> and better cooperating between each other when it comes to IPv6...
> 

Agreed ;)

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 14 Feb 2019 20:26:45 +0100

> didn't understand IPv6 very well.

I know how much pressure sometimes politics people puts on operators and 
tries to steer how network design is done ;)

I believe that big operators understand IPv6 quite well and that's why 
things work well in their networks - but we still need to make defaults 
better so everyone else suffers less.

Cheers, Jan

---

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

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of JORDI PALET MARTINEZ

> I know that IP addresses are considered personal data, but that doesn't mean they must be non-persistent. Only means that third parties (not the ISP) can't store that data without customer consent,…

I've been diligently following this (enlightening) thread. But the privacy aspects of this desire to retain a persistent IPv6 prefix are undeniable. I'm not sure how to reconcile:

1. The strong recommendation against persistent or EUI-based IIDs,

2. The strong desire to have 64-bit IIDs, and

3. This idea of retaining a persistent CPE prefix.

If the prefix is known to be 64 bits wide, and is persistent, that prefix identifies a household every bit as positively as a persistent 64-bit IID identifies a device. How come we aren't seeing recommendations AGAINST persistent prefixes for CPE devices?

Bert

---

From: Mark Smith <[email-masked]>
Date: Fri, 15 Feb 2019 07:39:59 +1100

> didn't understand IPv6 very well.

I don't know about other markets, however dynamic IPv4 addresses on
permanent, always up broadband links in Australia has usually been
because ISPs wanted to charge a price premium for static address
assignments..

Even these IPv4 dynamic addresses may be more stable than most
realise. I'm not sure about other vendors, however Cisco's IOS
remembers these dynamic address assignments and if the customer's new
session lands on the same BNG, they'll get the same dynamic IPv4
address as before.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 15 Feb 2019 00:19:42 +0100

On 14/02/2019 20:30, Manfredi (US), Albert E wrote:
> If the prefix is known to be 64 bits wide, and is persistent, that
> prefix identifies a household every bit as positively as a persistent
> 64-bit IID identifies a device. How come we aren't seeing
> recommendations AGAINST persistent prefixes for CPE devices?

Because in current state of today generic 
ISP_provisioning/CPE/host_stack implementations combination it doesn't 
work properly in real environment. ISPs ASNs and IPv6 traffic gets 
blacklisted by large content providers that are measuring for broken 
IPv6 implementations. Happened many times, hence this effort to make 
situation better :)

To augment what many already have said here - it's a tie between IP 
address and household address and name/surname that should not be 
public, the address itself is mostly harmless and it doesn't matter if 
it's static or dynamic. Tracing gets done on L7 and above anyway ;)

Cheers, Jan

---

From: Christian Huitema <[email-masked]>
Date: Thu, 14 Feb 2019 21:57:41 -1000

> it's static or dynamic. Tracing gets done on L7 and above anyway ;)

In the current state of the web, if a user gets a new address, the
various web surveillance mechanisms will associate it with the previous
user identity and context after maybe a dozen web queries or two. That
gets better if the user has a strong defensive posture, blocks web
trackers, etc. But it just takes one cookie, or one login, or some other
inference, and poof, the surveillance databases know that new_address_X
is the same user as old_address_Y.

The case of the household is even worse. It takes only one cookie,
login, etc, and the surveillance databases will learn that new_prefix_P
is the same household as old_prefix_Q. Even you run Ghostery or Privacy
Badger or the latest release of Firefox, you won't escape if you share a
prefix with someone in your household who doesn't. Or with one of those
surveillance devices that masquerade as thermostats or light switches or
voice assistants.

So that's pretty bleak. If you want defense, you probably want to
allocate different /64 prefixes to different devices, and change them
really often. You may not need to change them for every devices -- no
point providing privacy to the surveillance thermostat. But for your
laptop, your tablet or your phone, they to change before the
surveillance advertisers see you access a dozen web pages or two.

-- Christian Huitema

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 15 Feb 2019 10:30:15 +0100

Exactly.

> surveillance advertisers see you access a dozen web pages or two.

/64 for each device is fine. What I'm questioning is if we really need 
to make underlying to be something that was never meant to be if L7 and 
above is broken? I think L7 and above needs to be fixed first and then 
changing of addresses in transport layer can have any effect. Until then 
- let's transport packets in a way that doesn't break often and make 
user grumpy.

To put "lipstick on a pig" is a rhetorical expression, but quite useful 
in our case :) :) :)

Cheers, Jan

---

From: Christian Huitema <[email-masked]>
Date: Thu, 14 Feb 2019 23:37:47 -1000

> On Feb 14, 2019, at 11:30 PM, Jan Zorz - Go6 <[email-masked]> wrote:
> 
> /64 for each device is fine. What I'm questioning is if we really need to make underlying to be something that was never meant to be if L7 and above is broken? I think L7 and above needs to be fixed first and then changing of addresses in transport layer can have any effect. Until then - let's transport packets in a way that doesn't break often and make user grumpy.

We are pretty far from the original thread, but let me say that looking at layers as if they were isolated does not work. Tracking uses all the cues that it can, from MAC addresses to GPU model. It will of course use 64 bit prefixes when available. That a beautiful index for the surveillance operations. It is pretty clear that we need to somehow defend against that.

-- Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 15 Feb 2019 10:40:19 +0100

/64 for every device is perfectly possible and I think it is wise, following RFC8273, so VMs inside a device can have their own addresses.

I see a scenario where (and I don't care if it is a residential or enterprise), a single persistent (unless the user explicitly wants it non-persistent) /48 is provided to the CE.

Then the CE can organize the /48 in different subnets. For example, devices (sensors that just report data), will get persistent or non-persistent /64s. Actuators (you need to talk to them, so you may want to have persistent addresses in the DNS), will get persistent /64. End-user devices (tablets, laptops, etc.), will have persistent or non-persistent /64s and finally, of course, if you have servers, you want to have the with persistent /64s.

I know everything could be non-persistent using dynamic DNS, but this is expensive, is extra services, and it is slow. I don't think it make sense for stable services.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Jan Zorz - Go6 <[email-masked]>
Fecha: viernes, 15 de febrero de 2019, 10:30
Para: Christian Huitema <[email-masked]>, <[email-masked]>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    Exactly.

    
    
    Cheers, Jan

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Feb 2019 10:53:20 +0100

Le 15/02/2019 à 10:30, Jan Zorz - Go6 a écrit :
[...]

> To put "lipstick on a pig" is a rhetorical expression, but quite useful 

I do not know what putting lipstick on a pig means, although I do 
remember this expression being used by or in relationship with a politician.

Signed contractual allocation of permanent IPv6 address, and of an IPv6 
prefix, to a (group of) mobile device, is an excellent thing for session 
continuity.

The privacy concerns are matters of L7 and above, specifically politics, 
computer-assisted human interactions, graphical user interfaces.  GDPR 
is one a politics answer for privacy.

GDPR itself has some issues when it comes to implementation: websites 
now invite the user to accept or not cookies, but the manner in which 
this is performed - a technical implementation - leads to accept more, 
or less.  Some times end users feel confident their privacy is 
respected, other times they feel they loose control of it, and worse - 
outright cheated.

In time, an example of this GDPR-enforced dialogue is the following 
related to cookie acceptance:
- first, there was 2 answers possible: yes, or no.  Exclusively.  You
   had to press something.
- then came the little cross on the window corner, to avoid answering
   altogether - do not leave any trace.  YEt the end user did not
   know whether the answer was yes or no when pressing that cross.
- recent dialogues involve a cross with only one default answer
  'Accept'.  How dare they to take my cross pressing as Accept.  I did
   not say 'Accept'.  I pressed a cross, or Escape button, to avoid
   answering the question.
- what I want in the future is cross closing the dialogue box and tell
   the website to shut up, dont trace me, dont use cookies.  Dont even
   record the fact that I pressed that cross.

Is that 3rd option part of GDPR?

This reminds of the cartoon showing the options possible for vote, 
during a particular campaign, in which only one option was actually 
possible: whatever button one pressed, the end result was the same.

This is the kind of privacy issues that need to be addressed.  It is 
level 7 and above.

This looks far from being a matter of using or not using stable IP 
addresses when querying a website.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Feb 2019 10:57:05 +0100

Le 15/02/2019 à 10:37, Christian Huitema a écrit :
>> /64 for each device is fine. What I'm questioning is if we really
>> need to make underlying to be something that was never meant to be
>> if L7 and above is broken? I think L7 and above needs to be fixed
>> first and then changing of addresses in transport layer can have
>> any effect. Until then - let's transport packets in a way that
>> doesn't break often and make user grumpy.
> 
> We are pretty far from the original thread, but let me say that
> looking at layers as if they were isolated does not work. Tracking
> uses all the cues that it can, from MAC addresses to GPU model. It
> will of course use 64 bit prefixes when available. That a beautiful
> index for the surveillance operations. It is pretty clear that we
> need to somehow defend against that.

Address the surveillance operations at their root would allow freedom to 
design session continuity IPv6 mechanisms safely assuming that the root 
of the surveillance operations is ok.

If possible :-)

(I can assure you that changing IP addresses all the time is a nightmare 
in implementations :-)

Alex

---

From: Christian Huitema <[email-masked]>
Date: Fri, 15 Feb 2019 00:30:15 -1000

> On Feb 14, 2019, at 11:57 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> (I can assure you that changing IP addresses all the time is a nightmare in implementations :-)

The alternative is of course some kind of onion routing for the masses. Or generalized VPN. I wonder about the trade off, in terms of both overhead and management.

Right now we have the bizarre property of having better privacy in a coffee shop than at home. That doesn't seem right.

-- Christian Huitema

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Feb 2019 11:53:17 +0100

Christian,

Thank you for the answer.  I generally agree.

Le 15/02/2019 à 11:30, Christian Huitema a écrit :
> The alternative is of course some kind of onion routing for the
> masses. Or generalized VPN. I wonder about the trade off, in terms of
> both overhead and management.

I will have to search for onion routing, before I can think about what 
trade-offs could be.

For 'generalized VPN' - I can safely say that we are a very long way 
from simply VPN with IPv6, let alone generalized :-)

OpenVPN open source well-known implementation has probably the easiest 
IPv6 capability of them all.  Yet it requires NAT IPv6 for the 
addressing architecture between real and virtual interfaces.  Worse, 
some reported a 'proprietary' (read 'unknown behaviour') intermediate 
layer used.

SoftEther, another less known open source implementation of VPN, does 
some form of IPv6 but can it's IPv6 cant work without having also IPv4 
addresses on it.

In this situation, adding security in a place where security is more 
important than just desirable, requires the use of IPv4 instead of IPv6.

> Right now we have the bizarre property of having better privacy in a
> coffee shop than at home. That doesn't seem right.

I fully agree with that.  It may be because that coffee shop is small 
enough to be manageable by a few persons who do consider privacy 
seriously.  Otherwise, I dont know why.

Alex

---

From: Markku Savela <[email-masked]>
Date: Fri, 15 Feb 2019 12:55:16 +0200

> Right now we have the bizarre property of having better privacy in a coffee shop than at home. That doesn't seem right.

On the other hand, I prefer to have have reasonably stable global 
routable IP4/6 addresses at home. Makes peer-to-peer applications easier 
to setup, if your address does not change every minute or hour, or whatever.

However, I'm also very much for privacy. If there is possibility to 
change address, the change trigger control should be on the user, not on 
operator...

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 15 Feb 2019 13:11:05 +0100

On 15/02/2019 10:53, Alexandre Petrescu wrote:
> Le 15/02/2019 à 10:30, Jan Zorz - Go6 a écrit : [...]
> 
>> To put "lipstick on a pig" is a rhetorical expression, but quite 
>> useful in our case :) :) :) >

Some politicians used this term, bit it's not tied to tehm :D

"To put "lipstick on a pig" is a rhetorical expression, used to convey 
the message that making superficial or cosmetic changes is a futile 
attempt to disguise the true nature of a product or person. "

https://en.wikipedia.org/wiki/Lipstick_on_a_pig

> addresses when querying a website.

It's a matter of other mechanisms tracking you independently of how 
often you change the IP address.

You can test some of this stuff here: https://panopticlick.eff.org/

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 15 Feb 2019 13:13:27 +0100

> need to somehow defend against that.

Actually, we are not very far from original thread, as sometimes 
operators are implementing PD to be "dynamic" also because of percieved 
privacy reasons and it's essential that we figure out if changing the 
prefixes dynamically adds anything to privacy or nothing.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 15 Feb 2019 13:15:27 +0100

On 15/02/2019 11:55, Markku Savela wrote:
>> Right now we have the bizarre property of having better privacy in
>> a coffee shop than at home. That doesn't seem right.
> 
> routable IP4/6 addresses at home. Makes peer-to-peer applications
> easier to setup, if your address does not change every minute or
> hour, or whatever.
> 
> change address, the change trigger control should be on the user, not
> on operator...

Bingo!

Cheers, Jan

---

From: Richard Patterson <[email-masked]>
Date: Fri, 15 Feb 2019 12:20:47 +0000

> > change address, the change trigger control should be on the user, not

And that mechanism already exists in the form of a DHCPv6 RELEASE, but
not if the assignment authority has been removed from the DHCPv6
Server, and placed within RADIUS instead.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Feb 2019 13:29:19 +0100

> Server, and placed within RADIUS instead.

I speculate RELEASE does not work with prefixes (like it does work with 
IA_NA addresses, but not with IA_PD prefixes).

Alex

---

From: Simon Hobson <[email-masked]>
Date: Fri, 15 Feb 2019 12:41:30 +0000

Alexandre Petrescu <[email-masked]> wrote:

> GDPR itself has some issues when it comes to implementation: websites now invite the user to accept or not cookies, but the manner in which this is performed - a technical implementation - leads to accept more, or less.  Some times end users feel confident their privacy is respected, other times they feel they loose control of it, and worse - outright cheated.
> 
> In time, an example of this GDPR-enforced dialogue is the following related to cookie acceptance:
> ...

Yes, cookie control has become a complete farce - and you missed out possibly the most annoying option, where clicking on the option to "manage cookies" just gives you a list of the (possibly) hundreds of trackers they use and links to the sites to control them. Many of them require you to create an online account (and thus accept their T&Cs and give them permission to track you !) before you can tick a box to "pretty please, think about not tracking me, though I don't trust you to honour this request".
I have a feeling things will settle down. At present some of the "big fish" are in the spotlight - like certain companies who's entire business case depends on not complying with GDPR. I have a feeling that sooner or later there will be some test cases over cookie control and misleading UIs.

Jan Zorz - Go6 <[email-masked]> wrote:

> "To put "lipstick on a pig" is a rhetorical expression, used to convey the message that making superficial or cosmetic changes is a futile attempt to disguise the true nature of a product or person. "
> 

Interestingly, "polish a turd" on Wikipedia redirects to the same page - the phrase having much the same meaning.

---

From: Richard Patterson <[email-masked]>
Date: Fri, 15 Feb 2019 12:58:41 +0000

> IA_NA addresses, but not with IA_PD prefixes).

I'm not sure why you'd speculate that, but it does IME.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Feb 2019 14:02:40 +0100

> I'm not sure why you'd speculate that, but it does IME.

I speculate that because I've never seen RELEASEing a prefix.  And I did 
see many other DHCP things working.

I dont know what you mean by IME.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Fri, 15 Feb 2019 13:05:39 +0000

> because ISPs wanted to charge a price premium for static address

That's the case in the UK as well. From my dealings with various of them over the years (with work hat on) I have come across a number of variations.
BT charges (or did last time I had any dealings) £5/mo for a single static IPv4 address - that may be a premium of as much as 15-20% but obviously less on a more expensive product. Since they run static and dynamic assignments on the same set of equipment/connections, and with permanent-on connections there's no IPv4 address saving with dynamic addressing, there's no technical reason to charge a monthly premium other than "because we can and it boosts profit margins".
TalkTalk does not allow static IPv4 on residential products, but does on business products. Naturally business products cost more, although they use the same set of infrastructure - so it's a purely marketing thing to stop a business that doesn't need a static IPv4 (or the slightly better service levels) paying less by using a "residential" product.

So yes, I think it's safe to assume that there's a strong profit driver towards doing anything that makes life "difficult" for any customer wanting a static address/prefix - eg for hosting services or running site-site VPNs. A lot of this is down to the competitive market we "enjoy" in the UK with a significant race to the bottom in terms of pricing among many of the ISPs - so anything that can lower the headline "from £xx" on adverts, while making it up on extras, is used. I don't expect IPv6 to be different if you want stable addressing.
So yes, I think the earlier reference to RFC 1925 (I'd forgotten about that one), section 2.3, is appropriate if pushing for stable addressing to be the norm.

Other ISPs are more reasonable. My own, Plusnet, charges a one-off setup when requesting a (single) static IPv4 and no premium thereafter.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 15 Feb 2019 14:55:27 +0100 (CET)

> see many other DHCP things working.

It would beneficial for everybody if you stopped speculating so much.

Here you go:

14:54:11.595732 IP6 (hlim 1, next-header UDP (17) payload length: 266) 
fe80::222:7ff:fe6f:1b36.546 > ff02::1:2.547: [udp sum ok] dhcp6 release 
(xid=2fec (elapsed-time 0) (option-request SIP-servers-domain DNS-server 
SNTP-servers NTP-server AFTR-Name opt_67 opt_96 opt_123 opt_198 opt_199 
SIP-servers-domain SIP-servers-address DNS-server DNS-search-list 
server-unicast SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_83 
opt_94 opt_95 opt_96) (client-ID hwaddr type 1 0022076f1b36) (server-ID 
hwaddr/time type 1 time 512640186 56847afe6699) (vendor-class) 
(Client-FQDN) (IA_PD IAID:1598115417 T1:0 T2:0 (IA_PD-prefix 
2003:1c09:24:1500::/60 pltime:0 vltime:0)) (IA_PD IAID:1230001238 T1:0 
T2:0 (IA_PD-prefix 2003:1821:24:1500::/60 pltime:0 vltime:0)) (IA_PD 
IAID:1448036688 T1:0 T2:0 (IA_PD-prefix 2003:1831:24:1500::/60 pltime:0 
vltime:0)))

14:54:12.241025 IP6 (class 0xe0, hlim 30, next-header UDP (17) payload 
length: 290) fe80::8678:acff:fe4b:15cc.547 > fe80::222:7ff:fe6f:1b36.546: 
[udp sum ok] dhcp6 reply (xid=2fec (client-ID hwaddr type 1 0022076f1b36) 
(server-ID hwaddr/time type 1 time 512640186 56847afe6699) (status-code 
Success) (IA_PD IAID:1598115417 T1:0 T2:0 (status-code Success)) (IA_PD 
IAID:1230001238 T1:0 T2:0 (status-code Success)) (IA_PD IAID:1448036688 
T1:0 T2:0 (status-code Success)))

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Feb 2019 14:47:12 +0000

Alex,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Friday, February 15, 2019 5:03 AM
> To: Richard Patterson <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: A common problem with SLAAC in "renumbering" scenarios
> 
> 
> 

DHCPv6 Release for IA_PD is no different than for IA_NA and others; it
works the same way.

Please also remember that RFC8415 is the new standard; RFCs 3315 and
3633 are obsoleted.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Feb 2019 16:00:00 +0100

> DHCPv6 Release for IA_PD is no different than for IA_NA and others; it

I agree - the packet dump showed IPv6 message RELEASE with IA_PD for 
prefixes.  My speculation was wrong.

> Please also remember that RFC8415 is the new standard; RFCs 3315 and

Noted, and congratulations for the new DHCP RFC.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 15 Feb 2019 16:47:43 +0000

> to you via Thunderbird, which seems highly resistant to transport

some browsers implement HE, which is useful.  TB handles some types of 
connection failures, but there are plenty of other failure modes which 
it cannot handle well (e.g. partial connectivity).  I suspect there are 
dragons down this route, starting out with how we might consider 
defining standardised APIs for reliable connection semantics to handle 
transport failures.  I.e. HE + lots more, cross-platform, cross-application.

Nick

---

From: Lee Howard <[email-masked]>
Date: Fri, 15 Feb 2019 14:28:10 -0500

On 2/15/19 4:30 AM, Jan Zorz - Go6 wrote:
> to make underlying to be something that was never meant to be if L7 
> and above is broken? I think L7 and above needs to be fixed first and 
> then changing of addresses in transport layer can have any effect. 
> Until then - let's transport packets in a way that doesn't break often 
> and make user grumpy.
>
If the problem is above layer 7, it's not in scope for the IETF. You 
might try HRPC.

In another message you said:

Nick Hilliard>> The ietf isn't going to get operator buy-in for 
mandating static v6 prefix assignments.

Jan Zorz> This is clear and understandable. Do you think they would 
buy-in the advice, that they need to honor the lifetime of a prefix to 
same DUID and give the same PD until it expires, unless there is an 
urgent network design change (moving customers to different BNG, 
emergency re-route because of outage, etc...) and at the same time make 
sure that CPE sends out RA packets with decrementing lifetime on LAN 
side, according to lifetime of PD?

Seems to me several operators have offered their opinions here. If you 
want more opinions, maybe ask a group of operators?

Lee

---

From: Sander Steffann <[email-masked]>
Date: Fri, 15 Feb 2019 22:20:24 +0100

Hi Lee,

> Seems to me several operators have offered their opinions here. If you want more opinions, maybe ask a group of operators?

Not a very helpful comment... I think the underlying problem here is that there is no technical solution available that solves stable IPv6 address delegation at residential scale in an acceptable way.

- For stable address delegation the routing inside the ISP becomes a mess, especially when it can't be guaranteed that a customer consistently ends up at the same BNG.
- To keep ISP networks scalable, prefixes are aggregated to (roughly) BNG level, making it impossible to keep prefix delegation stable at the customer's end

With IPv4 this didn't cause massive problems because NAT disconnected the LAN addresses from the WAN side at the customer's end. With IPv6 this is no longer the case and it does cause problems.

Stability at one end causes instability at the other end, and vice versa.
And as can be seen from this discussion it's still an unsolved problem...

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 15 Feb 2019 21:39:56 +0000

> And as can be seen from this discussion it's still an unsolved problem...

the underlying problem is how to transfer state information, and any 
transfer of state is going to cause headaches.

In the ipv4 world, we handled this by delegating state management to the 
CPE via NAT and by accepting that reboots would cause session resets. 
This is by no means a 100% solution, but it was broadly acceptable.

In the ipv6 world, the public addressing structures remove the 
insulating barrier of NAT, which causes the underlying state indirection 
to become visible again.

Nick

---

From: Simon Hobson <[email-masked]>
Date: Fri, 15 Feb 2019 21:49:58 +0000

Sander Steffann <[email-masked]> wrote:

> I think the underlying problem here is that there is no technical solution available that solves stable IPv6 address delegation at residential scale in an acceptable way.
> 

How is IPv6 different to IPv4 in this ?
Some ISPs seem to have no issue with providing static IPv4 addresses - so one /32 route per static customer. I don't see how one /[48|56|whatever] per customer is any different.

Here in the UK at least, some ISPs clearly have no problem with fixed addresses. Plusnet, for example, allow the end user to set their connection to a fixed address and nothing else changes other than the CPE being allocated the same address all the time. Sadly they ran a couple of IPv6 trials years ago and nothing has happened since :-(

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 15 Feb 2019 21:51:02 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Sander Steffann

> And as can be seen from this discussion it's still an unsolved problem...

Right, but I would come back to my previous point. In the IID discussions, a lot of time was spent justifying why stable IIDs are not a good idea, and testing was done to see what breaks when IIDs are changed frequently. If changing the IID is doable, seems not to break many applications, and is touted as a meaningful security measure, then those same considerations should apply to the prefix. Yet, we're not seeing a push for varying prefixes, as we got for keeping IIDs unpredictable or even short-lived.

Instead, now there's a shift in thinking, where changing the IPv6 address is not so useful for security (which I too have been thinking all along).

We should be consistent. Just as stable IIDs, even EUI-64 based IIDs, should be permissible, when they make sense (such as in enterprise networks), we are no longer depending on them or suggesting to do this. They are a special case. Perhaps the same ought to apply to stable prefixes. Networks which want those can use whatever means they need, such as non-volatile memory in CPE devices. Otherwise, they should not be recommended and not be the norm? Just asking. Maybe this problem should go away.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 21:14:31 -0300

> And as can be seen from this discussion it's still an unsolved problem...

While I'm not sure the extent to which one can completely solve the
problem, it *is* possible to make deployments way more robust that they
currently are.

Hopefully the next rev of our document will have things more thoroughly
spelled out.

Having thought about the problem for some time now, the lack of
robustness has a lot to do with these three items:

1) Inappropriate use of timers in SLAAC

Clearly, the whole point of having timers is that, when things go wrong,
they eventually go off. SLAAC uses default values for timers in the
order from one week to one month (!). That makes the timers completely
useless. They will never go off, and will never allow you do do anything
sensible about any problem scenario.

2) No mechanism to phase out addresses

If timers were used appropriately, you wouldn't need this. But with the
values that we currently use for SLAAC, hosts do need some smarts to
deprecate addresses and removing them. Otherwise,  an address that was
e.g. incorrectly advertised or that has become stale will be preferred
for one week and remain valid for a month. That's kind of insane.

3) Under-specification of the interaction between DHCPv6-PD and SLAAC

This is largely unspecified. Among other things, we should specify how
DHCPV6 timers are translated into SLAAC timers, that preivously-leased
prefixes should be announced with a lifetime of 0 to help remove them on
the LAN side, and also that the SLAAC timers should be dynamically
reduced as the lifetimes on the WAN-side are reduced. -- otherwise,
you'll be making promises on the LAN side based on promises you did
*not* get on the WAN side.

If we had always had 1) and 3), we probably wouldn't need 2) that much.
But the cat is out of the bag already, and we now also need 2), to deal
with scenarios where we don't have 2) and 3).

What we can achieve with the above is allowing nodes to have a more
timely reaction to network configuration changes -- infer that some
prefix has been phase out, unprefer the corresponding addresses, and
eventually remove them.

Other stuff that has been mentioned on this thread is unrelated: e.g.,
transport connections breaking. Yeah, of course this is important for
robustness, but is to be handled over layer-4, and is completely
unrelated to what we are discussing here.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 21:19:12 -0300

> transfer of state is going to cause headaches.

I'd say that, at the very least, we want the network to be able to, at
the very least, figure out when information has become stale, and clean
up after itself.

What we have right now is a situation in which if incorrect information
is advertised, or somehow that information becomes stale, it will remain
in use between 7 days (addresses still being preferred) to 30 days
(addresses still considered valid).

That's clearly unacceptable.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 21:36:19 -0300

Bert,

On 15/2/19 18:51, Manfredi (US), Albert E wrote:
> -----Original Message----- From: ipv6 <[email-masked]> On
> Behalf Of Sander Steffann
> 
>> - For stable address delegation the routing inside the ISP becomes
>> a mess, especially when it can't be guaranteed that a customer
>> consistently ends up at the same BNG.
>> 
>> - To keep ISP networks scalable, prefixes are aggregated to
>> (roughly) BNG level, making it impossible to keep prefix delegation
>> stable at the customer's end
>> 
>> With IPv4 this didn't cause massive problems because NAT
>> disconnected the LAN addresses from the WAN side at the customer's
>> end. With IPv6 this is no longer the case and it does cause
>> problems.
>> 
>> Stability at one end causes instability at the other end, and vice
>> versa. And as can be seen from this discussion it's still an
>> unsolved problem...
> 
> Right, but I would come back to my previous point. In the IID
> discussions, a lot of time was spent justifying why stable IIDs are
> not a good idea, and testing was done to see what breaks when IIDs
> are changed frequently. If changing the IID is doable, seems not to
> break many applications, and is touted as a meaningful security
> measure, then those same considerations should apply to the prefix.
> Yet, we're not seeing a push for varying prefixes, as we got for
> keeping IIDs unpredictable or even short-lived.

Agreed.

> Instead, now there's a shift in thinking, where changing the IPv6
> address is not so useful for security (which I too have been thinking
> all along).

That's certainly not me.

Please let me be crystal clear on this one: if you make prefixes stable,
then things like RFC4941 become mostly useless -- as an attacker, I
wouldn't need to care about the IID, because I'd use your prefix for
tracking.

I'm not arguing in favor of dynamic prefixes. But I'm not arguing
against them, either. -- there are trade-offs involved.

What we should not do is making stable prefixes a "must". In fact, we
are moving towards "do temporary-addresses only if you wish" when it
comes to address generation, so it wouldn't be consistent to try to
force stable prefixes.

> 
> We should be consistent. Just as stable IIDs, even EUI-64 based
> IIDs,

FWIW, we recommend against EUI-64 (see RFC8064 and RFC7721). You don't
need EUI-64 to get stable addresses -- that's what we have RFC7217 for.
But, as long as EUI-64 is not the default, and the user needs to do work
to go against the advice (i.e., SLAAC defaults to RFC7217, as it does)
I'm fine.

> should be permissible, when they make sense (such as in enterprise
> networks), we are no longer depending on them or suggesting to do
> this. 

Exactly.

> They are a special case. Perhaps the same ought to apply to
> stable prefixes. Networks which want those can use whatever means
> they need, such as non-volatile memory in CPE devices. Otherwise,
> they should not be recommended and not be the norm? Just asking.
> Maybe this problem should go away.

As usual, I think this is the tip of an iceberg. If things break when
you don't do stable prefixes, then that's an indication that there's
underlying network brittleness. It turns out that we have put state in
the middle of the network -- e.g. on the CPE -- and that the network
fails to recover from that.  The current SLAAC timers essentially tell
you that it will take nodes one week to un-prefer an address, and one
month to remove it. Clearly, that's unacceptable.

Clearly, a CPE crashing and rebooting is one scenario in which nodes may
end up with stale information. But there are many others (e.g., what if
radvd crashes and rebobots?  Does radvd advertise prefixes with a
lifetime of 0 when information is changed, or before the daemon is exiting?)

Yes, the network should behave more nicely. And I'm all for that. But we
should not rely on state in the network for the network to be robust.
That seems to go against the very Internet architecture and design
principles.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 22:50:30 -0300

Hi, Mark,

On 14/2/19 01:46, Mark Smith wrote:
[....]
> mechanism implementation cost on each and every application that wants

This is not an application problem. It is a network-layer problem.

> by link failure (e.g. landing on a different BNG after PPPoE PADI).

I disagree. The root of the problem is that, as is, SLAAC is extremely
bad in recovering from stale information. The case where the CPE crashes
and reboots is just one scenario.

[...]
> depends on CPE firmware developers, rather than something the ISP

Ultimately, the problem is in the host, which is using stale
information. Yes, the CPE may behave more nicely -- and we'd like that.
But that doesn't mean it should take the network 30 days to recover from
stale information. Making the CPE behave more nicely is certainly nice -
and we advocate that. But we want robust networks. Hence we also need
hosts to be smarter.

[...]
> DecrementLifetimes in radvd in the past.)

What you are doing is essentially trying to hide robustness problems by
forcing specific conditions under which things work well.

This would be the equivalent of requiring the network to provide
reliable data transfer and argue that TCP shouldn't implement checksums
and timeout/retransmission mechanisms.

Yeah, things work better when parties behave more nicely (e.g., to the
extent that is possible, hte more reliable the network is, the better).
That doesn't mean things should break if some boxes behave differently
(for whatever reason).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 22:58:06 -0300

On 14/2/19 07:01, Nick Hilliard wrote:
[....]
> three problem areas,

Exactly.

> i.e. add a section to slaac-renum about SP design.

FWIW, I wouldn't mind that.

> Modifying SLAAC would be likely to take years to roll out to end hosts.

That shouldn't discourage us to do the right thing. Meanwhile, in the
presence of these scenarios the possible outcome is that IPv6
connectivity fails, and HE ends up preferring IPv4.

That's bad. But as long as by the time we get to IPv6 only things work
well, that's nice.

> see some push back from SPs on this.

FWIW, I see anything other than updated/improved SLAAC behaviour as
"nice to have, but cannot be relied upon".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 23:00:04 -0300

> Why not? This is already happening in IPv4. I've got from a major operator in Spain (and other operators in other countries do the same), the same IPv4 address for decades! I'm talking about reside…

This doesn't apply everywhere.

I know of many cities where you might step on a strip, and cars will
stop. I know of quite a few others where they will not, no matter the
zebra or traffic lights.

Ultimately, the question is "do you wanna live?".

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 23:04:50 -0300

Jordi,

On 14/2/19 07:51, JORDI PALET MARTINEZ wrote:
> There are many other ways to track people. I don't really think that
> having a different prefix, even if it changes every few minutes, will
> avoid anyone to be tracked.

That's irrelevant.

A stable prefix makes it quite easier for anybody, no matter which
application is in use (even if non-web), to track users.

In the context of RFC7528, I don't believe we can make stable prefixes a
requirement for IPv6 not to break.

> In addition to that, I think it is easy for operators to implement a
> policy such as a configuration web page for your connectivity where
> you can choose a non-persistent prefix to be changed in your network
> every "n" hours. Up to the ISP to decide if the default policy is
> "persistent" or "non-persistent".
> 
> If I'm the one designing this web page, I will make sure to warn the
> users in the "non-persistent" option, with some text in the line of:
> "when your prefix is replaced, your network is shortly interrupted,
> so running transactions may break. In addition to that, it may happen
> that when the prefix is replaced due to a power out-age, reboot or
> reset of the router or other network devices, some other devices in
> your network may remember the old prefix for some time, and you may
> experience connectivity difficulties during that period".

Seriously?

You expect an average internet user to analyze trade-offs and even know
what a prefix is?

---

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

On 14/2/19 20:19, Jan Zorz - Go6 wrote:
> work properly in real environment. 

Yeah, we need to improve what we have. :-)

> ISPs ASNs and IPv6 traffic gets

Not really. RFC4941 and RFC7721 is actually and argument against that.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 23:33:02 -0300

> I know everything could be non-persistent using dynamic DNS, but this is expensive, is extra services, and it is slow. I don't think it make sense for stable services.

Of course, nobody would mandate dynamic prefixes everywhere -- in the
same way we don't mandate web servers to run over RFC4941.

That said, where privacy matters, using stable prefixes makes tracking
extremely trivial.

It is not the goal of this thread or our document to mandate any
specific way to build a network. However, you can't just rule out
dynamic prefixes.

And it would be a terrible poor engineering choice (and unapplicable, at
the end of the day) to based network robustness on the assumption that
prefixes do not change. Because for many networks, they do. The cat is
out of the bag already.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Feb 2019 23:36:06 -0300

> prefixes dynamically adds anything to privacy or nothing.

It certainly does. Same as it does changing IIDs (see RFC4941 and
RFC7721). Of course, this doesn't solve all the problems.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 15 Feb 2019 19:06:57 -0800

> Not really. RFC4941 and RFC7721 is actually and argument against that.
As does several public incidents where people were tracked on the
Internet by IP address (see ICE tracking illegal immigrants), and law
enforcement's fear of NAT because it creates untrackable addresses
under the right conditions
(https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online).

IP addresses can expose Personally Identifiable Information in
themselves-- the privacy threat is real. There's at least two drafts
on the subject:

draft-herbert-ipv6-prefix-address-privacy-00
draft-nordmark-id-loc-privacy-00

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 16 Feb 2019 06:02:42 +0100 (CET)

> Some ISPs seem to have no issue with providing static IPv4 addresses - so one /32 route per static customer. I don't see how one /[48|56|whatever] per customer is any different.

It isn't.

> Here in the UK at least, some ISPs clearly have no problem with fixed addresses. Plusnet, for example, allow the end user to set their connection to a fixed address and nothing else changes other t…

This very much comes down to network design and implementation. I have 
designed networks where there was no DHCP at all, the customer received a 
printed paper with instructions how to configure their WAN IPv4 address 
and DNS resolver addresses statically, and then this was it until they 
moved to a different address. This is fine, but not how most people build 
networks today. For that network, the access design was a media converter 
(ethernet DSLAM) and a router (L3 switch) and one vlan per customer, BCP38 
done in the DSLAM (because it could and it was easy to do there) and then 
customer aggregation of 29 customers per IPv4 /27 (RFC3069). Nowadays 
people build network with huge L2 aggregation domains (to run PPPoE or 
just AE over) to BNGs which typically aggregate tens of thousands of 
customers, and they like to be able to move people around between these 
BNGs. With that dynanisism having customer-unique routes becomes a real 
problem as now you can't just route larger prefixes to this BNG, now you 
need to update routing table entries as the customer session goes up/down.

I advocate the semi-static model, where the same address space is handed 
out as long as the customer is up and there are no network changes. This 
is what I have and it means my addresses (IPv4 and IPv6) change at a 
frequency of once per year or something like that. This is acceptable to 
me...

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 17 Feb 2019 01:15:37 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Mikael Abrahamsson

That's much like my ISP is doing. With IPv4, as long as I don't reboot my home router, the WAN side IP address remains the same. Occasionally, the ISP remotely reboots my CPE, and then too, the WAN facing IP address changes.

What are the security aspects of this sort of operation, for IPv6? Well, if I were concerned about someone keeping track of the household, then I'd just reboot the CPE equipment more frequently. Done.

But this has nothing to do with someone tracking my own movements. If I bring my phone or PC to a library of coffee shop, I get a different IP address anyway. Even if the home IPv6 prefix remains fixed, one's movements outside the home aren't impacted. Still (repeating myself), since the IETF has been so diligent in recommending against the use of EUI-64, and for random and even short-lived privacy IIDs, it only makes sense for the IETF to not spend a lot of time finding ways to keep your IPv6 home prefix static.

To solve this problem, it seems more beneficial to make appropriate changes to SLAAC, than anything else.

Bert

---

From: Tom Herbert <[email-masked]>
Date: Sat, 16 Feb 2019 18:13:08 -0800

On Sat, Feb 16, 2019, 5:16 PM Manfredi (US), Albert E <
[email-masked] wrote:

> That's much like my ISP is doing. With IPv4, as long as I don't reboot my
> home router, the WAN side IP address remains the same. Occasionally, the
> ISP remotely reboots my CPE, and then too, the WAN facing IP address
> changes.
>
> What are the security aspects of this sort of operation, for IPv6? Well,
> if I were concerned about someone keeping track of the household, then I'd
> just reboot the CPE equipment more frequently. Done.
>

Albert,

That technique is easily defeated by "always connected" applications. After
an address change, the application logs into the server and the server logs
identity, address, and a timestamp. Then it's just a matter of applying the
server logs to infer identities in unrelated traffic

Increasing frequency of address change might make it a little harder to
track users, but I think it's mostly a false sense of security in reality.
If a user really cares about privacy they want single use untrackable
addresses.

Tom

> But this has nothing to do with someone tracking my own movements. If I
> bring my phone or PC to a library of coffee shop, I get a different IP
> address anyway. Even if the home IPv6 prefix remains fixed, one's movements
> outside the home aren't impacted. Still (repeating myself), since the IETF
> has been so diligent in recommending against the use of EUI-64, and for
> random and even short-lived privacy IIDs, it only makes sense for the IETF
> to not spend a lot of time finding ways to keep your IPv6 home prefix
> static.
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 17 Feb 2019 20:05:03 +0000

From: Tom Herbert <[email-masked]> 

> That technique is easily defeated by "always connected" applications. After an address change, the application logs into the server and the server logs identity, address, and a timestamp. Then it's just a matter of applying the server logs to infer identities in unrelated traffic 
>
> Increasing frequency of address change might make it a little harder to track users, but I think it's mostly a false sense of security in reality. If a user really cares about privacy they want single use untrackable addresses.

Agreed, Tom. But that only strengthens the point that going to great lengths to make IPv6 prefixes stable, when we've spent so much time doing the opposite with respect to the IID, seems self-contradictory. It seems more productive to fix whatever breaks, when the prefix changes. For instance, Fernando's points about SLAAC timers. That should be the main focus of the IETF, IMO. Ensuring permanent prefixes should be the odd exception, done with more or less extraordinary measures.

Bert

---

From: Ole Troan <[email-masked]>
Date: Sun, 17 Feb 2019 21:23:06 +0100

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

Lifetimes become quite useless, when the promise made with them is broken. They only serve then for garbage collection. 

If your model of networking is dynamically changing addresses, then don’t you need a rendezvous point for all inbound communication anyway? Guess then you will not have much benefit from a 128 bit address space either. 

Ole

---

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

-----Original Message-----
From: Ole Troan <[email-masked]> 

> If your model of networking is dynamically changing addresses, then don’t you need a rendezvous point for all inbound communication anyway? Guess then you will not have much benefit from a 128 bit…

Well, even if addresses can change, you still need lots of them, or you'll end up with conflicts.

But again, these arguments about apps surviving a reboot also existed with unpredictable and even short-lived IIDs, yet no one has suggested going back to totally predicable EUI-64. We seem to be doing that now, with static prefixes.

Apps can always be written to survive middlebox reboots, though, if that's important. If nothing else, the app can use its own session IDs, to bridge over short interruptions. I've seen some very credible objections by operators, on here, as to why long-term, permanent prefixes are problematic. That, plus consistency concerning previous privacy arguments, should be leading 6man to recommend against permanent prefixes? Not finding ways to ensure them?

Bert

---

From: Fernando Gont <[email-masked]>
Date: Sat, 16 Feb 2019 00:48:43 -0300

Bert,

> If the prefix is known to be 64 bits wide, and is persistent, that prefix identifies a household every bit as positively as a persistent 64-bit IID identifies a device. How come we aren't seeing re…

You nailed it ;-)

Yes, there are clear privacy implications to stable prefixes. There has
been some discussion on the topic (we did a bit in RFC7721). See e.g.:
draft-herbert-ipv6-prefix-address-privacy

This is yet another reason for *not* ruling out dynamic prefixes -- if
noting that "brittleness resulting from assuming state in the network is
a bad" is not enough.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 17 Feb 2019 21:27:24 -0300

Ole,

On 17/2/19 17:23, Ole Troan wrote:
[....]
>> 
>> Agreed, Tom. But that only strengthens the point that going to
>> great lengths to make IPv6 prefixes stable, when we've spent so
>> much time doing the opposite with respect to the IID, seems
>> self-contradictory. It seems more productive to fix whatever
>> breaks, when the prefix changes. For instance, Fernando's points
>> about SLAAC timers. That should be the main focus of the IETF, IMO.
>> Ensuring permanent prefixes should be the odd exception, done with
>> more or less extraordinary measures.
> 
> Lifetimes become quite useless, when the promise made with them is
> broken. They only serve then for garbage collection.

This is tricky. Robustness has a lot to do with being able to gracefully
deal with situations that "shouldn't happen".

If you asked me, yes, I'd love the network to behave nicer. That said, I
also want the network to be robust, and not break when e.g. a
crash-and-reboot event takes place.

> If your model of networking is dynamically changing addresses, then
> don’t you need a rendezvous point for all inbound communication
> anyway? Guess then you will not have much benefit from a 128 bit
> address space either.

I think you are mixing things up here.

1) No matter whether dynamic or stable prefixes are in use, the network
should be robust. The discussion of stable vs dynamic prefixes is
orthogonal to this document.

2) Many have argued in favor of temporary-only which, in some deployment
scenarios (e.g. mobile), makes sense. In scenarios where you'd go
temporary-only, then dynamic prefixes obviously make sense. Folks have
also noted reasons for which they may want to do dynamic prefixes. Your
network, your policy.

3) With "only allow outgoing communications" (RFC6092) plus IPv6 CPEs
not supporting uPNP, you do need a rendezvous point. Ironically enough,
I have dual-stacked boxes which I can reach directly via IPv4 (DDNS +
UPnP) but not over IPv6 (no way to punch holes in the v6 firewall). From
this point of view, the justification for v6 is that when/if we
eventually get to multiple layers of NAT, UPnP will not do the trick,
and by that time the CPE vendors will have figured out they should
include UPnP in their IPv6 CPEs.

---

From: Lee Howard <[email-masked]>
Date: Mon, 18 Feb 2019 13:32:48 -0500

> Not a very helpful comment... I think the underlying problem here is that there is no technical solution available that solves stable IPv6 address delegation at residential scale in an acceptable w…

The question was, "Would operators support this solution?" To that 
question, asking a group of operators seems to me to be a pretty sound 
suggestion.

I disagree that the problem to be solved is "stable IPv6 address 
delegation," and said so repeatedly and loudly when we worked on 
RIPE-690, along with the only other large operator involved in editing 
that document.

The problem to be solved is stale address state. Stable prefix 
delegation would be one solution. Better dynamic renumbering would be 
another, which could be handled in ways Fernando describes in his draft 
(draft-gont-6man-slaac-renum-00 in case anyone's forgotten), or several 
others

> And as can be seen from this discussion it's still an unsolved problem...

That's a good summary. Similar to Nick Hilliard's description of where 
the network state information lives.

We can try to solve this with locator-ID splits, but that solution space 
has been sitting around for a while, and I'm not sure it ultimately 
solves the problem. We can always add a layer of indirection (put a 
mapping somewhere) but it doesn't help the stub hosts.

Lee

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Feb 2019 12:05:18 -0800

> mapping somewhere) but it doesn't help the stub hosts.

Lee,

That's already being done in mobile networks where stub hosts are
mobile devices. Grant it, that is done for mobility not necessarily
for dynamic prefixes or privacy. Nevertheless, it does demonstrate the
mapping model necessary if addressing and topological routing are
disassociated (aka identifier-locator split).

Tom

---

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

> 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: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 19 Feb 2019 06:05:30 +0100

On 18/02/2019 19:32, Lee Howard wrote:
>>> Seems to me several operators have offered their opinions here. If 
>>> you want more opinions, maybe ask a group of operators?
>> Not a very helpful comment... I think the underlying problem here is 
>> that there is no technical solution available that solves stable IPv6 
>> address delegation at residential scale in an acceptable way.
> 

I was thinking about that. ;)

> RIPE-690, along with the only other large operator involved in editing 

You did. But RIPE-690 was all about documenting current reality of 
operational environments and practices that can work today and not about 
the future where we want to go.

Shaping the future where we want to go is taking place with this I-D and 
now it's time to say how we want the deployment of IPv6 protocol at 
various network (end)points to be done.

> (draft-gont-6man-slaac-renum-00 in case anyone's forgotten), or several 

Making end-host more robust doesn't hurt. Giving a good advice on how to 
build a CPE to be nicer towards the host doesn't hurt. Mandating 
operators to honour the lifetime of PD that they set themself and not 
change prefix before expiry (if there is no emergency situation in the 
network) would also help.

> 
> 
>>
>> - For stable address delegation the routing inside the ISP becomes a 
>> mess, especially when it can't be guaranteed that a customer 
>> - To keep ISP networks scalable, prefixes are aggregated to (roughly) 
>> BNG level, making it impossible to keep prefix delegation stable at 
>> the customer's end
>>
>> With IPv4 this didn't cause massive problems because NAT disconnected 
>> the LAN addresses from the WAN side at the customer's end. With IPv6 
>> this is no longer the case and it does cause problems.
>>

My immediate reaction would be "as far on the edge as possible" :)

> mapping somewhere) but it doesn't help the stub hosts.

I believe that proposed change in ND in this I-D would do the job. But 
I'm obviously biased ;)

Cheers and thnx, Jan

---

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: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Feb 2019 09:26:01 +0100

> question, asking a group of operators seems to me to be a pretty sound 

I think it is very relevant to ask at least one operator whether 
DHCPv6-PD gives a stable prefix to a home or mobile user.

Alex

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 19 Feb 2019 10:37:19 +0100

> There is no reason for hosts to deprecate addresses in 2001:db8:3::/64.

Dear Jen,

In theory you are correct.

In practice - at residential home or SOHO environment we rarely see a 
corner case that you described. I'm not saying it's incorrect, but I 
would say - very very rare.

We really need to address the big elephant in the room first and enable 
operators to deploy IPv6 on a massive scale in architectural way that 
they choose. We ignored it for too long now. :)

Cheers and thnx, Jan

P.S: I hope that we can have this discussion at IPv6 WG meeting at RIPE 
in Reykyavik in May and bring some additional operational feedback to 
this mailing list ;)

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Feb 2019 23:14:08 +1100

> - To keep ISP networks scalable, prefixes are aggregated to (roughly) BNG level, making it impossible to keep prefix delegation stable at the customer's end

It's not a hard requirement to aggregate prefixes at the individual
BNG level, and most ISPs should be running BGP to carry customer
routes. Obviously BGP to scale to 100s of 1000s of routes because the
Internet runs with it.

The minimum PD stability needed for fixed access customers (e.g. ADSL,
FTTH etc.) is within the pool of BNGs they can attach to upon
reconnection. So if you need or want to aggregate those routes, you
place the BGP route aggregation boundary at the boundary of your BNG
pool, rather than at the individual BNG. You then say to your
customers that if they physically move their service by e.g. moving
house, they may not receive the same stable PD prefix again, because
you're not guaranteeing they will reconnect to the same BNG pool.

It would however be nice to try to provide the customer with a stable
prefix on a greater scale than just within the same BNG pool, so you
could pick greater geographic boundaries for your aggregation points,
rather than at the boundary of an individual BNG pool. For example,
here in Australia, I'd try to aim for that boundary to be at each of
the 7 capital city boundaries, even though I may have multiple PoPs
within a city, with each PoP containing a number of BNGs in a pool
(and possibly multiple BNG pools within a PoP). Smaller aggregation
domains e.g. dividing cities into 4 regions might be necessary
depending on numbers of subscribers.

You can still provide a guaranteed static and persistent PD prefix to
customers that want to pay for it, which means that prefix isn't ever
aggregated and can follow them regardless of where they geographically
because you never aggregate that prefix. They're paying for and
getting more value because they're getting a guarantee.

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Feb 2019 13:22:18 +0100

> getting more value because they're getting a guarantee.

Indeed. Wonder how these pesky mobile phone operators manage to deliver the same telephone number to a user, for years. Across different providers and contracts.
I can’t think this argument is anything but a strawman.

There’s nothing a bit of regulation can’t fix. :-)

Ole

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 19 Feb 2019 13:48:56 +0100

On 19/02/2019 13:22, Ole Troan wrote:
> Indeed. Wonder how these pesky mobile phone operators manage to
> deliver the same telephone number to a user, for years. Across
> different providers and contracts. I can’t think this argument is
> anything but a strawman.

Ole,

 From general architecture point of view I'm also a big proponent of 
static prefix delegations. However, operators have different operational 
requirements and I think it's fair to make end host (and CPE) more 
robust to accommodate different architecture designs.

Making things more robust and resilient can't hurt, can it? :)

> There’s nothing a bit of regulation can’t fix. :-)

Careful what you wish for ;)

Cheers, Jan

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 Feb 2019 12:57:10 +0000

Ole Troan wrote on 19/02/2019 12:22:
> different providers and contracts.

Ole,

if recommending static IP addressing is an idea that 6man wants to push, 
you'll need to reach out to the security and ops areas to get their 
input on this.  I'm not sure this is an issue that 6man can resolve fully.

> There’s nothing a bit of regulation can’t fix. :-)

I'm sure you didn't mean to invite regulatory enforcement :-)

Nick

---

From: Sander Steffann <[email-masked]>
Date: Tue, 19 Feb 2019 13:55:01 +0100

> Indeed. Wonder how these pesky mobile phone operators manage to deliver the same telephone number to a user, for years. Across different providers and contracts.

Tunnels and the phone equivalent of NAT :)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Feb 2019 14:07:33 +0100 (CET)

> Indeed. Wonder how these pesky mobile phone operators manage to deliver the same telephone number to a user, for years. Across different providers and contracts.

They use a directory to convert between the stable identifier used, and 
the temporary one that can be changed, so that the stable identifier is 
fairly easily handled by humans. If only we would have that...

Oh, wait... we do. DNS.

You don't dial your IMSI identifier number nor your IMEI. You dial your 
phone number which when your IMSI or IMEI changes, the phone number is 
changed to reflect the new reality. Also you can't have session continuity 
as you change IMSI or IMEI.

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Feb 2019 14:08:54 +0100

Nick,

> On 19 Feb 2019, at 13:57, Nick Hilliard <[email-masked]> wrote:
> 
> if recommending static IP addressing is an idea that 6man wants to push, you'll need to reach out to the security and ops areas to get their input on this.  I'm not sure this is an issue that 6man can resolve fully.

It’s been the IPv6 addressing model for at least 20 years, so I think the other areas have had ample time to provide their input.

There has also been quite a lot of work on IPv6 renumbering mechanisms. Which if used does handle the case where a customer needs to be renumbered, without causing significant disruption. 

If we want to do significantly better, (as in handle flash renumbering etc) we need to look towards “session layers”, changing transport protocols. 

> I'm sure you didn't mean to invite regulatory enforcement :-)

So far the ISP industry has managed to stay largely self-regulated. Let’s hope it can continue that way. But that doesn’t mean the IETF should accommodate “operators cannot provide service with fixed addresses”. 

Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Feb 2019 14:11:54 +0100

> On 19 Feb 2019, at 14:07, Mikael Abrahamsson <[email-masked]> wrote:
> 
> They use a directory to convert between the stable identifier used, and the temporary one that can be changed, so that the stable identifier is fairly easily handled by humans. If only we would have that...
> 
> Oh, wait... we do. DNS.

Or LISP or ILNP or mobile IP orany of the other map and encap schemes. 

Cheers 
Ole
> 
> You don't dial your IMSI identifier number nor your IMEI. You dial your phone number which when your IMSI or IMEI changes, the phone number is changed to reflect the new reality. Also you can't have session continuity as you change IMSI or IMEI.
> 
> --

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Feb 2019 14:15:59 +0100

> if recommending static IP addressing is an idea that 6man wants to
> push, you'll need to reach out to the security and ops areas to
> get their input on this.  I'm not sure this is an issue that 6man
> can resolve fully.

I like static addresses, but it strikes me as a bad idea to limit ourselves
to static addresses at relatively low protocol levels. 

SLAAC already has plenty of protocol mechanism to deal with changing addresses.
What is left is tying that to DHCP-PD.

I have observed many cases where a host that moves from one network to
another doesn't see a link down event. This is most common with VMs that run on
a laptop. 

This means that hosts need to have a robust way of detecting that the network
environment has changed. There is no reason to assume that routers will have
either unique link local address or unique mac addresses.

At the same time, CPEs that are not cheapest-of-cheapest typically have a 
logfile and record diagnostic information. Adding a bit of flash that lasts
the lifetime of the CPE doesn't cost that much. So there is plenty of room
to specify what a CPE should do.

Whether users get stable prefixes or not should be a matter of policy, not 
something we hardwire in protocols. The latter just leads to situations
where users get told to reboot all of their devices.

---

From: Tim Chown <[email-masked]>
Date: Tue, 19 Feb 2019 13:30:25 +0000

On 19 Feb 2019, at 13:08, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:

Nick,

On 19 Feb 2019, at 13:57, Nick Hilliard <[email-masked]<mailto:[email-masked]>> wrote:

Ole,

It's been a while since we had an active IPv6 renumbering WG.  It must be time (again).... ;)

https://datatracker.ietf.org/wg/multi6/about/, b. 2001, d. 2007
https://datatracker.ietf.org/wg/6renum/about/, b. 2011, d. 2013

Indeed.

Tim

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Feb 2019 14:42:09 +0100

Le 19/02/2019 à 13:22, Ole Troan a écrit :
>>>> Seems to me several operators have offered their opinions
>>>> here. If you want more opinions, maybe ask a group of
>>>> operators?
>>> 
>>> Not a very helpful comment... I think the underlying problem
>>> here is that there is no technical solution available that
>>> solves stable IPv6 address delegation at residential scale in an 
>>> acceptable way.
>>> 
>>> - For stable address delegation the routing inside the ISP 
>>> becomes a mess, especially when it can't be guaranteed that a 
>>> customer consistently ends up at the same BNG. - To keep ISP 
>>> networks scalable, prefixes are aggregated to (roughly) BNG 
>>> level, making it impossible to keep prefix delegation stable at 
>>> the customer's end
>>> 
>> 
>> routes. Obviously BGP to scale to 100s of 1000s of routes because
>> the Internet runs with it.
>> 
>> The minimum PD stability needed for fixed access customers (e.g. 
>> ADSL, FTTH etc.) is within the pool of BNGs they can attach to upon
>> place the BGP route aggregation boundary at the boundary of your
>> BNG pool, rather than at the individual BNG. You then say to your
>> house, they may not receive the same stable PD prefix again,
>> because you're not guaranteeing they will reconnect to the same BNG
>> pool.
>> 
>> It would however be nice to try to provide the customer with a 
>> stable prefix on a greater scale than just within the same BNG 
>> pool, so you could pick greater geographic boundaries for your 
>> aggregation points, rather than at the boundary of an individual 
>> BNG pool. For example, here in Australia, I'd try to aim for that 
>> boundary to be at each of the 7 capital city boundaries, even 
>> though I may have multiple PoPs within a city, with each PoP 
>> containing a number of BNGs in a pool (and possibly multiple BNG 
>> pools within a PoP). Smaller aggregation domains e.g. dividing 
>> cities into 4 regions might be necessary depending on numbers of 
>> subscribers.
>> 
>> You can still provide a guaranteed static and persistent PD prefix 
>> to customers that want to pay for it, which means that prefix
>> isn't ever aggregated and can follow them regardless of where they 
>> geographically because you never aggregate that prefix. They're 
>> paying for and getting more value because they're getting a 
>> guarantee.
> 
> deliver the same telephone number to a user, for years.

It's called 'RIO' in France (Relevé d'Identité Opérateur).

That RIO contains some identifiers and the phone number.

This RIO could probably contain the IPv6 /56 prefix.

Alex

> Across different providers and contracts. I can’t think this argument
> is anything but a strawman.
>

---

From: Lee Howard <[email-masked]>
Date: Tue, 19 Feb 2019 10:20:42 -0500

> routes. Obviously BGP to scale to 100s of 1000s of routes because the
Thank you for telling me what protocol I should be using in a specific 
part of my network.
> you're not guaranteeing they will reconnect to the same BNG pool.

You seem to be arguing that the network engineers and architects at very 
large ISPs do not understand their network or routing or equipment. You 
are telling people how to design and build their networks.

> depending on numbers of subscribers.
Cool. Go ahead and build your network your way.
> getting more value because they're getting a guarantee.

You can do whatever you like on your network.

Lee

---

From: Lee Howard <[email-masked]>
Date: Tue, 19 Feb 2019 10:29:42 -0500

> I can’t think this argument is anything but a strawman.

You are saying he (maybe others) is either a liar, intentionally 
creating false arguments, or a fool, not understanding the network.

Your insinuation that fixed network operators must be doing something 
fundamentally wrong because mobile voice networks work differently is 
ignorant and insulting.

That's out of line for a working group chair.

> There’s nothing a bit of regulation can’t fix. :-)

Because of the smiley I don't know how to interpret this. Either you 
actually think regulation would work, and the question is whether you 
mean governmental or IETF, or you don't, in which case there's no 
argument that 6man should tell network operators they're doing it wrong.

Lee

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 Feb 2019 16:16:14 +0000

Ole Troan wrote on 19/02/2019 13:08:
> It’s been the IPv6 addressing model for at least 20 years, so I
> think the other areas have had ample time to provide their input.

dynamic-assignment addressing protocols tend to assign dynamically.  As 
Barbara notes, the stability period may be long but there is no 
guarantee that things won't change, especially in the ipv6 world (the 
caida study refers almost exclusively to ipv4).  Addressing tends to be 
sticky, not static.

> So far the ISP industry has managed to stay largely self-regulated. 
> Let’s hope it can continue that way.

Not inviting regulation would be a good start in this department.

> But that doesn’t mean the IETF should accommodate “operators cannot
> provide service with fixed addresses”.

We're not talking about that though - all (or nearly all) operators can 
provide static IP addressing and factor this into their design models 
and businesses to one degree or other.  What you seem to be talking 
about is whether operators should default to exclusively using static 
prefix assignments.  This is unrealistic at best.

Nick

---

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

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan

> They use a directory to convert between the stable identifier used, and the temporary one that can be changed, so that the stable identifier is fairly easily handled by humans. If only we would hav…

Exactly. An extra layer of abstraction is introduced in mobile telephony, and the "telephone number" now becomes merely a unique identifier, not used for routing. So the example is much more similar to say, what the enum wg did in the past, to convert telephone numbers into IP addresses, and really nothing to do with IP addresses as they relate to routing packets, and never mind the security/privacy issues that have been elaborated for so long, with respect to stable IIDs.

In short, if the IETF were to push for stable IPv6 addresses to customers, especially mobile customers, then the route aggregation problems don't go away, nor do the security and privacy problems. They become hidden underneath this upper layer of abstraction.

The privacy concern I think we have been trying to alleviate is to make that actual IPv6 prefix, the one used for routing packets, not permanently linked to the same household, for all time. Any abstract, DNS-like, IP address, which is mapped to the actual IPv6 address, is not really the issue here, I don't think.

Bert

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Feb 2019 13:03:38 -0800

> Exactly. An extra layer of abstraction is introduced in mobile telephony, and the "telephone number" now becomes merely a unique identifier, not used for routing. So the example is much more simila…
I believe in mobile networks it the stable identifier of a device is
an IMSI. It would be a very bad idea to create IP addresses that embed
an IMSI, there is not security or privacy in that. It's similar to how
MAC addresses shouldn't be encode in IP addresses. So there is always
at least some decoupling between identity and address. As the demand
for secuirity and privacy increases, the need for decoupling them
increases as well. Taking that to its fullest extent, maximum privacy
and security happens when addresses are completely decoupled from
identity so that a third party cannot make any inference or
correlations about identity, location, or any other PII just based on
observation of IP addresses in packets. That requires very dynamic
addressing.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Feb 2019 23:50:25 -0300

> It’s been the IPv6 addressing model for at least 20 years, so I think the other areas have had ample time to provide their input.

For the reasons stated in draft-gont-6man-slaac-renum, I don't think
this affects the discussion we are having. But, out of curiousity,
where's the "addressing model" you are referring to documented?

Thanks,

---

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

> It’s been the IPv6 addressing model for at least 20 years, so I think the other areas have had ample time to provide their input.

According to
<https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf>
close to 40% of the real world doesn't follow that model you are
referring to.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2019 04:11:19 +0100

> On 20 Feb 2019, at 03:50, Fernando Gont <[email-masked]> wrote:
> 

I can’t see slaac-renum tackling these issues.Which reasons are you referring to?

With regards to the addressing model, your question shows a certain lack of history, but given that we all gave lived under the reigns of NAT for so long. Allow me to turn it around. How do you expect the network to work with addresses being of arbitrary lifetime (the effect of flash renumbering) and where is that described? Start with a long-lived TCP session, with the listening peer sitting in one of these networks. 

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Feb 2019 17:02:20 +1300

Maybe everybody could read up on previous rounds of discussion:

https://tools.ietf.org/html/rfc4192
https://tools.ietf.org/html/rfc5887
https://tools.ietf.org/html/rfc6866
https://tools.ietf.org/html/rfc6879
https://tools.ietf.org/html/rfc7010
(In that last one, the section "Gaps Considered Unsolvable"
might be of interest.)

Yes, the topic was site renumbering, not host renumbering. But
the assumption has always been that renumbering should be a routine
event in IPv6. (Those of us who had to manage IPv4 site renumberings,
especially before the advent of DHCP, have always been sensitive on
this topic.) Thus, hosts need to be ready for renumbering at any time,
without notice.

Better I think to focus on Fernando's specific issue.

Regards
   Brian Carpenter

---

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

> I can’t see slaac-renum tackling these issues.Which reasons are you referring to?

A significant percentage of IPv6 deployments don't employ static
prefixes but dynamic prefixes. That's a deployment reality.

How you (or me) would like things to be doesn't change deployed reality.

Our I-D tries to deal with such deployed reality.

> With regards to the addressing model, your question shows a certain lack of history, but given that we all gave lived under the reigns of NAT for so long. 

You have been referring to an addressing model that implies
static/stable addressing. I simply asked where that model is described.

If such requirement is not spelled out somewhere, I don't know why you'd
refer to that as a model, or even why you could expect it.

Not sure how my question for a reference that backs your model can turn
into something I'm supposed to be lacking, missing, or ignoring.

---

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: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2019 05:54:31 +0100

> On 20 Feb 2019, at 04:35, Fernando Gont <[email-masked]> wrote:
> 

There’s a defined way to do IPv6 renumbering, which involves overlapping new and old prefixes. 
There seems to be some people arguing that renumbering without an overlap is a supported case in IPv6. It is not. 

That is although related, not the problem you are looking at. 

Ole

---

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

Well, significant ... 37% dynamic, vs. 63% static.

And from the dynamic ones, 40% allows to be static. From that 38% charge extra cost for it (on top of stable IPv4, if provided).

Regards,
Jordi

---

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: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 02:03:52 -0300

> (In that last one, the section "Gaps Considered Unsolvable"

Thanks a lot for the pointers. I quickly checked RFC7010 (the section
title made me curious), specifically:

10.1.  Address Configuration

   o  RA Prefix Lifetime Limitation

      Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime
      is greater than 2 hours or greater than RemainingLifetime, set the
      valid lifetime of the corresponding address to the advertised
      Valid Lifetime."  So when renumbering, if the previous
      RemainingLifetime is longer than two hours, it is impossible to
      reduce a prefix's lifetime to less than two hours.  This
      limitation is to prevent denial-of-service attacks.

This seems a flaw in RFC4862 to me. Me, I think ND security boils down
to: modulo some basic sanity checks, you trust the RAs, or you don't.
There's not much of a point in sanitizing the Prefix Lifetimes and then
honoring Router Lifetimes of 0, or even blindly trusting RAs that would
make you configuring addresses from invalid prefixes, RAs that might
override your preferred router with one with higher preference, etc.

That aside, in the context of RFC8028, it would seem to me that any
prefix lifetimes larger than the Router Lifetime don't make much sense.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 02:16:46 -0300

> Well, significant ... 37% dynamic, vs. 63% static.

Of course it's significant. Would you consider 37% failure rate acceptable?

> And from the dynamic ones, 40% allows to be static. From that 38% charge extra cost for it (on top of stable IPv4, if provided).

I don't care about "allows". Either it works by default, or it doesn't.
If you expect a normal user to enter an ISP's web site and make
decisions about prefixes or pay more to workaround the lack of
robustness of what we ship, you are doing very bad engineering.

It puzzles me that instead of trying to improve things, some seem to
apply this problem-solving methodology:
https://images-na.ssl-images-amazon.com/images/I/416cjJcmM-L.jpg

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 02:34:42 -0300

> There’s a defined way to do IPv6 renumbering, which involves overlapping new and old prefixes. 

There's a defined way to do *planned renumbering*, you might argue.
That's not what we are trying to address here -- even when the
improvements we propose end up helping in that area, anyway.

> That is although related, not the problem you are looking at. 

There's a variety of reasons for which a prefix may become stale without
explicit signaling. Jen has provided a more thorough list here:
https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00
.

What triggered our I-D is one of the cases in Jen's list, where a CPE
crashes and reboots. Version -01 of our I-D elaborates on many things
that contribute to the problem.

What we have right now is a system that is not robust. We want to
improve robustness. The outcome of burying our heads into sand will most
likely be people complaining about IPv6, and IPv6 connectivity failing
and hosts falling back back to IPv4 (thanks to HE).

Modulo folks that seem to be in favor of improving things, so far I seem
to have read:

* CPE vendors are shipping crap
* ISPs are clueless in what they build
* Some of us miss some clues about IPv6
* The 37% of network suffering from these issues are just marginal.

I don't think the above is doing us any favours. Actually, it seems a
lot like "problem solving" in
https://images-na.ssl-images-amazon.com/images/I/416cjJcmM-L.jpg . I'd
rather honor the "E" in IETF.

Thanks,

---

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

Of course, not acceptable. I'm not saying that is not a problem to be solved, just tried to make the data more precise. My reading of your text was like "dynamic is over static".

Saludos,
Jordi

-----Mensaje original-----
De: Fernando Gont <[email-masked]>
Fecha: miércoles, 20 de febrero de 2019, 14:38
Para: JORDI PALET MARTINEZ <[email-masked]>, Ole Troan <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    

    
    Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Feb 2019 15:06:01 +0900

On Wed, Feb 20, 2019 at 12:30 AM Lee Howard <[email-masked]> wrote:

> > Indeed. Wonder how these pesky mobile phone operators manage to deliver
> the same telephone number to a user, for years. Across different providers
> and contracts.

TBH, if anything I find your comment to be the one that is out of line.
Personally, Ole's remark seems like a humorous way to say that the two
problems are not that different and that since one of them has been solved,
we should probably be able to solve the other as well. In contrast, your
comment reads to me like an ad hominem attack which has a chilling effect
on debate.

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Feb 2019 17:16:07 +1100

> into something I'm supposed to be lacking, missing, or ignoring.

I think it is implicit in a lot of places, if not stated explicitly
anywhere (although it may be somewhere in an RFC like RFC1122).

- By default, hosts don't delete addresses from interfaces if the
interface goes down. Addresses persist across interface down/up
events. If the most common cause of hosts' interfaces going down and
coming back up was considered to be attachment to a different link,
then addresses would probably be deleted by default upon link down.

- 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.

- TCP connections survive the host's local interface down/up events.
They're treated as a possible period of transient packet loss (the
same as packet loss anywhere else in the network), rather than an
event that terminates the TCP connection.

- The SLAAC default preferred and valid lifetimes are very exceptional
and remarkably large compared to other typical default networking
timer values that are in the order of 1s, 10s or 100s of seconds. The
default Valid Lifetime is ~2.6 million seconds/30 days.

Considering that a single RA would reset a decrementing address's
Valid Lifetime back to ~2.6 million seconds, I think that suggests
that TCP can expect that an address it is using on a host can be
relied upon to exist for a minimum of 30 days, so a TCP connection
should be able to be relied upon for a minimum of 30 days. That's
exceptionally robust given that the unsolicited RA default maximum
interval is 600 seconds.

Regards,
Mark.

---

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

On 20/2/19 03:02, JORDI PALET MARTINEZ wrote:
> Of course, not acceptable. I'm not saying that is not a problem to be
> solved, just tried to make the data more precise. My reading of your
> text was like "dynamic is over static".

My text essentially was: "No matter what's your personal take on the
static vs dynamic debate, dynamic prefixes represent a significant part
of the deployed IPv6 Internet. Hence having such deployments fail is
unacceptable".

Much of what I've seen on this thread has been about who to blame: CPEs
for what they ship, ISPs because they employ dynamic prefixes, etc.

Reality is that there are engineering trade-offs for what they do.
There's a significant part of the IPv6 Internet that exhibit the problem
scenario we describe, and that we have contributed our bit for the
problem to exist.

I'd rather focus on improving the current state of affairs and making
the network more robust, rather than pretending the problem doesn't
exist or pretending that the folks that make our "words on paper" a
reality are just clueless people.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Feb 2019 07:38:05 +0100 (CET)

> then addresses would probably be deleted by default upon link down.

This is no longer true. If you install a Windows machine, ubuntu desktop 
(with networkmanager, which is the default), MacOS, Android, iOS, they ALL 
take the addresses away when there is a link-down.

What you're talking about is long gone.

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Feb 2019 18:18:28 +1100

> take the addresses away when there is a link-down.

So what I was expecting would happen in this scenario is that the
addresses wouldn't be removed, however when the link came back up,
they'd be verified e.g. via DHCPv4, and then if they're invalid would
be removed and the corresponding TCP connections/sockets using them
would be torn down.

You're right that on e.g. this Fedora 29 box with Network Manager, the
addresses are removed from the interface when unplugged from the
network.

However, a test IPv6 telnet connection to route-views.routeviews.org
wasn't torn down after the addresses were removed from the interface.
I sent some characters while the link was down over that telnet
connection, and they were shown as being in the Send-Q via 'ss'. When
I plugged the link back in the interface got addresses again, and I
then prompted TCP to send again by typing some more characters (TCP
would have eventually tried again, this just stops the wait). They
were sent and since they were invalid CLI commands on that device, got
an error message back.

So while the addresses were removed from the interface, the TCP
connection entirely survived that, and treated the link down/up event
as a period of packet loss.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Feb 2019 08:20:42 +0100

> this topic.) Thus, hosts need to be ready for renumbering at any time,

Thank you for the pointer to 6renum.

In addition, the topic of prefix stability was addressed in mobility 
contexts by RFC3963 "Network Mobility".  That protocol works, but has, 
in some contexts, some issues related to "Route Optimization" RFC4888.

Another side node is the prefix stability addressed with BGP updates in 
Boeing and NASA demonstrator.

> Better I think to focus on Fernando's specific issue.

I agree, it is a very good issue.

In addition to household networks, assigning a stable prefix with 
DHCPv6-PD to a cellular phone, or to a car, are important for their 
respective networks.  I know of a cellular operator that does have a 
trial giving DHCPv6-PD to mobile user and to household network.  Its use 
eliminates the use of Network Mobility, when the prefix stays stable.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Feb 2019 16:35:49 +0900

> as a period of packet loss.

That doesn't really make sense on a mobile platform. When you switch from
wifi to cell data, you probably don't want to keep that connection alive
until that specific wifi network comes back. Instead you want to give the
app an error as soon as possible so it can retry the failed connection on
the new network. On Android, TCP connections are closed the instant their
IP address goes away. I don't know what iOS does.

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2019 08:46:03 +0100

Top posting. Two points here. 

1) Flash renumbering breaks stuff. Especially for people running servers. Allowing people to host and own their own content in their own networks would do a lot more to protect people’s privacy rather than changing addresses. So let’s agree that the problem you want to solve is a misconfiguration/error case, not recommended operational practice. 

2) We should always strive to make mechanisms more robust. Your suggested point solution already have alternative broader solutions. E.g. MPMH host or added rules in SAS. It might be worth looking at the more general problem.

Ole

> On 20 Feb 2019, at 06:34, Fernando Gont <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Feb 2019 16:49:40 +0900

FWIW, I think the reason that the only way to renumber IPv6 networks is
(mostly) there is no way to explicitly communicate the user prefixes from
the CPE to the network. I think most deployments inject routes based on
DHCPv6 PD snooping, and the implementations of that generally only support
one injected route per DHCPv6 client.

On Wed, Feb 20, 2019 at 4:46 PM Ole Troan <[email-masked]> wrote:

> 1) Flash renumbering breaks stuff. Especially for people running servers.
> Allowing people to host and own their own content in their own networks
> would do a lot more to protect people’s privacy rather than changing
> addresses. So let’s agree that the problem you want to solve is a
> misconfiguration/error case, not recommended operational practice.
>
> 2) We should always strive to make mechanisms more robust. Your suggested
> point solution already have alternative broader solutions. E.g. MPMH host
> or added rules in SAS. It might be worth looking at the more general
> problem.
>
> Ole
>
>
> push, you'll need to reach out to the security and ops areas to get their
> >> There seems to be some people arguing that renumbering without an
> overlap is a supported case in IPv6. It is not.
> >>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 04:39:43 -0300

Mark,

[....]
> connection, regardless of how long that duration is.

Your are turning a kludge into a design principle. Yes, TCP uses
addresses as identifiers, because the Internet doesn't have a
name/identifier for hosts.

Then instead of creating such identifiers, folks tried to "move
addresses" -- well, if you can move it, it's not an address anymore!

> - TCP connections survive the host's local interface down/up events.

Not necessarily. This is implementation dependent.

In fact, if this was the case, and with the current lifetimes, with
Valid Lifetimes of one month, imagine what your network config would
look like after moving around a few coffee shops in a week -- unusable!

> exceptionally robust given that the unsolicited RA default maximum

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) and nothing (including the CPE) fails
(quite unlikely).

---

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

On 20/2/19 04:46, Ole Troan wrote:
> 1) Flash renumbering breaks stuff. Especially for people running
> servers. Allowing people to host and own their own content in their
> own networks would do a lot more to protect people’s privacy rather
> than changing addresses. So let’s agree that the problem you want to
> solve is a misconfiguration/error case, not recommended operational
> practice.

The problem that we want to fix is indeed the misconfiguration/error
case. -- that's what triggered this work.

That aside, the more general problem -- which is made evident in the
misconfiguration/error case -- is the inability of SLAAC to recover from
stale configuration information.

Jen and others mentioned other scenarios that might led to the same end
result. And if you solve the misconfiguration/error case, you also solve
them -- because it's all about stale configuration (no matter how you
got there).

> 2) We should always strive to make mechanisms more robust. Your
> suggested point solution already have alternative broader solutions.
> E.g. MPMH host or added rules in SAS. It might be worth looking at
> the more general problem.

They are complementary solutions rather than alternative ones.

In fact, you don't need new rules in SAS. Once you use appropriate
timers in SLAAC -- which are nowadays irrelevant and just a hassle --
then you don't need new rules in SLAAC: rule 3 will already take care of
that.

As noted in the thread and discussed in Appendix C.2. of the I-D, you
can't completely fix the problem by simply relying on SAS. Because that
will not take care of the stale addresses and routes.

Hosts do need to do garbage collection on their stale addresses.

---

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

> 2) We should always strive to make mechanisms more robust. Your suggested point solution already have alternative broader solutions. E.g. MPMH host or added rules in SAS. It might be worth looking…

It is mentioned in Appendix C.2 of our I-D, but anyway: if you tried to
solve this by adding a brand new rule to SAS that "prefers the most
recently advertised info", besides the other shortcommings that were
already mentioned, SAs are warranted to oscillate, leading to
troubleshooting pain. And there are multiple scenarios where this
"improvement" will fail, including e.g. stale ULAs being preferred over
fresh globals (unless you put the "freshness" rule as rule #0, thus
breaking the spirit of RFC6724).

Each of the areas that contribute to the problem need and should be
improved. SAS is probably the only one that doesn't need changes,
because as soon as you use appropriate timers, rule #3 of RFC6724 will
do the work.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Feb 2019 10:03:55 +0100 (CET)

On Wed, 20 Feb 2019, Lorenzo Colitti wrote:

> That doesn't really make sense on a mobile platform. When you switch 
> from wifi to cell data, you probably don't want to keep that connection 
> alive until that specific wifi network comes back. Instead you want to 
> give the app an error as soon as possible so it can retry the failed 
> connection on the new network. On Android, TCP connections are closed 
> the instant their IP address goes away. I don't know what iOS does.

I contacted linux-netdev about this, and I got no sympathy to close down 
the sessions if the addresses were gone. "Oh, the addresses might come 
back". Even when I said I'd like to be able to have this as a setting to 
close down the sessions, that I knew it won't come back I kept getting 
""how do you know?"

How do you close them in Android? Did you write your own userspace code to 
find sockets bound to addresses that were no longer available and close 
them down?

---

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

> would say - very very rare.

Sorry if I did not make it clear - what I'm trying to say is that the
proposed changes seem to affect not just residential home or SOHO
environment but all hosts in all environments.
So it would be nice to think about other scenarios and potential impact.

> they choose.

I think we all agree on this (well, unless what they choose does not
hurt users and IPv6 deployment ;-P)

>We ignored it for too long now. :)

Now all my personalities (one is an operator who has spent a lot of
time recently trying to deploy DHCPv6-PD and another one keeps sending
emails to IETF mailing lists) are equally confused ;)

> in Reykyavik in May and bring some additional operational feedback to

We've just requested the second slot so hopefully we can have that
discussion in Reykyavik...I hope it's not too late to ask RIPE NCC
for popcorn machines in the hotel lobby ;))

---

From: Sander Steffann <[email-masked]>
Date: Wed, 20 Feb 2019 10:24:10 +0100

> for popcorn machines in the hotel lobby ;))

Yes please :)

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Feb 2019 20:32:23 +1100

> >> static/stable addressing. I simply asked where that model is described.

<snip>

> 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>

> 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.

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.

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. 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.

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.

Regards,
Mark.

---

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: Mark Smith <[email-masked]>
Date: Wed, 20 Feb 2019 20:41:22 +1100

> So it would be nice to think about other scenarios and potential impact.

+1

I always think we should think about solutions that will work in a 2
or more router scenario, because that would usually guarantee they'd
then work in a single router scenario. The other way around not so
much, because people may not think about issues related to
synchronising state and other issues between the two or more routers,
because they aren't required to.

Redundancy both in routers/CPE and links (e.g. FTTH + 4G) is
constantly getting cheaper, commodity and possibly therefore more
common. (Redundancy has got so cheap that even our commonly used hosts
have redundant links i.e. multihomed smartphones.)

<snip>

Regards,
Mark.

---

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: Michael Richardson <[email-masked]>
Date: Wed, 20 Feb 2019 10:25:40 -0500

Lorenzo Colitti <lorenzo=[email-masked]> wrote:
    > (mostly) there is no way to explicitly communicate the user prefixes from the
    > CPE to the network. I think most deployments inject routes based on DHCPv6 PD
    > snooping, and the implementations of that generally only support one injected
    > route per DHCPv6 client.

on the specific comment:
  BMG (PPPoE) devices usually terminate the DHCPv6 at the BMG, and so the BMG
  sees the radius packets that went into forming the PD, so it's not DHCPv6 PD
  snooping, exactly.  There is nothing in PD or radius that prevents multiple
  prefixes from being delegated, it's just a software problem :-)
  For the cable-modem situation, the scenario is very different.

I was confused at first by your comment, so I read it a few times.
I think you are suggesting that if we could have multiple prefixes (the old
and the new), that the renumbering event would no longer be a flash
renumbering.  That the mode of operation that 7084 recommends essentially
results in flash renumbering.  There is no apparent way to introduce a new
prefix while the old prefix is still alive.

The lack of old/new prefix definitely seems like a bug and it looks like
something that 6man ought to fix with an update to 7084, ideally in a
standards track document.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Feb 2019 10:29:30 -0500

> take the addresses away when there is a link-down.

By link-down, do you mean cable pulled out, or "ifconfig eth0 down"?
Annoyingly, Linux flushes all IPv6 addresses on ifconfig-down, but leaves the
IPv4 there, and you have to "ifconfig eth0 inet 0.0.0.0" to get rid of it.

I actualy would like the LL addresses to remain and just become very lossy on
link down, as that would allow the network to flap while not loosing a
mgmt ssh connection in over fe80:...%eth0 address.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Feb 2019 10:35:17 -0500

> I contacted linux-netdev about this, and I got no sympathy to close down the
    > sessions if the addresses were gone. "Oh, the addresses might come
    > close down the sessions, that I knew it won't come back I kept getting ""how
    > do you know?"

Hmm. You know because you are writing the "DHCP" daemon :-)
This reminds me of the /dev/pty allocation problem, or the good-ole
/dev/tty00 background process.... some googling found:
        https://jdebp.eu/FGA/bernstein-on-ttys/cttys.html

There is a system call, which I can't remember, which kills all other access
to a tty... clearly we want to do exactly that when we realize that a device
has changed provisioning domains.

Well.. maybe each time we are in a new provisioning domain, we want to spawn
a "macvlan" device with the new randomized layer-2 address, and use that.
Just let the old one hang around until everything times out... or maybe, we
they say, "it could come back"

    > find sockets bound to addresses that were no longer available and close them
    > down?

No, I don't think that this happens.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Feb 2019 16:29:40 +0000

Ole Troan wrote on 20/02/2019 07:46:
> So let’s agree that the problem you want to solve is a
are you declaring this to be the consensus view of the problem statement?

Nick

---

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: 神明達哉 <[email-masked]>
Date: Wed, 20 Feb 2019 11:44:09 -0800

At Wed, 20 Feb 2019 02:03:52 -0300,

> override your preferred router with one with higher preference, etc.

I don't remember precisely how we decided to introduce this
restriction in RFC2462 (it first appeared in 2462, not 4862), but I'm
at least pretty sure everyone understood that "ND security boils down:
you trust the RAs, or you don't".  It should be just that it's not
necessarily always all-or-nothing (with which we would never have to
worry about neighbor cache exhaustion or bother to introduce RA guard,
for example) but about providing a safety net when its benefit is
deemed to outweigh the cost.  In the case of the "two hour rule", I
guess (again, I don't remember the precise discussion at that time)
the consensus was that the resulting address stability against
operational errors or minor mischief is worth adding the additional
complexity to the protocol; no one naively assumed that's a strong
security measure against determined attacks.

As usual in such a case, different people can have a different sense
of balance, so it's not surprising if someone disagrees with this
consensus.  So I don't think it's necessarily a "flaw" in the spec
simply because you have a different view on this particular tradeoff.
On the other hand, it's possible that we now might reach a different
conclusion if we had this discussion today: people may revise their
opinions, actual experiments and/or technology evolution may suggest
revising the original tradeoff considerations, etc.  If you think
that's the case, you can always start revising the spec with a "The
two hour rule in SLAAC is considered harmful" draft.

--
JINMEI, Tatuya

---

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: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2019 10:50:42 +1300

> prefix while the old prefix is still alive.

Whereas of course RFC 4192 specifically describes planned renumbering
(for enterprise network networks with actual humans in charge.)
However, it seems to me that RFC 7084 is aimed mainly at manager-free
scenarios. I do agree that a document on manager-free renumbering
might be appropriate, but I think it's more than a simple fix to 7084.

Mumble HNCP mumble. RFC 7788 doesn't really seem to tackle the issues
we've been discussing here.

    Brian

---

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: Bob Hinden <[email-masked]>
Date: Wed, 20 Feb 2019 14:37:49 -0800

Lee,

> On Feb 19, 2019, at 7:29 AM, Lee Howard <[email-masked]> wrote:
> 
> 
> You are saying he (maybe others) is either a liar, intentionally creating false arguments, or a fool, not understanding the network.
> 
> Your insinuation that fixed network operators must be doing something fundamentally wrong because mobile voice networks work differently is ignorant and insulting.

Expressing technical requirements is within scope for this (and other) 6man discussions.  I don’t see how you turned this into saying someone called others liars, making false statements, or being a fool, etc.  Given the number of posts on this topic, there are clearly many views.   

Please return to the technical discussion.

Bob

> Because of the smiley I don't know how to interpret this. Either you actually think regulation would work, and the question is whether you mean governmental or IETF, or you don't, in which case there's no argument that 6man should tell network operators they're doing it wrong.
> 
> Lee
> 
> 
> 
>> 
>> Ole

---

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: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Feb 2019 08:46:10 +0900

> find sockets bound to addresses that were no longer available and close

Not quite. I added a SOCK_DESTROY operation to the netlink SOCK_DIAG
interface that allows userspace to force-close TCP connections. As you can
imagine that was a bit controversial, but it was accepted after discussion
(partly because it turned out that BSD already had a way to do this). We
call this in various situations, most commonly when an IP address goes
away. Look at SockDiag.cpp or sock_diag_test.py.

---

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

On 20/2/19 06:32, Mark Smith wrote:
[....]
> 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.

> example, took this approach.

Based on the deployment level of Mobile IP, I'm not sure we want to
follow that road ;-)

> 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

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.

> 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.

---

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:19:41 -0300

Hi, Jinmei,

On 20/2/19 16:44, 神明達哉 wrote:
> Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 
> you trust the RAs, or you don't".  

I'm also pretty sure about that.

> It should be just that it's not

What I'm saying is that, security-wise, as long as there are multiple
vectors to perform the same sort of attack, an attacker need not exploit
one specific vector.

e.g., if I was up for performing a DoS in ND, I'd have so many different
options that I wouldn't care if you patched one specific vector.

> simply because you have a different view on this particular tradeoff.

I agree I could have employed different wording.

> two hour rule in SLAAC is considered harmful" draft.

Completely agree.

Thanks!

Best regards,

---

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.

---

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:
>

---

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: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Feb 2019 11:07:06 +0100

[...]
> Based on the deployment level of Mobile IP, I'm not sure we want to

But do not take an even worse road, even less implementations.

(Mobile IP implementations are available widely on Cisco and other 
platforms; Mobile IPv4, Mobile IPv6 and DS-MIP are distinct; numerous 
trials featured it; Mobile IP went even into Space on a shuttle)

The SLAAC problem with non-expiring prefixes and addresses that you talk 
about in your draft is valid, and solving it could be valuable in some 
context.

Alex

[...]

---

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: Tim Chown <[email-masked]>
Date: Thu, 21 Feb 2019 10:51:34 +0000

On 20 Feb 2019, at 19:44, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:

The two hour rule way predates RFC 6104/6105 and the "RA Guard" functionality common in at least enterprise switches today.  And it says "two hours unless the RA is authenticated", so the "impossible" quoted above isn't strictly true, but in practice, we also see how widespread the required SeND deployment to do that is...).

With RA Guard on the table, whether you'd want to relax the two hour rule would presumably depend on how important you feel it is to protect against misconfigurations of genuine RAs.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Thu, 21 Feb 2019 13:33:54 +0100

> 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.

Assuming that only the preferred lifetime is changed quickly in response
to receiving an RA, what problems do you expect with the oscillating 
source addresses?

As far as I know, there exist NATs for IPv4 that distribute traffic over
multiple public IPv4 addresses. That seems to work.

I don't know if there are IPv6 stacks that distribute traffic over multiple
addresses that all have preferred lifetime > 0, but as far as I know, that
is allowed.

---

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

Hello, Tim,

[....]
> 
> The two hour rule way predates RFC 6104/6105 and the "RA Guard"
> functionality common in at least enterprise switches today.  And it says
> "two hours unless the RA is authenticated", so the "impossible" quoted
> above isn't strictly true, but in practice, we also see how widespread
> the required SeND deployment to do that is...).  

:-)

> With RA Guard on the table, whether you'd want to relax the two hour
> rule would presumably depend on how important you feel it is to protect
> against misconfigurations of genuine RAs.

If we were enforcing the same sort of policy for all fields, this might
require some thinking. But as an attacker, I'm always going to use
whatever vectors I have available that "just works". Put another way: if
one of entries to a fortress is protected by a door made of steel, but
the others just have a curtain... what's the point?

Besides, since we want the default valid lifetime to be well under 2
hours, we really need to update this bit of RFC4862, too.

---

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:19:53 -0300

> to receiving an RA, what problems do you expect with the oscillating 

I don't expect *problems*. I do think that when problems arise,
undeterministic behaviour makes trouble-shooting way more painful.

> addresses that all have preferred lifetime > 0, but as far as I know, that

It is certainly allowed. However, troubleshooting becomes way more painful.

Depending on the timing of RAs, it could mean that a specific source
address next-hop is employed for a very short window of time. When such
next-hop fails, network problems become intermitent.

I'd expect that if load is to be shred among RAs, it happens in some
sort of deterministic fashion (i.e., it is quite clear and explicit that
default routers are selected in round-robin fashion, or that one
next-hop is employed only if another fails).

Another draw-back of this approach is that since "longest-match" becomes
the last rule (after freshness), then it is quite likely that you might
not end up using the best bath to the destination -- since you
prioritize freshness over longest match.

---

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

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: 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: 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: Jan Zorz - Go6 <[email-masked]>
Date: Sat, 23 Feb 2019 00:13:26 +0400

On 22/02/2019 17:44, Christian Huitema wrote:>> Most people feel the 
outcome is undesirable when it happens.  Some
> I think that's a good summary: a problem that does not occur very
> often, but is very annoying when it does.

Since we documented this behaviour in RIPE-690 BCOP document and 
operators reached the consensus that it's least painful if they 
currently make PDs as static/stable as possible - this might happen less 
than before. I keep receiving feedback that many operators actually read 
the document and decides to avoid dynamic PDs despite the fact that 
their original network design choice would be different and they suffer 
in silence, waiting for SLAAC to be fixed and/or CPE behaviour to be 
improved.

Some of them can push CPE vendors to make their CPE better, some of them 
can't, but about improving SLAAC - they can just wait for IETF to react 
and potentially OS vendors to fix TCP stack implementations after IETF 
is done with the work.

>> 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.

Many modern operating systems gets patched often ;)

> 
> 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.

Thank you.

Cheers, Jan

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Sat, 23 Feb 2019 00:36:53 +0400

> unless there's a good reason not to.

Unfortunately not all vendors understand SHOULD in this way. 
Implementing more options is expensive and lowers the profits, so it's 
quite easy to fall into "implement all the MUSTS, declare compliancy 
with RFCs and ship the product" trap.

Cheers, Jan

---

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:

---

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: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Feb 2019 13:25:48 +1300

> with RFCs and ship the product" trap.

Sure. I dealt with a lot of development managers during my years
at a 3-letter company, so this error in thinking is quite familiar
to me. But there is nothing the IETF can really do about that.

    Brian

---

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?

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?
>> 

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?
>> 
> 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

Agreed.

> 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: Jan Zorz - Go6 <[email-masked]>
Date: Sat, 23 Feb 2019 07:26:48 +0100

> to me. But there is nothing the IETF can really do about that.

Actually, there is.

If we feel that something must be implemented in end product, than we 
should not be polite about it and use a MUST :) That's the quickest way 
to get things back on track.

Cheers, Jan

---

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: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 05:30:04 -0300

> to me. But there is nothing the IETF can really do about that.

Making RFC8028 a MUST in the next rev of node reqs? ;-)

---

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:26:51 -0500

⁣Sent from BlueMail ​

---

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: Michael Richardson <[email-masked]>
Date: Sun, 24 Feb 2019 18:26:14 -0500

Brian E Carpenter <[email-masked]> wrote:
    mcr> results in flash renumbering.  There is no apparent way to introduce
    mcr> a new prefix while the old prefix is still alive.

    > might be appropriate, but I think it's more than a simple fix to 7084.

Let's talk about this.

I think that the problem is seperable into the ISP<->CPE protocol,
and the CPE<->network protocol.  I think that RFC4192 provides for
the second part very well.

The part that is missing is some kind of "push" notification from the ISP to
the CPE that new addresses are available.  That need not obsolete the
old addresses --- the lifetime contract can be maintained.
Probably such a thing could be simulated by adjustment of T1 and T2 timers
in DHCP-PD, forcing the CPE to come back to confirm the old address, and at
that point, adding the new prefix.  This may require new specification as
well as new code; those parts of DHCP are not in my brain cache right now.

    > we've been discussing here.

I guess that you are saying that section 6 of 7788 doesn't say enough here?
It seems that if the new prefix is available prior to the lifetime of the old
prefix expiring, that it can be done smoothly.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Feb 2019 06:45:18 +0100

> On 25 Feb 2019, at 00:26, Michael Richardson <[email-masked]> wrote:
> 

DHCP Reconfigure. 

Cheers,
Ole

---

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: Sander Steffann <[email-masked]>
Date: Mon, 25 Feb 2019 14:59:34 +0100

Hi,

+1

I often hear the argument that it isn't widely implemented, which seems sadly true. But then inventing something else (that then has to be implemented) seems extremely silly.

Cheers,
Sander

---

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: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Feb 2019 14:48:15 +0000

Per CM-SP-eRouter-I13-140729.pdf, at least for CableLabs, this seems to be required:

The eRouter sends a DHCPv6 Solicit message as described in section 17.1.1 of [RFC 3315]. The Solicit message
MUST include:
1. A Client Identifier option containing the DHCP Unique Identifier (DUID) for this eRouter (as specified by
[RFC 3315]), the DUID should be formatted as follows:
a. The eRouter MUST use a DUID that is one of DUID-LL, DUID-EN or DUID-LLT type and;
b. The eRouter MUST use a DUID that is persistent across administrative reset or reboot following a loss of
power per [RFC 7084] W-6.
2. An IA_NA option to obtain its IPv6 address.
3. An IA_PD option (as specified in [RFC 3633]) to obtain its delegated IPv6 prefix.
4. A Reconfigure Accept option to indicate the eRouter is willing to accept Reconfigure messages.
...

- Bernie

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Sander Steffann
Sent: Monday, February 25, 2019 9:00 AM
To: Ole Troan <[email-masked]>
Cc: Michael Richardson <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: graceful renumbering of CPE networks

Hi,

>> The part that is missing is some kind of "push" notification from the 
>> ISP to the CPE that new addresses are available.  That need not 
>> obsolete the old addresses --- the lifetime contract can be maintained.
> 
> DHCP Reconfigure.

+1

Cheers,
Sander

---

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: Philip Homburg <[email-masked]>
Date: Tue, 26 Feb 2019 11:33:02 +0100

> is 21 years old, is an update required?  

I think this should be updated.

A long time ago, the model was that you would get a prefix from your ISP
and that was the only global prefix on the local network.

So with short lifetimes, if the internet connection would go down for a 
relatively long period, there would be no global prefix anymore and hosts
would have to resort to link local to communicate (which obviously fails
if there are multiple subnets).

Some time in the past, the thinking changed and now there should be a ULA
prefix in addition to any global prefixes.

So I think that with a ULA, it makes more sense for a CPE to limit lifetimes
to some multiple of the RA interval.

---

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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2019 14:20:22 +0100 (CET)

On Sun, 24 Feb 2019, Michael Richardson wrote:

> ISP to the CPE that new addresses are available.  That need not obsolete 
> the old addresses --- the lifetime contract can be maintained. Probably 
> such a thing could be simulated by adjustment of T1 and T2 timers in 
> DHCP-PD, forcing the CPE to come back to confirm the old address, and at 
> that point, adding the new prefix.  This may require new specification 
> as well as new code; those parts of DHCP are not in my brain cache right 
> now.

This is an interesting idea.

In the context of 
https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ 
we've been looking for what could make the HGW refresh its view of the 
world towards the ISP. It would be beneficial if the ISP router also could 
signal to the HGW that "hey, I just restarted, please reconfirm your 
beliefs". This would by design be cross-protocol and this message needs to 
affect both DHCP and SLAAC for instance.

We also of course need to make it less likely that there is all of a 
sudden a request storm, so some kind of exponential backoff would be 
needed.

What do we already have that could be used for this? Some kind of option 
to stick into an RA for the first few minutes after up:ing a new 
interface? An uptime counter to stick into the RA, and if it goes 
backwards then re-confirm? What's the least change possible for all 
involved entities to achieve that?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2019 14:26:24 +0100 (CET)

>> old addresses --- the lifetime contract can be maintained.

In the most common deployment scenario there is:

HGW <-> ISP-ROUTER <-> something <-> DHCPv6-server

Normal message flow is

HGW->ISP-ROUTER->DHCPv6-server which then answers back with 
DHCPv6-SERVER->ISP-router->HGW

In both ways the ISP-ROUTER is a DHCPv6 relay which does snooping on the 
relayed packets and installs routes as per the IA_NA/PD information flying 
by.

What mechanism in this deployment scenario would initiate a DHCP 
Reconfigure when the ISP-ROUTER is re-booted? I know there is some kind of 
"ok, I've lost state, please fill me in" kind of question that the relay 
can ask the server, but should we then tack on that when this happens (and 
it should then happen by default at start-up) a dhcp reconfigure message 
should be sent to the client?

What if both DHCP server and relay has lost state, can it even tell the 
HGW to refresh?

---

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: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 Feb 2019 13:53:18 +0000

Bulk lease query can be used by ISP-Router.

- Bernie

> On Feb 26, 2019, at 8:27 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> HGW->ISP-ROUTER->DHCPv6-server which then answers back with DHCPv6-SERVER->ISP-router->HGW
> 
> In both ways the ISP-ROUTER is a DHCPv6 relay which does snooping on the relayed packets and installs routes as per the IA_NA/PD information flying by.
> 
> What mechanism in this deployment scenario would initiate a DHCP Reconfigure when the ISP-ROUTER is re-booted? I know there is some kind of "ok, I've lost state, please fill me in" kind of question that the relay can ask the server, but should we then tack on that when this happens (and it should then happen by default at start-up) a dhcp reconfigure message should be sent to the client?
> 
> What if both DHCP server and relay has lost state, can it even tell the HGW to refresh?
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2019 15:14:19 +0100 (CET)

> Bulk lease query can be used by ISP-Router.

Yes, and then what? How is DHCP reconfigure initiated towards the HGW?

---

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: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 Feb 2019 15:24:42 +0000

How does a Reconfigure play into the ISP-router recovering its state?

Reconfigure is between the client HGW and the DHCP server. The DHCP server can issue a Reconfigure to the HGW (obviously communication needs to be restored at the ISP-router - hence the bulk leasequery).

Note also that there are two ways for the DHCP server to deliver the Reconfigure to the client - one is to unicast to the client directly, the other is to relay it (this requires the server to retain the Relay-Reply (or Relay-Forw)). Our server supports both methods - the operator can specify when they initiate the Reconfigure.

- Bernie

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2019 16:53:00 +0100 (CET)

On Tue, 26 Feb 2019, Bernie Volz (volz) wrote:

> Reconfigure is between the client HGW and the DHCP server. The DHCP 
> server can issue a Reconfigure to the HGW (obviously communication needs 
> to be restored at the ISP-router - hence the bulk leasequery).
>
> Note also that there are two ways for the DHCP server to deliver the 
> Reconfigure to the client - one is to unicast to the client directly, 
> the other is to relay it (this requires the server to retain the 
> Relay-Reply (or Relay-Forw)). Our server supports both methods - the 
> operator can specify when they initiate the Reconfigure.

Does the bulk leasequery really put back all needed state in the relay? So 
there is nothing needed to have the HGW do anything?

For a different scenario, in the sense of "the customer was moved to a 
different BNG" so there is now no state on the new router for this 
customer (but the HGW doesn't know), how is DHCP reconfigure done?

---

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: Sander Steffann <[email-masked]>
Date: Tue, 26 Feb 2019 17:45:59 +0100

Hi Mikael,

> Does the bulk leasequery really put back all needed state in the relay? So there is nothing needed to have the HGW do anything?

Yep. The DHCPv6 server remembers the relay and everything it has sent through it (that has not expired) and the relay can ask for a full dump over TCP of that data. That includes all the delegated prefixes and the link-local address of the next hop (which is the DHCPv6-PD client).

> For a different scenario, in the sense of "the customer was moved to a different BNG" so there is now no state on the new router for this customer (but the HGW doesn't know), how is DHCP reconfigure done?

It depends on the technology. If the connection is PPPoE then the CPE has to set up a new PPP session, which will generate the required state. When doing this for plain ethernet then I usually configure both BNGs as DHCPv6 relays, which means that they both see the request, both forward it to the DHCPv6 server, which then replies to both, generating the required state in both. Yes, this means that the HGW gets two DHCPv6 replies to every request, but that doesn't hurt much. They just ignore the duplicate packet.

That way both BNGs get the state, and will refresh the state using lease query after a reboot. And when you have two BNGs for redundancy they have to be able to handle each other's load in case of failure anyway, so keeping all the state is a good test for that :)

Cheers,
Sander

---

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: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 Feb 2019 16:56:08 +0000

> Does the bulk leasequery really put back all needed state in the relay? So there is nothing needed to have the HGW do anything?

The idea is that this would restore the state.

> For a different scenario, in the sense of "the customer was moved to a different BNG" so there is now no state on the new router for this customer (but the HGW doesn't know), how is DHCP reconfigur…

Why would a Reconfigure be done here? This seems more like this would require the HGW to get a new lease (i.e., Solicit). I'm not sure how the move would be done without causing the link state to have changed to trigger some kind of action at the HGW to restart DHCP (perhaps with Confirm or Rebind).

- Bernie

-----Original Message-----
From: Mikael Abrahamsson <[email-masked]> 
Sent: Tuesday, February 26, 2019 10:53 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ole Troan <[email-masked]>; Michael Richardson <[email-masked]>; 6man WG <[email-masked]>
Subject: RE: graceful renumbering of CPE networks

On Tue, 26 Feb 2019, Bernie Volz (volz) wrote:

> server can issue a Reconfigure to the HGW (obviously communication 
> needs to be restored at the ISP-router - hence the bulk leasequery).
>

---

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: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2019 18:30:19 +0100 (CET)

On Tue, 26 Feb 2019, Bernie Volz (volz) wrote:

> Why would a Reconfigure be done here? This seems more like this would 
> require the HGW to get a new lease (i.e., Solicit). I'm not sure how the 
> move would be done without causing the link state to have changed to 
> trigger some kind of action at the HGW to restart DHCP (perhaps with 
> Confirm or Rebind).

There are plenty of deployment scenarios where all kinds of things can 
happen without the link layer going down and up again. Please read 
https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ for 
one.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2019 14:35:20 -0300

Hello, Jinmei,

> primary reason for tweaking the protocol.

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: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Feb 2019 08:35:48 +1300

Philip,

> prefix in addition to any global prefixes.

Really? Where do you think that is stated?

I happen to run my CPE with ULA enabled, but I'm not aware of any
recommendation to do so.

> to some multiple of the RA interval.

Why? I don't expect my ULA prefix to change ever. Or do you mean the lifetimes
for globally routeable prefixes?

   Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 26 Feb 2019 11:45:53 -0800

> I happen to run my CPE with ULA enabled, but I'm not aware of any

It's not published yet, but it's mentioned under "Benefits of Using ULAs in
this scenario" in:

https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02#section-4.2

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Feb 2019 09:10:01 +1100

> I happen to run my CPE with ULA enabled, but I'm not aware of any

RFC7084. Was also in its ancestor.

OpenWRT is enabling ULAs by default (although with infinite lifetimes which
is something that should be changed).

Back in 2010 Fritzboxes were doing ULAs too, although badly. They had all
zeros random parts, and were trying to swap them in and out with the PD GUA
addresses as the WAN link went up or down. (It seemed they didn't
understand the fundamental idea that IPv6 supports multiaddressing.)

---

From: Philip Homburg <[email-masked]>
Date: Wed, 27 Feb 2019 00:23:28 +0100

>Really? Where do you think that is stated?

As Mark said, RFC-7084.

>for globally routeable prefixes?

In the case of bridged VMs, prefixes can stick around for a long time.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Feb 2019 12:57:57 +1300

> RFC7084. Was also in its ancestor.

Not so. All it says is:

   ULA-1:  The IPv6 CE router SHOULD be capable of generating a ULA
           prefix [RFC4193].

Unless I've missed something, nowhere does it recommend that ULA
should be enabled by default, and even though I'm a strong advocate
of ULAs, it isn't obvious that they should be on by default as a
general recommendation.
 
> is something that should be changed).

And for homenets that is a reasonable default IMHO, and is advocated
by RFC7368. However, https://tools.ietf.org/html/rfc7788#section-6.5
doesn't make it mandatory.

> understand the fundamental idea that IPv6 supports multiaddressing.)

My 2013-vintage FritzBox does better than that.

   Brian>

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Feb 2019 11:28:23 +1100

>    ULA-1:  The IPv6 CE router SHOULD be capable of generating a ULA

That could be interpreted to mean if it is capable of generating a ULA then
it should generate and announce one. It's probably a bit of ambiguity in
what generate can mean - generate could mean generate without
using/announcing it, but what would be the point of doing so?

There is earlier text in that section such implies ULAs are to be used if
the device can  generate them - "will need".

   An IPv6 CE router is expected to support an IPv6 end-user network and
   IPv6 hosts that exhibit the following characteristics:

   1.  Link-local addresses may be insufficient for allowing IPv6
       applications to communicate with each other in the end-user
       network.  The IPv6 CE router will need to enable this
       communication by providing globally scoped unicast addresses or
       ULAs [RFC4193 <https://tools.ietf.org/html/rfc4193>], whether
or not WAN connectivity exists.

> doesn't make it mandatory.

The concern with infinite is that in theory they'll persist on a hosts
interface until the OS is rebooted. So a mobile laptop that is suspended
while moved around, and never rebooted could carry those addresses around
and possibly open sockets around for months.

Infinite LTs are implying the address is infinitely valid in any context.
It would be the most extreme case of the issue Fernando and Jan have raised.

I think the loopback address is the only address where infinite lifetimes
are valid. The Link-Local prefix has infinite lifetimes, however I think
there is a privacy case where link-local addresses shouldn't. (Which I'll
put in an email in the next day or so.)

> My 2013-vintage FritzBox does better than that.

Good. I worked for the ISP who introduced them to Australia, and was doing
work with a number of IPv6 CPE vendors, however Fritz just seemed to be a
blackhole regarding working with us to improve their IPv6 implementation at
the time.

Regards,
Mark.

---

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: Alexandre Petrescu <[email-masked]>
Date: Wed, 27 Feb 2019 11:12:52 +0100

Le 26/02/2019 à 23:10, Mark Smith a écrit :
> 
> 
> On Wed., 27 Feb. 2019, 06:36 Brian E Carpenter, 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Philip,
> 
> OpenWRT is enabling ULAs by default (although with infinite lifetimes 
> which is something that should be changed).

YEs I confirm openwrt is enabling ULAs by default.

In recent years I tested several IoT-class cellular router owrt devices 
and they all enable ULAs by default on their WiFi and Ethernet 
interfaces.  In some cases they also enable NAT IPv6.  These owrt dont 
enable 64share nor CLAT; these latter are typical on Android (a 
different OS distribution than owrt, both based on linux kernel) and on 
Apple iOS (OS distribution based on mach kernel?).

While these IoT-class routers are not perfect, their use of ULAs is not 
a culprit.  ULA is fine.

It's their reliance on 64share (an INFORMATIONAL RFC), IPv6 NAT 
(perpetuates the NAT problem) and rigid length 64bit IIDs that are culprits.

A more reasonable IoT-class cellular router would use variable length 
IIDs, and DHCPv6 Prefix Delegation (Stds Track).

> Back in 2010 Fritzboxes were doing ULAs too, although badly. They had 
> all zeros random parts, and were trying to swap them in and out with the 
> PD GUA addresses as the WAN link went up or down. (It seemed they didn't 

Yes I heard of several German cellular router devices enabling ULAs.

Alex

---

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Feb 2019 19:46:00 +0000

Hi,

On 26 Feb 2019, at 19:35, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

Philip,

On 26-Feb-19 23:33, Philip Homburg 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?

RFC 7084 says simply:

"ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193<https://tools.ietf.org/html/rfc4193>]."

So just capability.

RFC 7638 has a "soft" should:

"A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices."

And there's draft-ietf-v6ops-ula-usage-recommendations-05, which meanders somewhat, and appears to be a dead draft.

I read that as prefix lifetimes, not the prefix itself, though the ULA prefix should be persistent.  RFC 7084 says:

"ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix consistently across reboots."

Tim

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Feb 2019 15:15:04 -0500

Chairs,
in the context of discussion of https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
(which has received a ridiculous amount of ML traffic), I'd like to have some
discussion in 6man at IETF104 about how we can signal orderly renumbering of
CPE devices that use DHCPv6-PD to get their addresses.

Possible outcomes that I can see:
   1) 6man needs to take RFC7084 BCP and make some standards documents,
   2) dhc WG needs to write some BCP document
   3) we need to encourage RIPE, Broadband forum, or CableLabs (or all of
      them), to write new documents referring to existing technology.
   4) we need to write a problem statement because there combination of
      problem areas goes beyond PPPoE vs CMTS/FTTH/ethernet in terms
      of it's combinatorics.

But it's clear as 6man-slaac-renum has pointed out that every renumber and
some reboots look like flash renumbering to end-hosts even when they don't
need to be so abrupt.

    > There are plenty of deployment scenarios where all kinds of things can happen
    > without the link layer going down and up again. Please read

---

From: 神明達哉 <[email-masked]>
Date: Wed, 27 Feb 2019 16:24:10 -0800

At Wed, 27 Feb 2019 11:28:23 +1100,
Mark Smith <[email-masked]> wrote:

> > >>> Some time in the past, the thinking changed and now there should be
a
> > ULA

FWIW, "SHOULD be capable of doing X" is clearly different from "SHOULD
be doing X" to me: the former means it SHOULD be implemented; the
latter means it SHOULD be (implemented and) enabled.  I often see
phrases like this in IETF documents and I always interpret them this
way without seeing any ambiguity.

So I agree with Brian here.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Feb 2019 18:09:14 -0800

> On Feb 26, 2019, at 2:33 AM, Philip Homburg <[email-masked]> wrote:
> 

Which might make sense if you have exactly one ISP....

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 Feb 2019 14:07:36 +1100

Yes.

Network redundancy and multi-homing has become so cheap to have that
rather than it just being something our network might have, it is also
something that our end-hosts might have too.Our smartphones are
commonly multihomed when we have access to the Internet via both Wifi
and mobile networks.

---

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

> commonly multihomed when we have access to the Internet via both Wifi

But smartphones managed it using an RFC 7556 PVD -aware/-capable
architecture.  I suspect that's probably the way to go for general
hosts now to solve these and other problems.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Feb 2019 13:29:20 +0100

>Which might make sense if you have exactly one ISP....

I think the common case in home networks and probably also lots of small
business is to have one ISP.

In any case, my point was that if your internal network connectivity depends
on a prefix from an external party then you want relatively long
lifetimes.

If instead your internal network connectivity is based on ULA, then there is
no real need to worry about losing all external prefixes.

---

From: Timothy Winters <[email-masked]>
Date: Thu, 28 Feb 2019 07:49:05 -0500

On Wed, Feb 27, 2019 at 7:24 PM 神明達哉 <[email-masked]> wrote:

> > > >>> Some time in the past, the thinking changed and now there should
> be a
> > > ULA
> > > >> recommendation to do so..
> > > >>
> > > >
I agree with Tatuya and Brain on how the SHOULD is interpreted.  In this
case of the 7084 IPv6 Ready CE Router Logo
<https://www.ipv6ready.org/db/index.php/public/search/?l=&c=&ds=&de=&pc=&ap=&oem=&etc=E&fw=&vn=&do=1&o=4>will
allow ULA to be optional, and none of the current Logos have ever claimed
support for ULAs.   Taking a quick survey of about ten off-shelf Home
Gateways (purchased in the US) we found that none had ULAs enabled by
default.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 28 Feb 2019 12:57:15 +0000

So I agree with Brian here.
I agree with Tatuya and Brain on how the SHOULD is interpreted.  In this case of the 7084 IPv6 Ready CE Router Logo <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ipv6ready.org_db_index.php_public_search_-3Fl-3D-26c-3D-26ds-3D-26de-3D-26pc-3D-26ap-3D-26oem-3D-26etc-3DE-26fw-3D-26vn-3D-26do-3D1-26o-3D4&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=N95yCPLb_SZCOaNyLVGMhtzt_ePCy8G9yxx51PyWSEk&s=XqtrT2N55_1szs6ez9bolqEd5d2t2N0EWWUDxqA7lNs&e=> will allow ULA to be optional, and none of the current Logos have ever claimed support for ULAs.   Taking a quick survey of about ten off-shelf Home Gateways (purchased in the US) we found that none had ULAs enabled by default.

<bhs> This is also consistent with my intent. I’ve found over the years that different ISPs want different defaults in their procured CE routers. So in BBF we quickly abandoned combining requirements for what functionality needs to be supported with default configuration recommendations. If someone wanted to see about maybe having a BCP for default configuration for specific use cases in IETF, that might be reasonable. But it’s important to scope default configuration recommendations very tightly. - Barbara