Mailing List Archive

static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
On 26-Oct-19 04:19, Matthew Huff wrote:
> This is part of one of the many reasons corporate acceptance of IPv6 is so low. The IPv6 design appears to be oriented toward residential, ISP, and public wifi usages, with little care to corporate needs. Not only is static IPs desired, but in many cases required by regulation (Auditing, access, etc...).

That is *not* a design issue. It's an ISP business practice issue, and it's why the RIRs have for a long time been assigning /48s for enterprises that want them.

> Things like DHCPv6 not supporting DNS server announcements is a good example (it's available recently, but not across all platforms). Private address may be a great thing for residential / public wifi, etc... but must be disabled in many, if not all, corporate environments.

Absolutely. They are a recommended default for the consumer market but I would expect most corporate deployments to disable them.

> Also, we have found that many software vendors certify their products for IPv6, but as soon as the PR release is done, their devs no longer test with IPv6 and their tech support almost always recommend disabling it the first time you open a ticket.

Again, it's a business issue over which paying customers have much more influence that anyone else, but only if they make it a commercial issue.

Progress will only come as more and more people stop putting IPv6 in the "too hard" basket. I really do understand that for people running actual services this is not a trivial thing, but it's a real chicken/egg situation, unfortunately. But the signs are good at last.

Regards
Brian Carpenter

>
> -----Original Message-----
> From: ipv6-ops-bounces+mhuff=ox.com@lists.cluenet.de <ipv6-ops-bounces+mhuff=ox.com@lists.cluenet.de> On Behalf Of Nick Hilliard
> Sent: Friday, October 25, 2019 11:10 AM
> To: Michael Sturtz <Michael.Sturtz@PACCAR.com>
> Cc: ipv6-ops@lists.cluenet.de; Gert Doering <gert@space.net>; Fernando Gont <fernando@gont.com.ar>
> Subject: Re: ipv6-ops Digest, Vol 159, Issue 1
>
> Michael Sturtz wrote on 25/10/2019 16:03:
>> This sort of operational nonsense will limit the wider acceptance of
>> IPv6! I am responsible research and for the documentation and
>> implementation of IPv6 for a Fortune 200 company. We have locations
>> worldwide. The allocation of unstable end network addresses
>> complicates the deployment and support of IPv6.
> most service providers view this as a commercial issue rather than a protocol issue. This is just an observation, btw.
>
> Nick
>
RE: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
The problem with non-routable private ULA addressing is most vendor equipment doesn't support having a SLAAC or DHCP6 dynamic routable address and a static ULA address.

For simple home networks I suppose we could have a RFC that proposes the FE80 address space be used as the "static" address space for SOHO server addressing and locating such as local DNS or single server environments or the end user equipment could just assume that it would be "static" given the common use of EUI-64 for the /64 portion (Windows excepted).

Right now, with the way it actually works in the field it is very disruptive every time the /64 is renumbered by the ISP In my experience this happens way too often. An end user should not have to go around and reboot devices, hunt around for the new printer IP and so on just because the ISP caused a renumber of their automatically assigned /64. With SOHO networks which are the vast majority of end user networks we can't make it painful to use IPv6. Even novice users can navigate the web UI of a home router and assign a static IP address to their network printer / scanner / copier etc. and it is very common to do this with IPv4. The random ISP renumbering completely breaks that whole use case. Given the very long IPv6 addresses, DNS (name resolution) becomes very important for most end users. Currently, this works fine on IPv4 because of NAT, PAT & RFC1918. We don't have an operational answer for this on IPv6 at all. For sites such as this I routinely get trouble tickets of random degraded connectivity that can be traced back to an ISP renumber event and one or more pieces of equipment didn't handle the renumber and could not connect to something else on the network or could not connect to something on the IPv6 internet.



-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Sent: Friday, October 25, 2019 4:02 PM
To: Matthew Huff <mhuff@ox.com>; Nick Hilliard <nick@foobar.org>; Michael Sturtz <Michael.Sturtz@PACCAR.com>
Cc: ipv6-ops@lists.cluenet.de; Fernando Gont <fernando@gont.com.ar>; Gert Doering <gert@space.net>
Subject: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

On 26-Oct-19 04:19, Matthew Huff wrote:
> This is part of one of the many reasons corporate acceptance of IPv6 is so low. The IPv6 design appears to be oriented toward residential, ISP, and public wifi usages, with little care to corporate needs. Not only is static IPs desired, but in many cases required by regulation (Auditing, access, etc...).

That is *not* a design issue. It's an ISP business practice issue, and it's why the RIRs have for a long time been assigning /48s for enterprises that want them.

> Things like DHCPv6 not supporting DNS server announcements is a good example (it's available recently, but not across all platforms). Private address may be a great thing for residential / public wifi, etc... but must be disabled in many, if not all, corporate environments.

Absolutely. They are a recommended default for the consumer market but I would expect most corporate deployments to disable them.

> Also, we have found that many software vendors certify their products for IPv6, but as soon as the PR release is done, their devs no longer test with IPv6 and their tech support almost always recommend disabling it the first time you open a ticket.

Again, it's a business issue over which paying customers have much more influence that anyone else, but only if they make it a commercial issue.

Progress will only come as more and more people stop putting IPv6 in the "too hard" basket. I really do understand that for people running actual services this is not a trivial thing, but it's a real chicken/egg situation, unfortunately. But the signs are good at last.

Regards
Brian Carpenter

>
> -----Original Message-----
> From: ipv6-ops-bounces+mhuff=ox.com@lists.cluenet.de
> <ipv6-ops-bounces+mhuff=ox.com@lists.cluenet.de> On Behalf Of Nick
> Hilliard
> Sent: Friday, October 25, 2019 11:10 AM
> To: Michael Sturtz <Michael.Sturtz@PACCAR.com>
> Cc: ipv6-ops@lists.cluenet.de; Gert Doering <gert@space.net>; Fernando
> Gont <fernando@gont.com.ar>
> Subject: Re: ipv6-ops Digest, Vol 159, Issue 1
>
> Michael Sturtz wrote on 25/10/2019 16:03:
>> This sort of operational nonsense will limit the wider acceptance of
>> IPv6! I am responsible research and for the documentation and
>> implementation of IPv6 for a Fortune 200 company. We have locations
>> worldwide. The allocation of unstable end network addresses
>> complicates the deployment and support of IPv6.
> most service providers view this as a commercial issue rather than a protocol issue. This is just an observation, btw.
>
> Nick
>
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
On 25/10/19 20:02, Brian E Carpenter wrote:
[....]
> Progress will only come as more and more people stop putting IPv6 in the "too hard" basket. I really do understand that for people running actual services this is not a trivial thing, but it's a real chicken/egg situation, unfortunately. But the signs are good at last.

We don't seem to be helping ourselves a lot.

FWIW, the slaac-renum I-D resulted from my conversation with the biggest
ISP in one country from the middle east, which was facing this problem.
They can't do stable addresses, and they are facing this problem.

Not sure how many more 100's of messages are needed before we get to do
something about it...


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Hi Michael,

On 26-Oct-19 12:33, Michael Sturtz wrote:
> The problem with non-routable private ULA addressing is most vendor equipment doesn't support having a SLAAC or DHCP6 dynamic routable address and a static ULA address.

Yes. But that is the vendors' fault for not doing what the RFCs recommend. I don't really see how another RFC can fix that.

>
> For simple home networks I suppose we could have a RFC that proposes the FE80 address space be used as the "static" address space for SOHO server addressing and locating such as local DNS or single server environments

By "simple" you mean with no interior routers, I guess. Yes, that's what I have; no RFC needed, just a well designed CE. Here's how it looks from Windows (and pretty much the same from Linux), just some magic numbers obscured:

Ethernet adapter Ethernet 4:

Connection-specific DNS Suffix . : fritz.box
Description . . . . . . . . . . . : ASIX AX88772B USB2.0 to Fast Ethernet Adapter #2
Physical Address. . . . . . . . . : xxxx
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2406:e002:xxxx:9301:80b2:5c79:2266:e431(Preferred)
IPv6 Address. . . . . . . . . . . : fd63:45eb:dc14:0:80b2:5c79:2266:e431(Preferred)
Temporary IPv6 Address. . . . . . : 2406:e002:xxxx:9301:243c:2e79:2618:e284(Preferred)
Temporary IPv6 Address. . . . . . : fd63:45eb:dc14:0:243c:2e79:2618:e284(Preferred)
Link-local IPv6 Address . . . . . : fe80::80b2:5c79:2266:e431%7(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.178.30(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Tuesday, 22 October, 2019 15:07:41
Lease Expires . . . . . . . . . . : Tuesday, 5 November, 2019 13:43:40
Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%7
192.168.178.1
DHCP Server . . . . . . . . . . . : 192.168.178.1
DHCPv6 IAID . . . . . . . . . . . : xxxx
DHCPv6 Client DUID. . . . . . . . : xxxx
DNS Servers . . . . . . . . . . . : fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
192.168.178.1

> or the end user equipment could just assume that it would be "static" given the common use of EUI-64 for the /64 portion (Windows excepted).

EUI-64 is legacy at this point. You get stable addresses using a locally generated stable ID, 80b2:5c79:2266:e431 in the above case. Again - the RFCs already have all this; tell your vendors what you want, repeatedly and loudly, is all I can suggest.

> Right now, with the way it actually works in the field it is very disruptive every time the /64 is renumbered by the ISP In my experience this happens way too often.

Yes, we all agree about that. That's exactly why Fernando has written his draft. (Of course the ISP should be giving you a /48 or /56, but that's another existing RFC.)

> An end user should not have to go around and reboot devices, hunt around for the new printer IP and so on just because the ISP caused a renumber of their automatically assigned /64. With SOHO networks which are the vast majority of end user networks we can't make it painful to use IPv6. Even novice users can navigate the web UI of a home router and assign a static IP address to their network printer / scanner / copier etc. and it is very common to do this with IPv4. The random ISP renumbering completely breaks that whole use case. Given the very long IPv6 addresses, DNS (name resolution) becomes very important for most end users. Currently, this works fine on IPv4 because of NAT, PAT & RFC1918. We don't have an operational answer for this on IPv6 at all. For sites such as this I routinely get trouble tickets of random degraded connectivity that can be traced back to an ISP renumber event and one or more pieces of equipment didn't handle the renumber and could not connect to something else on the network or could not connect to something on the IPv6 internet.

Again, exactly why Fernando has written his draft. I notice that my Canon printer has fe80::2bb:c1ff:fe99:cd6 as well as 192.168.178.23. That's OK for a network with no interior routers. However, it looks as if the Canon utilities use IPv4. But in general IPv6 works well with this set up, even when my ISP has a glitch and I get flash-renumbered, as happened earlier this week.

Regards
Brian

>
>
>
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Sent: Friday, October 25, 2019 4:02 PM
> To: Matthew Huff <mhuff@ox.com>; Nick Hilliard <nick@foobar.org>; Michael Sturtz <Michael.Sturtz@PACCAR.com>
> Cc: ipv6-ops@lists.cluenet.de; Fernando Gont <fernando@gont.com.ar>; Gert Doering <gert@space.net>
> Subject: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
>
> On 26-Oct-19 04:19, Matthew Huff wrote:
>> This is part of one of the many reasons corporate acceptance of IPv6 is so low. The IPv6 design appears to be oriented toward residential, ISP, and public wifi usages, with little care to corporate needs. Not only is static IPs desired, but in many cases required by regulation (Auditing, access, etc...).
>
> That is *not* a design issue. It's an ISP business practice issue, and it's why the RIRs have for a long time been assigning /48s for enterprises that want them.
>
>> Things like DHCPv6 not supporting DNS server announcements is a good example (it's available recently, but not across all platforms). Private address may be a great thing for residential / public wifi, etc... but must be disabled in many, if not all, corporate environments.
>
> Absolutely. They are a recommended default for the consumer market but I would expect most corporate deployments to disable them.
>
>> Also, we have found that many software vendors certify their products for IPv6, but as soon as the PR release is done, their devs no longer test with IPv6 and their tech support almost always recommend disabling it the first time you open a ticket.
>
> Again, it's a business issue over which paying customers have much more influence that anyone else, but only if they make it a commercial issue.
>
> Progress will only come as more and more people stop putting IPv6 in the "too hard" basket. I really do understand that for people running actual services this is not a trivial thing, but it's a real chicken/egg situation, unfortunately. But the signs are good at last.
>
> Regards
> Brian Carpenter
>
>>
>> -----Original Message-----
>> From: ipv6-ops-bounces+mhuff=ox.com@lists.cluenet.de
>> <ipv6-ops-bounces+mhuff=ox.com@lists.cluenet.de> On Behalf Of Nick
>> Hilliard
>> Sent: Friday, October 25, 2019 11:10 AM
>> To: Michael Sturtz <Michael.Sturtz@PACCAR.com>
>> Cc: ipv6-ops@lists.cluenet.de; Gert Doering <gert@space.net>; Fernando
>> Gont <fernando@gont.com.ar>
>> Subject: Re: ipv6-ops Digest, Vol 159, Issue 1
>>
>> Michael Sturtz wrote on 25/10/2019 16:03:
>>> This sort of operational nonsense will limit the wider acceptance of
>>> IPv6! I am responsible research and for the documentation and
>>> implementation of IPv6 for a Fortune 200 company. We have locations
>>> worldwide. The allocation of unstable end network addresses
>>> complicates the deployment and support of IPv6.
>> most service providers view this as a commercial issue rather than a protocol issue. This is just an observation, btw.
>>
>> Nick
>>
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Brian E Carpenter wrote on 26/10/2019 00:02:
> Progress will only come as more and more people stop putting IPv6 in
> the "too hard" basket.
maybe it is though? Maybe we underestimate the level of overall
complexity because when we look at any individual component, we can
always explain it away because it's only more complicated by a smidgen.

So for example, we mandate /64 for CPE/residential access and tell
people that assigning lots of /64s is good because it gives people
flexibility, although we don't suggest how to push them further down
into the network or provide an easy way to abstract away all the
complexities of running multiple networks.

We say ULA is fine for local stuff, but no NAT please (this is ipv6
after all), and then we write a 16 page document to tell people how to
select a suitable prefix, and then say it's really not that complicated
because the actual algorithm is only a 6-point sample idea and people
can do their own thing anyway.

We tell vendors that they must implement SLAAC and they don't need DHCP
but by the same token tell them that if they want anything more than
getting a host up and running, SLAAC won't do it, so they look at DHCP
(e.g. DOCSIS, residential DSL, etc) and force the vendors to use both
because we block the 2-3 constructs which would allow DHCP to operate as
a standalone protocol and do the whole lot in a significantly simpler way.

For years we never stepped in when people claimed that ipv6 was better
than ipv4 because it was designed to be easy to renumber, and now we're
here wondering why it's 2019 and there's no way to initiate a
renumbering process for SLAAC, and we frown because tech support desks
recommend disabling ipv6 because it's easier than fixing the underlying
problem because there is no underlying fix because SLAAC can't handle
the situation where the CPE renumbers but the end host doesn't.

This is just some bits of residential / cpe access. The same story is
reflected across other ipv6 deployment scenarios.

All of these things are individually reasonable and justifiable, and we
all buy into the explanations because we're good at convincing ourselves
about the things we already want to believe.

But we've crippled ourselves with complexity and we don't want to
acknowledge it.

Nick
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Fernando Gont <fernando@gont.com.ar> writes:

> They can't do stable addresses, and they are facing this problem.

This is a constructed problem. The solution is to remove the
construction.

I realize that the "can't do stable addresses" might be enforced by
non-technical entities, but this would most likely not happen if it was
a violation of a standards track RFC.

I'm sure you can fix that :-)


Bjørn
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Bjørn Mork wrote on 26/10/2019 15:06:
> I realize that the "can't do stable addresses" might be enforced by
> non-technical entities, but this would most likely not happen if it was
> a violation of a standards track RFC.

Surely you're joking?

Nick
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
On 26/10/19 11:06, Bjørn Mork wrote:
> Fernando Gont <fernando@gont.com.ar> writes:
>
>> They can't do stable addresses, and they are facing this problem.
>
> This is a constructed problem. The solution is to remove the
> construction.
>
> I realize that the "can't do stable addresses" might be enforced by
> non-technical entities, but this would most likely not happen if it was
> a violation of a standards track RFC.
>
> I'm sure you can fix that :-)

I'm sure the EFF would post a nice article about it.

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Hi,

On Fri, Oct 25, 2019 at 11:33:29PM +0000, Michael Sturtz wrote:
> The problem with non-routable private ULA addressing is most vendor equipment doesn't support having a SLAAC or DHCP6 dynamic routable address and a static ULA address.

You have claimed that before, but I find this hard to believe. In my
experience with various host implementations, having multiple addresses
(multiple SLAAC prefixes or static + SLAAC) works just as one would expect.

Maybe not OpenSolaris, but anything sane out there.

So, which systems exist that cannot handle static + SLAAC?

> For simple home networks I suppose we could have a RFC that proposes the FE80 address space be used as the "static" address space for SOHO server addressing and locating such as local DNS or single server environments or the end user equipment could just assume that it would be "static" given the common use of EUI-64 for the /64 portion (Windows excepted).

fe80 is not ULA, and using fe80 for mDNS is long-established practice
already :-)

> Right now, with the way it actually works in the field it is very disruptive every time the /64 is renumbered by the ISP In my experience this happens way too often. An end user should not have to go around and reboot devices, hunt around for the new printer IP and so on just because the ISP caused a renumber of their automatically assigned /64.

This is why "enter an IPv6 address for a device into anything else" should
be strongly frowned upon. Nobody should need to know the IPv6 address
for a printer in the first place.

mDNS exists, bonjour exists, these things actually work well.

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
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Hi,

On Fri, Oct 25, 2019 at 09:07:42PM -0300, Fernando Gont wrote:
> Not sure how many more 100's of messages are needed before we get to do
> something about it...

If something the IETF makes is not working properly out in the field,
it's never the IETF's fault. So you must be doing it all wrong.

The trick here seems to be to argue long enough to make people give up
and deploy IPv4 instead (lots of money to be made fixing other people's
NAT444 setups that nobody understand anymore, but "IPv4 is much easier!" -
just as a side note).

Seriously: I think your draft is a necessary document - whether to do it
in one or three documents, not sure, but maybe reaching individual
consensus is easier.

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
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Hi,

On Sat, Oct 26, 2019 at 04:06:17PM +0200, Bj?rn Mork wrote:
> Fernando Gont <fernando@gont.com.ar> writes:
>
> > They can't do stable addresses, and they are facing this problem.
>
> This is a constructed problem. The solution is to remove the
> construction.
>
> I realize that the "can't do stable addresses" might be enforced by
> non-technical entities, but this would most likely not happen if it was
> a violation of a standards track RFC.
>
> I'm sure you can fix that :-)

It's a fallacy that people are interested in RFCs that conflict with real
world constraints. Like, "must inspect arbitrarily deep EH chains
at wire speed". Or "must guarantee a static IPv6 prefix assignment
for the duration of a contract in an extremely low-margin market".

As I said before, this insistence on "IPv6 prefixes must never change!!
So if they change, we do not care about the consequences, but complain
about the change itself!!" is foolish to start with. People want to
change ISPs, want to multihome, if they have two ISPs, one or the other
might fail at times - so, getting our standards and implementations in
order to actually *deal with reality* (= prefixes change) would result
in a much nicer overall experience.

But then, since this is IETF, maybe reality is just all wrong, and just
not conforming to standards tracks RFC in the first place...

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
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Gert Doering <gert@space.net> writes:

> s I said before, this insistence on "IPv6 prefixes must never change!!

I never said that.

What I say is that renumbering is painful, and we should therefore
minimize the number of changes. We avoid all the pain if we avoid
renumbering.

> So if they change, we do not care about the consequences, but complain
> about the change itself!!" is foolish to start with. People want to
> change ISPs, want to multihome, if they have two ISPs, one or the other
> might fail at times - so, getting our standards and implementations in
> order to actually *deal with reality* (= prefixes change) would result
> in a much nicer overall experience.

I agree that we must deal with changing prefixes. Dealing with with is
just not the best solution to the self imposed problem of forced
changes.

Mulithoming is a different problem. Using more than one stable prefix
is not much harder than using one. The problem is prefix instability,
not the number of prefixes involved.

The main problem with renumbering is the large number of configuration
files, or nvram variables on id^H^Hiot devices, containing prefixes in
some form. This is mostly services using ACLs to differentiate between
internal and external sources. Examples from one of my hosts:

/etc/mail/access
/etc/dkimkeys/internal-hosts
/etc/spamassassin/local.cf
/etc/bind/named.conf.options
/etc/milter-greylist/greylist.conf
/etc/ntp.conf
/etc/squid/squid.conf

In addition to that, I also have a few more self-imposed prefix hard
coding:

/etc/init.d/firewall6
/etc/systemd/system/transmission-daemon.service
/etc/network/interfaces
/etc/dhcp/dhcpd6.conf

I left all DNS entries out.

Automating updates of all this is semi-trivial. But it is scripts that
has to be written, tested and maintained. And that will fail. Or be
incomplete. You may want to note that most of the files I list above
use an ACL syntax unique to that file. Not much standardization found
here...

Renumbering will never be completely painless. We can and should strive
to make it better. But forcing renumbering on end users is harmful and
should be avoided.


Bjørn
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1] [ In reply to ]
Bjørn Mork wrote on 27/10/2019 19:17:
> Automating updates of all this is semi-trivial.

this is completely atypical for what we are talking about, which is
residential consumer access, where you connect in, get some IP addresses
and then someone unplugs the CPE because they need to clean the shelf
where the modem is, and then nothing works properly because client
devices can't automatically renumber.

Your deployment use case is a stereotype case of needing static addresses.

The two things are not really comparable, at all.

Nick