Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

From: Philip Homburg <[email-masked]>
Date: Sun, 05 Apr 2020 21:11:20 +0200

Hi,

I have two comments on this draft:
1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC)

   It would be nice have a text like
   'The router MAY provide an option where the user can override the valid and
   preferred lifetimes.'

   Case in point, my ISP gives me a more or less fixed IPv6 prefix. However,
   for technical reasons customers have to run DHCPv6-PD. So this leave the
   user with no way to manually configre the lifetimes.

2) Based on the 6man discussion, I'm missing a section where overly long
   lifetime values in DHCPv6-PD are reduced by the router.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 5 Apr 2020 17:23:36 -0300

Hello, Philip,

>     user with no way to manually configre the lifetimes.

You mean the router simply copies the lifetimes from dhcpve-pd?

>     lifetime values in DHCPv6-PD are reduced by the router.

PUtting together the text I had suggested to Bernie, and some additional 
notes, how about this:

---- cut here ----
The Valid Lifetime and Preferred Lifetime of PIOs have direct impact on 
two different aspects:

* The amount of time hosts may end up employing stale network 
configuration information (see [draft-ietf-v6ops-slaac-renum]).

* The amount of time a Customer Edge router would need to persist trying 
to deprecate stale network configuration information (to handle cases 
where nodes miss Router Advertisements and thus still consider the stale 
information as valid).

As a result, a CPE Routers should consider overriding the default 
"Preferred Lifetime" and "Valid Lifetime" values from [RFC4861], and 
employ shorted values to mitigate the aforementioned effect. In such 
case, the selected values should always follow the requirement from 
Section 2.1 of this document, and the recommendations in RFC7772.

We note that a CPE Router need not directly reflect possibly long 
DHCPv-PD lease times in the corresponding Router Advertisements sent on 
the local network. Instead, shorter values may be used for the Router 
Advertisement messages which successively extend the prefix lifetimes on 
the local network, without ever spanning such lifetime past the 
DCHPv6-PD lease time.
--- cut here ----

That's one option, without numbers. If we wanted to suggest numbres, I 
guess there could be to options:

1) Something like: PL: Router Lifetime, V:= 1 day -- which seems to be a 
very conservative choice that everyone seems to support, or.,

2) Point to draft-gont-6man-slaac-renum

Thoughts?

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

---

From: Philip Homburg <[email-masked]>
Date: Mon, 06 Apr 2020 16:52:40 +0200

>You mean the router simply copies the lifetimes from dhcpve-pd?

Supposed that the ISP sets the lifetime of a prefix to one hour and I want 
the valid time to be a couple of hours. Then the current text says that
the router has to limit the valid lifetime to what remains of one hour.

I think there should be a way for operator (user of the CPE) to override this.

>very conservative choice that everyone seems to support, or.,

I think it is a good text and it should have numbers. The numbers here can
be tuned to a typical CPE situations.

>2) Point to draft-gont-6man-slaac-renum

That draft should apply to all hosts, so probably the trade-offs are
different. I think it is better to have the discussion here on what are the
right values for CPEs.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 12:33:38 -0300

> I think there should be a way for operator (user of the CPE) to override this.

I don't mind a CE Router to have knobs for folks to play with (in fact, 
that's normally useful).

That said, setting, the PIO lifetimes in a way that would span past the 
DHCPV6-PD would be incorrect.

> be tuned to a typical CPE situations.

So, double-checking: you agree to we incorporate the text that I 
proposed, and that we suggest the PL: Router Lifetime, and VL: 1 days?

> different. I think it is better to have the discussion here on what are the

Makes sense.

Thanks!

Cheers,

---

From: [email-masked]
Date: Mon, 6 Apr 2020 18:00:41 +0200

> I don't mind a CE Router to have knobs for folks to play with (in fact, that's normally useful).
> 
> That said, setting, the PIO lifetimes in a way that would span past the DHCPV6-PD would be incorrect.

Yes, that would violate a fundamental premise of prefix delegation.

Cheers,
Ole

---

From: [email-masked]
Date: Mon, 6 Apr 2020 18:02:41 +0200

> So, double-checking: you agree to we incorporate the text that I proposed, and that we suggest the PL: Router Lifetime, and VL: 1 days?

I would object to this document proposing new default lifetimes.
The RA should advertise the lifetimes towards an exiry date as described in 4861.
Let's not let this document feature creep. It's there to solve one problem and one problem only.

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Apr 2020 12:06:32 -0400

> the router has to limit the valid lifetime to what remains of one hour.

Why would you want the valid lifetime to be longer than the actual valid lifetime?

On Apr 6, 2020, at 10:25 AM, Bernie Volz (volz) <volz=[email-masked]> wrote:
> The question is how long this information has to be remembered and sent to the client. I don't think RFC8415 is that clear on this issue.

Isn’t the server supposed to remember the prefix it has assigned until its valid lifetime expires?

---

From: Philip Homburg <[email-masked]>
Date: Mon, 06 Apr 2020 23:17:13 +0200

>Yes, that would violate a fundamental premise of prefix delegation.

I disagree. In case of a static prefix it should be possible for the
user of the router to set long lifetimes.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 6 Apr 2020 14:32:55 -0700

> On Apr 6, 2020, at 9:00 AM, [email-masked] wrote:
> 

How far do you think we will get if we depend on the intelligence and diligent disciplined implementation of CPE firmware/software?

Yes, it’s wrong, but I guarantee you it probably does happen in the real world and certainly WILL happen in the real world that PIO lifetimes will be copied from IA_PDs without regard for the amount of time since the lease was issued.

It’s a stupid mistake, but I bet it becomes a common one as we strive for ever-cheaper devices.

Owen

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Apr 2020 23:46:56 +0200

Philip,

> On 6 Apr 2020, at 23:17, Philip Homburg <[email-masked]> wrote:
> 
> 
>> 

I am not sure that’s something that can be disagreed with. 
We specify standards to ensure interoperability. We don’t design products.

The intention of dhcp pd was that it was a replacement for a fax. And that the lifetimes should reflect the length of the contract the user had with a provider. 

Cheers 
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 18:47:32 -0300

On 6/4/20 18:32, Owen DeLong wrote:
[....]
> It’s a stupid mistake, but I bet it becomes a common one as we strive for ever-cheaper devices.

Agreed. In fact, I was kind of surprised when many argued that the 
DHCPv6/SLAAC interface wasn't an issue -- since it's not uncommon t¡for 
the two pieces of software.

IN any case, I think Ole was referring to the case where a *human* 
manually extends the PIO lifetime past the DHCPv6-PD lease.

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Apr 2020 08:06:06 +1000

> The intention of dhcp pd was that it was a replacement for a fax. And that the lifetimes should reflect the length of the contract the user had with a provider.

Agree. The PD address space isn't the end-users', it's on-loan from
their ISP, so their ISP is the party to choose how long it is on loan
for. CPE should be following and enforcing this loan term by
decrementing PD lifetimes in its LAN interface RAs.

Internal ULA address space provides the address stability that would
be being sought by a mechanism to override an ISP's PD prefix
lifetimes.

Regards,
Mark.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2020 22:11:16 +0000

And, if this is truly a fixed prefix, likely you could remove the need for DHCPv6 (discuss with service provided) and just manually configure it at the CPE end?

If the tool you are using doesn't give you what you need, use a different tool.

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Mark Smith
Sent: Monday, April 6, 2020 6:06 PM
To: Ole Troan <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

On Tue, 7 Apr 2020 at 07:50, Ole Troan <[email-masked]> wrote:
> >>> That said, setting, the PIO lifetimes in a way that would span 
> >>> past
> >> the DHCPV6-PD would be incorrect.
> >>

Agree. The PD address space isn't the end-users', it's on-loan from their ISP, so their ISP is the party to choose how long it is on loan for. CPE should be following and enforcing this loan term by decrementing PD lifetimes in its LAN interface RAs.

Internal ULA address space provides the address stability that would be being sought by a mechanism to override an ISP's PD prefix lifetimes.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Apr 2020 00:27:23 +0200

Bernie,

> And, if this is truly a fixed prefix, likely you could remove the need for DHCPv6 (discuss with service provided) and just manually configure it at the CPE end?

DHCP PD was designed for the “fixed” use case. I.e fixed as in lifetime equal contract. DHCP PD is a fax replacement. The concern was that few users would be able to type 48-56 bits correctly. 

If it wasn’t for that use case DHCPv6 might never have got off the  ground in the first place. ;-)

Cheers 
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 07 Apr 2020 10:01:40 +0200

> I am not sure thats something that can be disagreed with.  We
> specify standards to ensure interoperability. We dont design
> products.
> 
> The intention of dhcp pd was that it was a replacement for a fax.
> And that the lifetimes should reflect the length of the contract
> the user had with a provider.

Then the real world happened and ISPs use DHCPv6 PD to manage FIB entries in
their access routers.

I.e. they store customer prefixes in a radius server and have DHCPv6 PD
distribute the routes. If your CPE doesn't do DHCPv6 PD then no FIB so no joy.

We should not design specifications that prevent the user from overriding the
system in cases where it is harmless to do so.

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Apr 2020 18:26:59 +1000

> system in cases where it is harmless to do so.

Imagine a home user continuing to try to illegitimately use as a source
address what is now somebody else's PD prefix because they overrode the
ISP's lifetimes.

It's not harmless.

> https://www.ietf.org/mailman/listinfo/v6
> <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 07 Apr 2020 16:36:49 +0200

>address what is now somebody else's PD prefix because they overrode the

Any sensible ISP does ingress filtering.

Today people can already configure addresses statically. Worse,
people have been abusing other people's IPv4 addresses in various
ways.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 7 Apr 2020 14:25:53 -0700

> On Apr 6, 2020, at 14:17 , Philip Homburg <[email-masked]> wrote:
> 

By definition if it is spanning a DHCPv6-PD issued lifetime, it is NOT a static prefix.

What am I missing?

Owen

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Apr 2020 11:40:58 +0200

>By definition if it is spanning a DHCPv6-PD issued lifetime, it is NOT a =
>static prefix.
>
>What am I missing?

DHCPv6-PD is used as a mechanism to populate the FIB of the access router.

Just like you can have static IPv4 addresses and still hand them out using 
DHCPv4.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Apr 2020 17:01:22 -0700

> On Apr 8, 2020, at 02:40 , Philip Homburg <[email-masked]> wrote:
> 

Nope.

They’re fixed dynamic addresses at that point, not static addresses.

Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but it’s still being
issued to you dynamically and it won’t keep working if you don’t renew the lease.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Apr 2020 14:48:27 +0200

> Theyre fixed dynamic addresses at that point, not static addresses.

Call it fixed dynamic address. What does that even mean? It is dynamic
but never changing?

> Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but
> its still being issued to you dynamically and it wont keep working
> if you dont renew the lease.

That very much depends on the situation. In many cases, you can keep using 
a 'fixed dynamic' IPv4 address without running a DHCP client. In other
cases it may not work.

But the issue is not whether external communication works or not. When the
router is down, there is no external communication, whether the prefix is
still valid or not.

However, that does not mean that local connections should break.

The only thing I'm asking it to allow the operator to configure things
differently based on the local situation. Not that it should be the default
or happen automatically.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2020 09:13:42 -0400

> However, that does not mean that local connections should break.

I think there’s a sort of consensus that the best practice for dealing with this is that the CPE router should always be advertising a ULA along with whatever GUA it has.  If you don’t do this, then a flash renumbering event on the part of the ISP, which we have to allow for, will also break connections between devices on the local network.  E.g., if you are doing a backup to your NAS, that will suddenly fail and restart.

RFC 7084 doesn’t make this an explicit requirement—see section 4.3.  It does correctly document how ULAs should be handled, but does not require that this be done.

I’d be curious whether there’s still any debate about whether ULAs should be configured or not.  I have heard from some folks that link-local addresses are sufficient, and should be used for all link-local communication, and that certainly is another way of addressing this problem.  This relies, however, on the destination address being a link-local address, and of course doesn’t work if the CP network is subnetted.  That’s almost always the case nowadays, but e.g. if you have a stub network for IoT devices, or a guest network that’s isolated from the home network, that may not be adequate.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Apr 2020 15:37:45 +0200

> I think theres a sort of consensus that the best practice for
> dealing with this is that the CPE router should always be advertising
> a ULA along with whatever GUA it has.  If you dont do this, then
> a flash renumbering event on the part of the ISP, which we have to
> allow for, will also break connections between devices on the local
> network.  E.g., if you are doing a backup to your NAS, that will
> suddenly fail and restart.

Note, the scenario is where I have a fixed prefix. But for technical
reason I'm forced to run DHCPv6 PD. So, no flash renumbering expeced.

I'm not against using ULAs, but what do you put in DNS? Do you make separate
internal zones with ULAs?

In the case of a static prefix, just listing public addresses is way more
convenient.

---

From: [email-masked]
Date: Thu, 9 Apr 2020 16:07:03 +0200

> In the case of a static prefix, just listing public addresses is way more

Indeed. And for that reason there is no consensus that ULA should be recommended in home networks either.

From what I have seen trying to make multi-homing work, I'm not sure I would trust host stack behaviour with regards to source address selection having link-local, ULA and global either.
(and link-local addresses really only work with applications specifically supporting it).

And I'd expect the ULA might change whenever you change CPE too (if that's Ted's case), so even more complexity.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Apr 2020 17:00:13 +0200

> From what I have seen trying to make multi-homing work, I'm not
> sure I would trust host stack behaviour with regards to source
> address selection having link-local, ULA and global either.  

For ULA and global, the longest prefix match should get the right
one if the policy table is not updated to include a label for ULA.

No clue how many stacks would get that wrong.

> And I'd expect the ULA might change whenever you change CPE too
> (if that's Ted's case), so even more complexity.

If the new router picks a new ULA prefix then hosts will have two
ULA prefixes until the old one expires. As long as the valid lifetime of
the old one is high enough, long connections should be unaffected.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2020 12:00:37 -0400

>> internal zones with ULAs?

This is a solved problem.  You can (and should, for a CPE) use home.arpa. as an internal zone.

Additionally, if you are using multicast DNS internally, which is generally the case, you don’t need a zone at all—just use .local.

>> In the case of a static prefix, just listing public addresses is way more

This is a real edge case—the way you describe this, I am fairly sure you are talking about typing names into zone files.   O(nobody) is ever going to do this on a home network.   If the name shows up in the DNS, it’s because the CPE device has a way to make it show up in the DNS.  For that use case, ULAs work just fine.

> Indeed. And for that reason there is no consensus that ULA should be recommended in home networks either.

I don’t think this is actually the case.  I understand that there is not full consensus, but I think there is rough consensus: what I observe in terms of implementations is that everybody provides ULAs.  I understand that you are in the rough here, but I think you really are in the rough.

> (and link-local addresses really only work with applications specifically supporting it).

Any application that uses mDNS will automatically get the ULA for on-link queries, so that’s not a problem in practice: if the broadcast domain is flat, the link-local address can be used simply by asking for IN AAAA hostname.local.

> And I'd expect the ULA might change whenever you change CPE too (if that's Ted's case), so even more complexity.

Sure, but since the CPE isn’t going to advertise a long lifetime, that’s okay.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Apr 2020 18:36:24 +0200

Ted,

I take it you describe some future vision of how you would like home networks to work. That’s fine. Unfortunately O(nobody) are able to operate them like that now. 

Ole

> On 9 Apr 2020, at 18:01, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2020 13:22:00 -0400

> I take it you describe some future vision of how you would like home networks to work. That’s fine. Unfortunately O(nobody) are able to operate them like that now. 

No, with the exception of implementing RFC 6763 using DNS rather than mDNS, everything that I described is current practice.  If you have a Mac or an iPhone and a printer, they most likely communicate using IPv6 link-local addresses.

I don’t know if your router at home publishes a ULA, but my Eero mesh does, my OpenWRT routers do, and the Apple Airport Base Station I was debugging the other day does.  Anecdata, granted, but that’s a pretty broad spectrum.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Apr 2020 20:54:16 +0200

Ted,

Expose the internal services in the home to the outside. Home-assistant, ssh, xmpp server etc.
That’s painful enough with static addresses. But if you tell me that’s all plug and play then please share.
And yes, this is pretty much the only end user relevant value add of IPv6, so we better make sure it works. 

Cheers,
Ole

> On 9 Apr 2020, at 19:22, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2020 15:04:33 -0400

> And yes, this is pretty much the only end user relevant value add of IPv6, so we better make sure it works. 

This is a pretty rare use case.  However, if you want to advertise a home service for global reachability, of course you have to use a GUA.  I would hope that you don’t use a long TTL if your ISP doesn’t guarantee you a static address.  Personally, my solution to this is to have a local DNS server and change the zone file whenever my public IPv4 address or GUA prefix changes.  So in a sense this is a solved problem, but I agree that we don’t have a good automation solution for it, and I don’t believe I ever claimed otherwise.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Apr 2020 22:22:38 -0300

On 9/4/20 16:04, Ted Lemon wrote:
> On Apr 9, 2020, at 2:54 PM, Ole Troan <[email-masked] 
> <mailto:[email-masked]>> wrote:
> This is a pretty rare use case.  However, if you want to advertise a 
> home service for global reachability, of course you have to use a GUA. 
>   I would hope that you don’t use a long TTL if your ISP doesn’t 
> guarantee you a static address.  Personally, my solution to this is to 
> have a local DNS server and change the zone file whenever my public IPv4 
> address or GUA prefix changes.  

Indeed. And you use short TTLs, because, otherwise, if your address 
changes, you'll keep stale information in DNS caches for a long time. 
Similar idea of what we have been discussing here.

Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Thu, 9 Apr 2020 19:26:36 -0700

> On Apr 9, 2020, at 05:48 , Philip Homburg <[email-masked]> wrote:
> 

It is delegated via a dynamic mechanism, but it is not dynamically assigned.
It is fixed in its assignment, yet dynamic in its delegation.

Thus, on the receiving end, it is still a dynamic address as the serving end
may decide to change it at the end of any given lease period.

If you control both the client and the server, then sure, that may never occur,
but the point is that according to the specs and the protocols, it can.

> a 'fixed dynamic' IPv4 address without running a DHCP client. In other

You may get away with this, but it’s a time bomb. Eventually, someone is
likely to update the DHCP server and depending on whether they remember
(or know) the the host in that particular fixed address clause isn’t actually
doing DHCP, life could get interesting in a number of ways. Really bad
administrative practice as far as I’m concerned. If you want to have hosts
with static addresses, then put them in a section of the network that’s not
in the DHCP scope.

> router is down, there is no external communication, whether the prefix is

I never said that the issue was external communication. If your internet
connection goes down long enough to time out your DHCP lease, I’d
think that renumbering your LAN would be among the least of your
concerns.

> However, that does not mean that local connections should break.

Nor did I say that they should. In general, an ISP using DHCP to hand out
fixed prefixes should be choosing pretty long lease times (on the order
of weeks if not a month or more, ideally something approximating the
length of time for which you’ve paid).

In such a case, your local connections won’t break for many days after
you’ve lost your internet connection.

> differently based on the local situation. Not that it should be the default

Yeah, I’m not convinced that benefiting your corner case exceeds the
likely harm when $END_USER who doesn’t know what those timers
really mean starts playing games.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 9 Apr 2020 19:36:37 -0700

> On Apr 9, 2020, at 09:00 , Ted Lemon <[email-masked]> wrote:
> 

Actually, while I think that Philip is pushing an edge case, I agree with him about the lack of consensus for ULA in the home.

Personally, IMHO, ULA is one of those things we’d be better off without.

> Any application that uses mDNS will automatically get the ULA for on-link queries, so that’s not a problem in practice: if the broadcast domain is flat, the link-local address can be used simply by…

Which is it? We’ll get the ULA or the Link Local? Your own statement displays the obvious probably confusion that will result when one combines mDNS with GUA, ULA, and Link Local addresses.

This would seem to argue that the GUA will be used:

from the host raspberrypi-4.local on my network:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:63:cb:d3 brd ff:ff:ff:ff:ff:ff
    inet 192.159.10.225/24 brd 10.0.0.255 scope global dynamic noprefixroute eth0
       valid_lft 2533sec preferred_lft 2083sec
    inet6 fda6:abcd:ef01:9a32::5/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 2620:0:930:0:f05a:a7e6:4110:513/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591751sec preferred_lft 604551sec
    inet6 fe80::c575:864d:8b77:25bf/64 scope link 
       valid_lft forever preferred_lft forever

From an adjacent iMac on the same network:
(106) ~ % ping6 raspberrypi-4.local                        2020/04/09 19:32:48
PING6(56=40+8+8 bytes) 2620:0:930::200:5 --> 2620::930:0:f05a:a7e6:4110:513
16 bytes from 2620::930:0:f05a:a7e6:4110:513, icmp_seq=0 hlim=64 time=0.307 ms
16 bytes from 2620::930:0:f05a:a7e6:4110:513, icmp_seq=1 hlim=64 time=0.799 ms
^C
--- raspberrypi-4.local ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.307/0.553/0.799/0.246 ms

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 9 Apr 2020 19:38:33 -0700

> On Apr 9, 2020, at 10:22 , Ted Lemon <[email-masked]> wrote:
> 
> On Apr 9, 2020, at 12:36 PM, Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:

Nope… They’re all using GUA.

> I don’t know if your router at home publishes a ULA, but my Eero mesh does, my OpenWRT routers do, and the Apple Airport Base Station I was debugging the other day does.  Anecdata, granted, but tha…

Mine does not… I had to add the ULA address to the hosts in my previous message just to do that test. It’s since been removed.

Normally, I don’t want the additional headaches of ULA which offers zero benefit in my environment.

None of my Apple Airports ever issued ULAs.

Owen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Apr 2020 09:16:48 +0200

When working in RIPE690 (https://www.ripe.net/publications/docs/ripe-690), we found that "persistent/non-persistent addresses" is a good way to avoid confusions with dynamic mechanism vs dynamically assigned addresses. When I've presented this document to different audiences, they also agreed that it is much clearer.

So, I think it will be good to be consistent by keeping using that terminology, and help to avoid those confusions. In fact, it will be also good to include a non-normative reference to this document.
 
Regards,
Jordi
@jordipalet

El 10/4/20 4:27, "v6ops en nombre de Owen DeLong" <[email-masked] en nombre de [email-masked]> escribió:

    

    

    

    

    
    Owen

**********************************************
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: Gert Doering <[email-masked]>
Date: Fri, 10 Apr 2020 09:29:02 +0200

HI,

> Expose the internal services in the home to the outside. Home-assistant, ssh, xmpp server etc.

That's about O(nobody).

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: Ole Troan <[email-masked]>
Date: Fri, 10 Apr 2020 10:10:27 +0200

> On 10 Apr 2020, at 09:29, Gert Doering <[email-masked]> wrote:
> 
> HI,
> 

And the only value proposition IPv6 had to offer. 
With end users forced into ephemeral addressing the complexity of an end to end IPv6 Internet is on par with IPv4.

If that reasoning is correct slaac-renum is the last nail in the coffin. 

Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Apr 2020 10:23:01 +0200

Hi,

> And the only value proposition IPv6 had to offer. 

"You can configure DNS entries to point at hosts in your home"?

Really?

(I thought "have enough address space so that nobody is forced to hide
behind a NAT if they do not want to" was the selling argument)

> With end users forced into ephemeral addressing the complexity of an end to end IPv6 Internet is on par with IPv4.

"Services in the home" for O(99%) never had any reasonable chance to fly,
because normal end users just don't do that.

For the rest, the "WE MUST HAVE A FIREWALL IN CPEs!" discussion killed
the remaining intentions.  For O(99.9999%), figuring out - if they are
not finding a random cloud offering much more convenient anyway - how
to *understand* what they need to change in their CPE, and then find out
how to *do* it, is fairly orthogonal to what their desires are in life.

> If that reasoning is correct slaac-renum is the last nail in the coffin. 

Yeah, the IETF did a good job in ensuring IPv6 wasn't deployed in 
reasonable ways in reasonable time, but I'm not going to rant about that
today (it's in the v6ops archives already).

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2020 08:11:29 -0400

> If that reasoning is correct slaac-renum is the last nail in the coffin. 

That is hardly the only value proposition that favors IPv6.  And nobody is saying that that value proposition isn’t valid. We’re saying that it’s too hard right now, and so nobody is using it. We have successes with IPv6, but we haven’t completely specified the solution space.

For IPv6 to work the way you wish it to, which I also want, we still need more work. We need a way for home networks to automatically publish names in the DNS. We need a way for home networks to not publish names in the DNS that shouldn’t be.   We actually have an example of the former: the DNSSD Discovery Proxy, which is in AUTH48 at present, and for which I’ve done an implementation that runs on Linux and Mac (and probably would run on Windows with some tweaking).

The problem with the discovery proxy is that if you use it to publish names globally, it will publish everything that’s visible locally, and that’s not what we want.  Also, it relies on mDNS, which is not ideal, but does work.

So this is incremental progress toward the goal that you are describing.

As Jordi said, the goal that we’re talking about here is not to eliminate stable addresses. But stable addresses solve a specific problem, not every problem. When we /want/ stable addresses in a certain situation, we also need to deal with the case where we don’t get them.  E..g., if my ISP won’t let me have a stable address, one way to handle that is to use TTLs that are short enough that when the ISP forces an address change, the DNS is updated quickly and reachability is not lost, even if persistent connectivity is broken.

You can’t force universal deployment of stable end-to-end connectivity by refusing to handle the cases where you don’t get it. There are legitimate cases where it doesn’t happen; these need to be handled.

Stable connectivity is a layer 9 issue. By that I don’t mean that the solution is to lobby every ISP until they give up.  The problem is that right now, the set of use cases that stable connectivity addresses is small. There is no killer app, if you will forgive the overused metaphor. If there were significant use cases that created demand for stable addresses, then it would be a lot harder for ISPs to insist that you not have them. 

 Making it so that we don’t get the best approximation of stability we can manage when ISPs are insisting you can’t have it works against the development of that killer app, not for it.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 05:34:15 -0700

In this case, however, I feel there is a need to differentiate between persistent dynamically assigned addresses
vs. persistent statically assigned addresses.

Owen

> On Apr 10, 2020, at 00:16 , JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 05:35:28 -0700

> On Apr 10, 2020, at 00:29 , Gert Doering <[email-masked]> wrote:
> 
> HI,
> 

That’s true today. I don’t expect that to necessarily remain true in perpetuity. In fact, once we have a broader spectrum of IPv6 deployment and IPv6-enabled console gaming systems, I’ll bet that will lead the way on this issue.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 05:36:46 -0700

> On Apr 10, 2020, at 01:10 , Ole Troan <[email-masked]> wrote:
> 
> 
> 

How is it that you think SLAAC-RENUM makes this worse? I can see an argument that it won’t make things any better,
but I’m having trouble seeing how it adds any nails, let alone being “the last nail in the coffin”.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 05:44:51 -0700

> On Apr 10, 2020, at 01:23 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

The main advantage to not being stuck behind a NAT is the ability to directly address (and reach)
devices from the internet. DNS isn’t necessarily a requirement for this to happen (though it helps).

So indirectly, “Expose the internal services in the home to outside” whether or not it involves
DNS _IS_ the biggest (if not only) selling point. Not being behind NAT is a dependency for
that selling point.

> because normal end users just don't do that.

Today.

The future (if we ever enable it) can present a very different picture.

> how to *do* it, is fairly orthogonal to what their desires are in life.

True, but CPE can evolve with user preferences over time. Likely we can develop
rational ways to ask users if an application should be permitted to accept connections
from the outside world and have the firewall automatically implement that choice
through what amounts to little more than a dialog box.

Apple was able to make “sudo” graphical and user friendly, surely we can eventually
find a way to implement something similar for applications to ask for the user to grant
permission to the router to modify filters.

Owen

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Apr 2020 14:51:36 +0200

Hi,

On Fri, Apr 10, 2020 at 05:35:28AM -0700, Owen DeLong wrote:
> That???s true today. I don???t expect that to necessarily remain true in perpetuity. In fact, once we have a broader spectrum of IPv6 deployment and IPv6-enabled console gaming systems, I???ll bet that will lead the way on this issue.

You're going to put the IPv6 address of your gaming console into public
DNS?

No?

We might see end-to-end talk between the devices (and I hope so), but 
"put addresses into public DNS" is something for grey-bearded people like
you and me, not for "things you buy in the supermarket that just work".

Rendezvous services, registering, then talking directly.

If those wonderful IETF-recommended omnipresent CPE firewalls permit.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 06:00:45 -0700

> On Apr 10, 2020, at 05:51 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

You don’t need to… Your gaming console will register with a meet-me server.
People you choose to play with will then receive each other’s IPv6 address
from the server and the consoles will connect to each other.

As I said, DNS IS _NOT_ required for this to be useful.

> you and me, not for "things you buy in the supermarket that just work”.

Today, I completely agree with you. In the future, I’m less certain. In the future,
something like Dynamic DNS combined with authoritative servers that can
be easily configured in home gateways might well become a thing.

> Rendezvous services, registering, then talking directly.

Yes, this will almost certainly be the first wave. It still requires the ability to get
the firewall to move the fsck out of the way.

> If those wonderful IETF-recommended omnipresent CPE firewalls permit.

Obviously what is needed (and lacking so far) is a standardized mechanism by which
a device can pass along a dialog to the user which allows the user to authenticate and
grant permission to the router to allow the flows requested by the {device, application}.

I have no precise idea what that mechanism or process looks like, but I have enough
general ideas of ways it could work to say that it really wouldn’t be all that difficult to
implement if we can get the right people to pull their collective heads out of their
collective rumps.

Owen

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Apr 2020 15:02:41 +0200

Hi,

> grant permission to the router to allow the flows requested by the {device, application}.

Of course this will need to make it very clear if the intent of said
communication is benign or malicious.  Otherwise, users can not make a
educated choice.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 06:11:12 -0700

> On Apr 10, 2020, at 06:02 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

You want to ask the malware to identify itself as malware… Uh, good luck with that.

Users are allowed to make uninformed choices about what URLs they click on every day.

Obviously this is an extension of that paradigm.

OTOH, the user should be presented with some confidence in which application and/or device
is making the request (He’s viewing the request on the device and the OS could be required
to disclose the Application and whether or not it’s a validly signed package; if so, who the
manufacturer is, etc.). There could also be a requirement that the contact point for inbound
traffic is not allowed to be an ephemeral port. (This would require a mechanism for requesting/
registering service ports with the OS).

Further protection could be afforded by the OS denying listeners binding to that port if they
don’t match the application signature in question. (This would require a signed mechanism
for updating signatures during application updates).

However, it’s not like any of this requires new or novel technology. It just requires combining
existing solved problems in a novel way.

Owen

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Apr 2020 15:26:54 +0200

> On 10 Apr 2020, at 14:36, Owen DeLong <[email-masked]> wrote:
> 
> 
> 

 It’s logically the same argument Lorenzo uses against DHCPv6. 

If we modify the IPv6 protocols to accommodate ephemeral addressing, then there is no incentive for operators to offer anything else. 

That creates a set of second class citizen end-user networks. Any service needs to accommodate the smallest common denominator. Which means you need nat and firewall traversal, deal with addresses being pulled out from underneath you...

Are there other benefits to end users that IPv6 offers than end to end transparency? I can run a service by just taking the address on the host interface and stuff it in DNS. 

With ephemeral addressing that’s quite a bit harder. And there is generally no tools supporting this model deployed. 

Can anyone think of an argument for why a user on such a network would not be better off sticking to IPv4 and NAT?

Cheers 
Ole

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 06:39:56 -0700

> On Apr 10, 2020, at 06:26 , Ole Troan <[email-masked]> wrote:
> 
> 
> 

Uh, I don’t buy that. It strikes me as a false dichotomy. Operators can actually reduce operational cost and complexity by offering relatively stable prefixes.

> That creates a set of second class citizen end-user networks. Any service needs to accommodate the smallest common denominator. Which means you need nat and firewall traversal, deal with addresses being pulled out from underneath you…

If you take the first argument as a given (and I don’t) this is a reasonable conclusion on the effect. However, it completely falls apart if your first postulate turns out false.

> Are there other benefits to end users that IPv6 offers than end to end transparency? I can run a service by just taking the address on the host interface and stuff it in DNS. 

Meh… You can run a service without DNS as well.

> With ephemeral addressing that’s quite a bit harder. And there is generally no tools supporting this model deployed. 

It’s a little bit harder. Plenty of solutions exist for updating DNS dynamically to reflect address changes. These even existed for the public side of portmaps in IPv4, complete with GUI interfaces on routers sufficiently stupid that plenty of home users were able to make them work.

> Can anyone think of an argument for why a user on such a network would not be better off sticking to IPv4 and NAT?

Not sure. I’d have to give it some thought. Given the general direction of a multitude of eyeball ISPs, I’m not sure they’ll have much choice in the matter in a few years.

Likely they’ll either have to give up their IPv4 addresses when their ISP drops IPv4 from its service offering, or, they’ll have to start paying extra to keep IPv4 when it stops becoming a standard part of ISP services.

Those will probably be the most compelling reasons.

However, this still hinges on the assumption that ISPs will behave in the manner you describe. I remain unconvinced that will be the case.

Owen

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Apr 2020 18:02:31 +0200

Hi,

> That creates a set of second class citizen end-user networks. Any service needs to accommodate the smallest common denominator. Which means you need nat and firewall traversal, deal with addresses…

Welcome to the Internet of 2020.

Actually, applications that can deal with "oops, my hosts's address changed
behind my back, so what" are something we need to see - devices are mobile,
roam between LAN and wifi and LTE, addresses change all the time, and 
users expect things like audio/video streams to continue seamlessly.

In that scenario, insisting on "butbutbut my home network address must 
never change!" is somewhat irrelevant in the grand picture.

> Are there other benefits to end users that IPv6 offers than end to end transparency? I can run a service by just taking the address on the host interface and stuff it in DNS. 

CGN hurts.  So yes, not having N:1 being forced on you is a benefit of IPv6.

> Can anyone think of an argument for why a user on such a network would not be better off sticking to IPv4 and NAT?

These days, people observe that their VPNs work much less reliably behind
a N:1 IPv4 NAT than via IPv6...

Gert Doering
        -- NetMaster

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2020 20:29:56 +0100

> Uh, I don’t buy that. It strikes me as a false dichotomy. Operators can actually reduce operational cost and complexity by offering relatively stable prefixes.

Maybe, but some go out of their way to not provide them. Now I don't know about what they are offering with IPv6, but with a previous work hat on I had a first hand view of what a number of (mostly UK) ISPs did with IPv4.

Some ISPs will not under any circumstances allow a fixed IP

Some ISPs will only allow a fixed IP if you pay extra for a business connection

Some ISPs even charge extra for a fixed IP if you are already paying extra for a "business" connection

Some ISPs are happy to let you choose. Mine is one of them, and the only charge they make for a fixed IP is a one-off charge when you tick the box in the control panel.

The usual answer (already mentioned) for "why no fixed address" is simply that they want to make it hard for you to do anything they think is not "consumer" stuff. If you have a consumer grade connection, then you are only allowed to consume - not serve. If you want to do anything not "consumer" - such as hosting a server, or having a site-site VPN - then you have to pay more for a "business" connection. It seems that teh marketing departments of these ISPs haven't heard of dynamic DNS services !

So yes, it may be simpler and cheaper for an operator to offer stable prefixes - but if what I've seen with IPv4 is anything to go by, they'll be happy to pay extra to have something to upsell the user with. And sometimes the upsell if a quite significant additional cost.

The "but IPv6 address space is so huge, there's no scarcity you can charge for" is irrelevant. IPSs were doing the "pay extra for fixed address" thing back when IPv4 addresses had no scarcity value either.

Never underestimate the technical stupidity of the marketing and finance departments ! If the marketing department sees the value of scamming users for static prefixes, then it matters not what is in the RFCs.

Simon

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Apr 2020 21:30:14 +0200

> It is delegated via a dynamic mechanism, but it is not dynamically
> assigned.  It is fixed in its assignment, yet dynamic in its
> delegation.
> 
> Thus, on the receiving end, it is still a dynamic address as the
> serving end may decide to change it at the end of any given lease
> period.

If the assignment is fixed, then the serving end does not change it at the
end of any lease period. If it does change then that is an operational
error, because, as said before, the assignment is fixed.

This is similar the DNS, it is not as if the registry is free to change
a DNS delegation at the end of a TTL. This change can only happen for other
reasons, in particular at the request of a registrar.

> I never said that the issue was external communication. If your
> internet connection goes down long enough to time out your DHCP
> lease, Id think that renumbering your LAN would be among the least
> of your concerns.

No. an ISPs, short DHCP leases are preferred. The reason is that when people
swap out CPEs, sometimes the old lease is stuck to the old CPE and the new one
gets a lease only when the old one expires.

> Nor did I say that they should. In general, an ISP using DHCP to
> hand out fixed prefixes should be choosing pretty long lease times
> (on the order of weeks if not a month or more, ideally something
> approximating the length of time for which youve paid).

2 hours is not pretty long in my book. This is reality. Not some sort of ideal
case.

> In such a case, your local connections wont break for many days
> after youve lost your internet connection.

2 hours is not many days in my book.

> Yeah, Im not convinced that benefiting your corner case exceeds
> the likely harm when $END_USER who doesnt know what those timers

Of course a RFC should know better than an operator, even when that operator 
is called 'user'. That's the right attitude to get IPv6 adopted.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Apr 2020 20:38:24 +0100

Ole Troan wrote on 10/04/2020 14:26:
> If we modify the IPv6 protocols to accommodate ephemeral addressing,
> then there is no incentive for operators to offer anything else.

this argument is fact-free nonsense.

And yes, that particular argument of Lorenzo against DHCPv6 is also 
nonsense.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Apr 2020 21:38:24 +0200

> then there is no incentive for operators to offer anything else.

This is something the market will solve if we won't.

It is already years ago that AVM FRITZ!Box had a misfeature that it would
try to deprecate prefixes it didn't hand out itself.

I can imagine plenty of hacks that can 'solve' this problem while creating
lots of others. RAs at a high frequency were already mentioned.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 12:46:10 -0700

> On Apr 10, 2020, at 12:29 , Simon Hobson <[email-masked]> wrote:
> 

If they’re trying that hard, nothing prevents them from giving the end user a /128 with NAT66 and ULA in the home.

> Some ISPs will not under any circumstances allow a fixed IP

No sane ISP will provide a static IP to residential end users, especially on a CMTS or *PON system.

Now, fixed is a different matter, but quite often they won’t want to make that guarantee.

The only ISPs I know of that are deliberately rotating IPv6 addresses frequently whether their customers want it or not are some silly European ISPs that have this strange notion that it protects their customer’s privacy and that they know better about what their customer wants or needs, even if their customer is loudly proclaiming otherwise. Most of the ones I know about like this are in Germany which has a long history of misguided privacy rules, regulations, and ideas. The Netherlands are not far removed.

> Some ISPs will only allow a fixed IP if you pay extra for a business connection

I’ve seen more of this in IPv4 than in IPv6, but most of the ones that do in IPv6 secretly give you an IP address that is very unlikely to change unless they change the network topology above you in which case, yeah, that’s going to happen unless you pay extra to cover their overhead in dealing with it. This doesn’t seem unreasonable to me.

> Some ISPs even charge extra for a fixed IP if you are already paying extra for a "business” connection

Right… Again, especially on CMTS and *PON, see above.

> Some ISPs are happy to let you choose. Mine is one of them, and the only charge they make for a fixed IP is a one-off charge when you tick the box in the control panel.

That’s great, but it sounds like they’re still issuing a fixed dynamic prefix rather than allowing for a static configuration. They’re doing this for a variety of reasons of operational convenience. If you pay them monthly, then you should be getting DHCP IA_PD offers that have at least a 1 month valid time. If you’re not, you should be asking them why not. If you are, then you really shouldn’t be suffering a problem with your LAN when your ISP goes down. Surely they can restore service in less than 15 days? If not, is renumbering your LAN really your biggest problem? If so, I gotta say… “First world problems, dude."

> The usual answer (already mentioned) for "why no fixed address" is simply that they want to make it hard for you to do anything they think is not "consumer" stuff. If you have a consumer grade conn…

That answer is pretty silly. I’ve easily worked around it by getting my own addresses and ASN from an RIR and using GRE. My less-than-cooperative ISP is merely layer 2 transport. I realize this isn’t an option open to everyone, but it works well for me.

Besides, if they issue you a relatively stable prefix, it’s certainly not hard to do things which aren’t “consumer”, including hosting all kinds of services and site-to-site VPNs. Heck, it’s pretty basic to do a site-to-site VPN any place you have at least one fixed end-point these days and even if you don’t, there are reasonable workarounds. I know one guy who managed to spin up an ultra cheap container or VM or whatever when the two sites lost track of each other and they’d both send their current address to each other via a proxy server running on that instance, and then once the connection was re-established, both sides would sent it a virtual thumbs up and it would go back to sleep until one side or the other called for it again. Since it only ran for about 20 seconds when a renumbering event occurred (every few years), it’s compute bill was so minuscule that it took like 8 years to rack up enough charges to generate a bill.

> So yes, it may be simpler and cheaper for an operator to offer stable prefixes - but if what I've seen with IPv4 is anything to go by, they'll be happy to pay extra to have something to upsell the…

IPv6 != IPv4 and most operators seem to be somewhat clueful about that (at least the bigger ones).

> The "but IPv6 address space is so huge, there's no scarcity you can charge for" is irrelevant. IPSs were doing the "pay extra for fixed address" thing back when IPv4 addresses had no scarcity value…

Not nearly as widespread, however. Also, fixed addresses in IPv4 in a CMTS or *PON are actually hard. Stable addresses in IPv6 that change very rarely are easy. Fixed addresses are less easy. This has nothing to do with billing models, it’s operational nature of the beast.

> Never underestimate the technical stupidity of the marketing and finance departments ! If the marketing department sees the value of scamming users for static prefixes, then it matters not what is…

Oh, I don’t, but I also know that they’ll chase the dollars and if it costs them $15/subscriber/month in engineering time to cope with the problems created by playing musical prefixes to gain $10 per subscriber, it won’t last long.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 10 Apr 2020 13:02:52 -0700

> On Apr 10, 2020, at 12:30 , Philip Homburg <[email-masked]> wrote:
> 

Nope… It’s fixed for the term of the lease. Anything beyond that is a matter
of contracts outside the technical realm.

> reasons, in particular at the request of a registrar.

DNS doesn’t have VALID lifetimes, only Preferred ones. There’s no ability to
say “You should make sure this is still correct after 900 seconds, but if you
can’t get an answer, you can consider it still workable for the next 30 days”.

Nonetheless, a domain administrator is absolutely free to change host data
whenever they want. Ideally, in the event of a changing IPv6 address, the
order goes something like this:

	1.	Add new address to interface on host, test routing and services.
	2.	Add AAAA record for a different name to DNS, more testing.
	3.	Remove different name configuration from host and DNS, make
		sure new address answers to expected name in expected ways.
	4.	Add AAAA record for new address to DNS with very short TTL.
	5.	Shorten TTL on old AAAA record.
	6.	More testing, make sure both addresses are working.
	7.	Remove old AAAA record. More testing
	8.	Apply normal TTL to new AAAA record.

At any point where testing fails in a production-effecting way, there are
rational and quickly implementable rollbacks.

At the end of your contract with the registry, they are certainly free to change
the information if you don’t renew. They’re also free to change the information
whether you like it or not if they are presented a proper law enforcement
document.

Example: http://weleakinfo.com <http://weleakinfo.com/>

Like it or not, I bet there’s language in your contract that allows your ISP to
change your address in case of operational need or basically if it suits them.
Read the fine print.

This doesn’t necessarily mean that they’re likely to do so (probably not, since
it’s a pain for them and causes customer unhappiness), but unless their lawyers
are morons, it’s in the contract as a safety net for them.

> gets a lease only when the old one expires.

Short leases are an IPv4 term. Please, let’s talk about valid and preferred lifetimes
in IPv6 IA_PD delegations. The former should be relatively short, but the longer
should be at least as long as the contract. If you swap out CPE, whatever
authentication method is being used (RADIUS, whatever) should be able to
recognize that it’s OK to issue the same IA_PD to the new CPE since it’s
still your end site.

Now, the IA_NA is an entirely different matter and may well change (heck, I’d argue
even should change) for the new CPE, but you don’t really care about that
for the most part.  In fact, that is useful to you if you think about it.

Again, IPv6 != IPv4

I confess I fell into the convenience of using older terminology earlier which
may have contributed to this misperception.

> 2 hours is not pretty long in my book. This is reality. Not some sort of ideal

Nor mine. Again, as far as I’m concerned, the IA_PD valid lifetime should be
something approximating the contract length at least. Preferred lifetime is an
entirely different matter. But guess what, a host which has a valid prefix that
is no longer preferred and no preferred prefixes is perfectly free to use the
valid prefix until it gets a preferred one.

> 2 hours is not many days in my book.

Again, we weren’t talking about two hours. An ISP doing fixed IA_PDs with a
two hour valid lifetime has it’s head squarely planted in the wrong end of its
collective anatomy.

> is called 'user'. That's the right attitude to get IPv6 adopted.

Are you assuming that I’m not an operator? I’ve been an operator for a very long time
and seen a very wide variety of implementations. The bottom line is that your
corner case is just that… A rare situation that will benefit a very small number of
end users. OTOH, what is proposed here addresses real world problems which
are affecting large numbers of users today.

It’s not so much “RFC knows better than end user” as it’s “the good of the many”.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Apr 2020 16:56:08 -0300

> lots of others. RAs at a high frequency were already mentioned.

Couldn't agree more!

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Apr 2020 08:57:39 +1200

On 11-Apr-20 04:02, Gert Doering wrote:
...
> users expect things like audio/video streams to continue seamlessly.

This can't be said often enough. Apps that can't deal with unexpected
and unannounced address changes are simply broken. Yes, it may take a
little time for them to notice and correct the situation; the user may
notice a glitch.

What we do here can reduce the glitches, and that's a good thing. But
don't aim for perfection, because it's impossible.

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Fri, 10 Apr 2020 17:15:56 +0200

> However, this still hinges on the assumption that ISPs will behave in the manner you describe. I remain unconvinced that will be the case.

This

And refusing to help those whose ISP doesn't behave like you would like them to is making it even worse. This WG needs to grow up and realise that we don't live in a perfect world. We should work towards making it better for the users, not shunning those whose ISP doesn't confirm to our dreams.

The internet is a for-profit system these days, and despite how much I dislike it, we need to provide incentives for ISPs to do things the right way. Hurting the poor users who don't have any knowledge/choice/etc is the wrong way to do that. Same as with the Android DHCPv6 disaster: it's hurting the wrong people. We need to work on standards and tools to make it better, not making it worse for those who cannot help it.

Cheers,
Sander