Mailing List Archive

You can often disable this on the host. Much of this is the lack of (or poor) configuration capabilities of the software/OS. If I know I always want to pick a specific IPv6 address in the same /64 it’s not too hard, but it’s also not as easy to configure without writing your own application.

The general consensus is that you shouldn’t use IP addresses and use some fixed name in the .local subnet and use mDNS to discover the device, but of course this often has it’s own issues.

Lets say I have 2 clothes dryers I’m connecting, I don’t know which one is dryer.local and which is dryer-1.local

- Jared

> On Oct 23, 2019, at 10:26 AM, Michael Sturtz <Michael.Sturtz@PACCAR.com> wrote:
>
> I have found more problems with the DHCPv6-PD. The issue is on many home networks where people are using server type hardware such as Windows(TM) networks where DNS is used to locate and secure the network the renumbering event creates major problems as the on premises DHCPv6 server has no way to understand that a renumber event has occurred. People are very used to the IPv4 RFC 1918 static addressing where nothing on their local internal network will change without notice. The fact that ISPs can randomly change the internal delegated address without notice is a major problem. That will confuse people and cause problems especially where a customer has equipment such as Windows or Linux servers or other equipment that requires static addressing or DHCPv6. I understand that for certain operational reasons ISPs need to renumber addresses however I suggest we discourage the practice. We also could modify the RFC to require a message to be sent by CPE to all downstream network devices that a network renumber event is being scheduled. This can be sent as a multicast message that encodes the date that the renumbering will occur. I realize that we need to understand the security implications of this. This is just one idea that could smooth the renumbering events when then have to happen for some operational reason.

Isn't that what ULA's are for?

________________________________
From: ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de <ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de> on behalf of Michael Sturtz <Michael.Sturtz@PACCAR.com>
Sent: October 23, 2019 10:26 AM
To: ipv6-ops@lists.cluenet.de <ipv6-ops@lists.cluenet.de>
Subject: RE: ipv6-ops Digest, Vol 159, Issue 1

I have found more problems with the DHCPv6-PD. The issue is on many home networks where people are using server type hardware such as Windows(TM) networks where DNS is used to locate and secure the network the renumbering event creates major problems as the on premises DHCPv6 server has no way to understand that a renumber event has occurred. People are very used to the IPv4 RFC 1918 static addressing where nothing on their local internal network will change without notice. The fact that ISPs can randomly change the internal delegated address without notice is a major problem. That will confuse people and cause problems especially where a customer has equipment such as Windows or Linux servers or other equipment that requires static addressing or DHCPv6. I understand that for certain operational reasons ISPs need to renumber addresses however I suggest we discourage the practice. We also could modify the RFC to require a message to be sent by CPE to all downstream network devices that a network renumber event is being scheduled. This can be sent as a multicast message that encodes the date that the renumbering will occur. I realize that we need to understand the security implications of this. This is just one idea that could smooth the renumbering events when then have to happen for some operational reason.

-----Original Message-----
From: ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de <ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de> On Behalf Of ipv6-ops-request@lists.cluenet.de
Sent: Wednesday, October 23, 2019 3:00 AM
To: ipv6-ops@lists.cluenet.de
Subject: ipv6-ops Digest, Vol 159, Issue 1

Send ipv6-ops mailing list submissions to
ipv6-ops@lists.cluenet.de

To subscribe or unsubscribe via the World Wide Web, visit
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.cluenet.de%2Fmailman%2Flistinfo%2Fipv6-ops&amp;data=02%7C01%7Cmichael.sturtz%40paccar.com%7Ce0b1f347a5cf432a761e08d7579fc9b3%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C1%7C637074216137461832&amp;sdata=jmfELsU1SabFN%2BnPssOkByWoExIqjKfLhJCotAe40FA%3D&amp;reserved=0
or, via email, send a message with subject or body 'help' to
ipv6-ops-request@lists.cluenet.de

You can reach the person managing the list at
ipv6-ops-owner@lists.cluenet.de

When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-ops digest..."




________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<http://www.rogers.com/web/content/emailnotice>



Ce message est confidentiel. Notre transmission et r?ception de courriels se fait strictement suivant les modalit?s ?nonc?es dans l'avis publi? ? www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________

My ULA is a /48 while Charter Spectrum only gives me a /64. Then I lose my
network info.

Amicalement,
Dave

Maple Park Development
Linux Systems Integration
http://www.maplepark.com/



On Wed, Oct 23, 2019 at 9:35 AM Kristian McColm <
Kristian.McColm@rci.rogers.com> wrote:

> Isn't that what ULA's are for?
>
> ------------------------------
> *From:* ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de
> <ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de> on
> behalf of Michael Sturtz <Michael.Sturtz@PACCAR.com>
> *Sent:* October 23, 2019 10:26 AM
> *To:* ipv6-ops@lists.cluenet.de <ipv6-ops@lists.cluenet.de>
> *Subject:* RE: ipv6-ops Digest, Vol 159, Issue 1
>
> I have found more problems with the DHCPv6-PD. The issue is on many home
> networks where people are using server type hardware such as Windows(TM)
> networks where DNS is used to locate and secure the network the renumbering
> event creates major problems as the on premises DHCPv6 server has no way to
> understand that a renumber event has occurred. People are very used to the
> IPv4 RFC 1918 static addressing where nothing on their local internal
> network will change without notice. The fact that ISPs can randomly change
> the internal delegated address without notice is a major problem. That
> will confuse people and cause problems especially where a customer has
> equipment such as Windows or Linux servers or other equipment that requires
> static addressing or DHCPv6. I understand that for certain operational
> reasons ISPs need to renumber addresses however I suggest we discourage the
> practice. We also could modify the RFC to require a message to be sent by
> CPE to all downstream network devices that a network renumber event is
> being scheduled. This can be sent as a multicast message that encodes the
> date that the renumbering will occur. I realize that we need to understand
> the security implications of this. This is just one idea that could smooth
> the renumbering events when then have to happen for some operational
> reason.
>
> -----Original Message-----
> From: ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de
> <ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de> On Behalf
> Of ipv6-ops-request@lists.cluenet.de
> Sent: Wednesday, October 23, 2019 3:00 AM
> To: ipv6-ops@lists.cluenet.de
> Subject: ipv6-ops Digest, Vol 159, Issue 1
>
> Send ipv6-ops mailing list submissions to
> ipv6-ops@lists.cluenet.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.cluenet.de%2Fmailman%2Flistinfo%2Fipv6-ops&amp;data=02%7C01%7Cmichael.sturtz%40paccar.com%7Ce0b1f347a5cf432a761e08d7579fc9b3%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C1%7C637074216137461832&amp;sdata=jmfELsU1SabFN%2BnPssOkByWoExIqjKfLhJCotAe40FA%3D&amp;reserved=0
> or, via email, send a message with subject or body 'help' to
> ipv6-ops-request@lists.cluenet.de
>
> You can reach the person managing the list at
> ipv6-ops-owner@lists.cluenet.de
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of ipv6-ops digest..."
>
>
>
>
> ------------------------------
> This communication is confidential. We only send and receive email on the
> basis of the terms set out at www.rogers.com/web/content/emailnotice
>
>
>
> Ce message est confidentiel. Notre transmission et réception de courriels
> se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel
>
> ------------------------------
>

As far as I know ULA was deprecated in 9/2004 however worse yet it isn't routable period so it isn't of much use since IPv6 to IPv6 NAT isn't permitted officially. I know that Cisco proposed IPv6 to IPv6 NAT but last I checked it wasn't accepted. Much of the IPv6 production equipment won't handle a statically configured IPv6 address such as the FE80/10 address and then still be able to use SLAAC or DHCPv6 to obtain a routable IPv6 address. This gets us to the problem. As far as I know IPv6 is supposed to be globally routable by definition and while ULAs are a great idea for completely offline networks I don't think at this point are a good solution for regular networks connected to the internet. As we add IoT equipment to local networks IPv6 is going to become very important to our community. When local networks go from dozens of devices to thousands IPv4 becomes unusable without network segmentation that most customers do not have the experience to handle. Think of it this way, a home network has a thousand IoT devices that will attempt to register their name with the local DNS server but because a lot of the local inexpensive consumer routers can't handle DNS registration this creates a major problem.

From: Kristian McColm <Kristian.McColm@rci.rogers.com>
Sent: Wednesday, October 23, 2019 7:35 AM
To: Michael Sturtz <Michael.Sturtz@PACCAR.com>; ipv6-ops@lists.cluenet.de
Subject: Re: ipv6-ops Digest, Vol 159, Issue 1

Isn't that what ULA's are for?

________________________________
From: ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de<mailto:ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de> <ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de<mailto:ipv6-ops-bounces+kristian.mccolm=rci.rogers.com@lists.cluenet.de>> on behalf of Michael Sturtz <Michael.Sturtz@PACCAR.com<mailto:Michael.Sturtz@PACCAR.com>>
Sent: October 23, 2019 10:26 AM
To: ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de> <ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>>
Subject: RE: ipv6-ops Digest, Vol 159, Issue 1

I have found more problems with the DHCPv6-PD. The issue is on many home networks where people are using server type hardware such as Windows(TM) networks where DNS is used to locate and secure the network the renumbering event creates major problems as the on premises DHCPv6 server has no way to understand that a renumber event has occurred. People are very used to the IPv4 RFC 1918 static addressing where nothing on their local internal network will change without notice. The fact that ISPs can randomly change the internal delegated address without notice is a major problem. That will confuse people and cause problems especially where a customer has equipment such as Windows or Linux servers or other equipment that requires static addressing or DHCPv6. I understand that for certain operational reasons ISPs need to renumber addresses however I suggest we discourage the practice. We also could modify the RFC to require a message to be sent by CPE to all downstream network devices that a network renumber event is being scheduled. This can be sent as a multicast message that encodes the date that the renumbering will occur. I realize that we need to understand the security implications of this. This is just one idea that could smooth the renumbering events when then have to happen for some operational reason.

-----Original Message-----
From: ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de<mailto:ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de> <ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de<mailto:ipv6-ops-bounces+michael.sturtz=paccar.com@lists.cluenet.de>> On Behalf Of ipv6-ops-request@lists.cluenet.de<mailto:ipv6-ops-request@lists.cluenet.de>
Sent: Wednesday, October 23, 2019 3:00 AM
To: ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>
Subject: ipv6-ops Digest, Vol 159, Issue 1

Send ipv6-ops mailing list submissions to
ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>

To subscribe or unsubscribe via the World Wide Web, visit
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.cluenet.de%2Fmailman%2Flistinfo%2Fipv6-ops&amp;data=02%7C01%7Cmichael.sturtz%40paccar.com%7Ce0b1f347a5cf432a761e08d7579fc9b3%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C1%7C637074216137461832&amp;sdata=jmfELsU1SabFN%2BnPssOkByWoExIqjKfLhJCotAe40FA%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.cluenet.de%2Fmailman%2Flistinfo%2Fipv6-ops&data=02%7C01%7CMichael.Sturtz%40PACCAR.com%7C0e31b7525c36472bb9e708d757c625c6%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C0%7C637074380867557710&sdata=XSlETXdVmXDZmb14C6uDMEU6Fl8wPKE4xPG0MG%2Fongw%3D&reserved=0>
or, via email, send a message with subject or body 'help' to
ipv6-ops-request@lists.cluenet.de<mailto:ipv6-ops-request@lists.cluenet.de>

You can reach the person managing the list at
ipv6-ops-owner@lists.cluenet.de<mailto:ipv6-ops-owner@lists.cluenet.de>

When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-ops digest..."



________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rogers.com%2Fweb%2Fcontent%2Femailnotice&data=02%7C01%7CMichael.Sturtz%40PACCAR.com%7C0e31b7525c36472bb9e708d757c625c6%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C0%7C637074380867557710&sdata=AgOc1x%2Fe%2BD4rLITDmg%2BoHaa41spxWeRIlj7yacu6bHY%3D&reserved=0>



Ce message est confidentiel. Notre transmission et r?ception de courriels se fait strictement suivant les modalit?s ?nonc?es dans l'avis publi? ? www.rogers.com/aviscourriel <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rogers.com%2Faviscourriel&data=02%7C01%7CMichael.Sturtz%40PACCAR.com%7C0e31b7525c36472bb9e708d757c625c6%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C0%7C637074380867567668&sdata=Ep%2B56ciyDF4%2BVQsXWtLmbjAtExyEfICqfOplyYhQERQ%3D&reserved=0>
________________________________

Hi,

On Wed, Oct 23, 2019 at 03:00:21PM +0000, Michael Sturtz wrote:
> As far as I know ULA was deprecated in 9/2004

Those were site-locals, not ULAs.

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

The only current RFC on ULA is fc00::/7 but fc00::/8 remains undefined and has not been accepted by IETF. The block fd00::/8 can be divided up. All of this said none of these addresses would be routable on the internet and since a lot of the end user equipment can't handle a statically configured ULA address and still obtain a routable address from SLAAC or DHCP6. This creates major problems for networks with limited IT support. On larger corporate networks with skilled IT people it's very likely that they will have a static allocation from an ISP however smaller networks without IT people it can become a serious problem. Those people won't be skilled enough to figure out ULAs anyway.

-----Original Message-----
From: Gert Doering <gert@space.net>
Sent: Wednesday, October 23, 2019 8:28 AM
To: Michael Sturtz <Michael.Sturtz@PACCAR.com>
Cc: Kristian McColm <Kristian.McColm@rci.rogers.com>; ipv6-ops@lists.cluenet.de
Subject: Re: ipv6-ops Digest, Vol 159, Issue 1

Hi,

On Wed, Oct 23, 2019 at 03:00:21PM +0000, Michael Sturtz wrote:
> As far as I know ULA was deprecated in 9/2004

Those were site-locals, not ULAs.

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

In my networks I use a combination of ULA's + SLAAC for anything that needs to behave like RFC1918 and disable address privacy so that the IP remains static, and for internet routable they use the prefix learned from the provider and propagated via SLAAC.

-----Original Message-----
From: Michael Sturtz <Michael.Sturtz@PACCAR.com>
Sent: October 23, 2019 11:52 AM
To: Gert Doering <gert@space.net>
Cc: Kristian McColm <Kristian.McColm@rci.rogers.com>; ipv6-ops@lists.cluenet.de
Subject: RE: ipv6-ops Digest, Vol 159, Issue 1

The only current RFC on ULA is fc00::/7 but fc00::/8 remains undefined and has not been accepted by IETF. The block fd00::/8 can be divided up. All of this said none of these addresses would be routable on the internet and since a lot of the end user equipment can't handle a statically configured ULA address and still obtain a routable address from SLAAC or DHCP6. This creates major problems for networks with limited IT support. On larger corporate networks with skilled IT people it's very likely that they will have a static allocation from an ISP however smaller networks without IT people it can become a serious problem. Those people won't be skilled enough to figure out ULAs anyway.

-----Original Message-----
From: Gert Doering <gert@space.net>
Sent: Wednesday, October 23, 2019 8:28 AM
To: Michael Sturtz <Michael.Sturtz@PACCAR.com>
Cc: Kristian McColm <Kristian.McColm@rci.rogers.com>; ipv6-ops@lists.cluenet.de
Subject: Re: ipv6-ops Digest, Vol 159, Issue 1

Hi,

On Wed, Oct 23, 2019 at 03:00:21PM +0000, Michael Sturtz wrote:
> As far as I know ULA was deprecated in 9/2004

Those were site-locals, not ULAs.

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




________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<http://www.rogers.com/web/content/emailnotice>



Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________

Hello, Michael,

On 23/10/19 09:26, Michael Sturtz wrote:
> I have found more problems with the DHCPv6-PD. The issue is on many home networks where people are using server type hardware such as Windows(TM) networks where DNS is used to locate and secure the network the renumbering event creates major problems as the on premises DHCPv6 server has no way to understand that a renumber event has occurred. People are very used to the IPv4 RFC 1918 static addressing where nothing on their local internal network will change without notice. The fact that ISPs can randomly change the internal delegated address without notice is a major problem. That will confuse people and cause problems especially where a customer has equipment such as Windows or Linux servers or other equipment that requires static addressing or DHCPv6. I understand that for certain operational reasons ISPs need to renumber addresses however I suggest we discourage the practice. We also could modify the RFC to require a message to be sent by CPE to all downstream network devices that a network renumber event is being scheduled. This can be sent as a multicast message that encodes the date that the renumbering will occur. I realize that we need to understand the security implications of this. This is just one idea that could smooth the renumbering events when then have to happen for some operational reason.

As noted in the draft, the renumbered home network is one of many
possible scenarios where the renumbering event occurs. While we can
certainly recommend stable prefixes, I do think that the network should
be robust in the presence of such events.

Thoughts?

Thanks!

Cheers,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

>> I have found more problems with the DHCPv6-PD. The issue is on many home networks where people are using server type hardware such as Windows(TM) networks where DNS is used to locate and secure the network the renumbering event creates major problems as the on premises DHCPv6 server has no way to understand that a renumber event has occurred. People are very used to the IPv4 RFC 1918 static addressing where nothing on their local internal network will change without notice. The fact that ISPs can randomly change the internal delegated address without notice is a major problem. That will confuse people and cause problems especially where a customer has equipment such as Windows or Linux servers or other equipment that requires static addressing or DHCPv6. I understand that for certain operational reasons ISPs need to renumber addresses however I suggest we discourage the practice. We also could modify the RFC to require a message to be sent by CPE to all downstream network devices that a network renumber event is being scheduled. This can be sent as a multicast message that encodes the date that the renumbering will occur. I realize that we need to understand the security implications of this. This is just one idea that could smooth the renumbering events when then have to happen for some operational reason.
>
> As noted in the draft, the renumbered home network is one of many
> possible scenarios where the renumbering event occurs. While we can
> certainly recommend stable prefixes, I do think that the network should
> be robust in the presence of such events.
>
> Thoughts?

I'm all in support for solving the larger problem of a network with ephemeral addressing.
The network layer is your smallest problem though.
One can imagine network layer solutions to parts of this problem. NAT, MIP, ILNP, Shim6.
Any solution must involve the upper layers, and I think many view this is problem in the realm of the transport layer (and perhaps a new session layer).

Is v6ops the place for that... probably not.

Ole

Hi,

On Thu, Oct 24, 2019 at 09:02:44AM -0300, Fernando Gont wrote:
> As noted in the draft, the renumbered home network is one of many
> possible scenarios where the renumbering event occurs. While we can
> certainly recommend stable prefixes, I do think that the network should
> be robust in the presence of such events.

Right. This is missing in the whole "only bad ISPs will ever give their
customers prefixes that are not stable" discussing - customers *change*
ISPs, and this should be as painless as it is in the IPv4+NAT world.

Thus, anything relying or implicitly assuming "IPv6 addresses are stable"
(in an unmanaged SoHo network) must be very much discouraged.

Maybe even dual-/48 multihoming can be made to work one day (and no, it
is not even working well in theory today, but even less so in practice with
the CPE implementations you can buy today).

Gert Doering
-- Operator
--
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

Mr. Doering, I could not agree with you more!
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. Essentially, this means we would need to ask ISPs for a stable IPv6 block and frequently we run into problems with the ISP not even understanding what we need even though their network backbone and endpoints are running IPv6! It took us a long time to be able to obtain a /48 that actually works at our main datacenter where we already have commercial fiber. Finally, due to our major contract with the provider we were able to escalate to support engineering that understood the requirements and got it working. Having ISPs randomly change the /64 that is allocated to end user networks creates confusion and operational problems for exactly the people who least understand what is going on and why there are connectivity problems. End users have become used to having a stable internal IPv4 address space for decades now we want them to switch to an unstable IPv6 internal network address space? I don't believe that ULA multi-homing is a solution either.





-----Original Message-----
From: Gert Doering <gert@space.net>
Sent: Thursday, October 24, 2019 11:50 PM
To: Fernando Gont <fernando@gont.com.ar>
Cc: Michael Sturtz <Michael.Sturtz@PACCAR.com>; ipv6-ops@lists.cluenet.de
Subject: Re: ipv6-ops Digest, Vol 159, Issue 1

Hi,

On Thu, Oct 24, 2019 at 09:02:44AM -0300, Fernando Gont wrote:
> As noted in the draft, the renumbered home network is one of many
> possible scenarios where the renumbering event occurs. While we can
> certainly recommend stable prefixes, I do think that the network
> should be robust in the presence of such events.

Right. This is missing in the whole "only bad ISPs will ever give their customers prefixes that are not stable" discussing - customers *change* ISPs, and this should be as painless as it is in the IPv4+NAT world.

Thus, anything relying or implicitly assuming "IPv6 addresses are stable"
(in an unmanaged SoHo network) must be very much discouraged.

Maybe even dual-/48 multihoming can be made to work one day (and no, it is not even working well in theory today, but even less so in practice with the CPE implementations you can buy today).

Gert Doering
-- Operator
--
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

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

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

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.

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

Nick I agree! The problem is from an operational support and protocol level we created this monster by selling the idea of "end to end connectivity" and "every end site will get a /64" that has been sold to even end users. I understand that the ISPs really don’t want customers to be able to serve content from consumer connections. This is likely why they are randomly changing the /64 allocated to the end sites especially on consumer lines. It is highly likely this situation wasn't anticipated when drafting the protocol. We can come up with a protocol solution to account for this which gives the ISPs the flexibility to renumber their networks as they need while at the same time not breaking connectivity for end sites when the renumber event occurs. I have personal experience with multiple devices that use SLAAC breaking connectivity for some indeterminate period of time when a network renumber event occurs. Yes this could be due to poorly implemented end devices etc. but the end point is people just disable IPv6 because of the headaches caused by it.

-----Original Message-----
From: Nick Hilliard <nick@foobar.org>
Sent: Friday, October 25, 2019 8:10 AM
To: Michael Sturtz <Michael.Sturtz@PACCAR.com>
Cc: Gert Doering <gert@space.net>; Fernando Gont <fernando@gont.com.ar>; ipv6-ops@lists.cluenet.de
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

Michael Sturtz wrote on 25/10/2019 16:21:
> Nick I agree! The problem is from an operational support and
> protocol level we created this monster by selling the idea of "end to
> end connectivity" and "every end site will get a /64" that has been
> sold to even end users.

The problem was more a cultural thing in the ietf - people wanted
devices to have autonomy and be able to select their own addressing
mechanism, and not be subject to the whims of the network operator.
Hence the intent behind /64, and SLAAC, and the difficulties that the
IETF has with DHCP.

The problem was (and is) that this vision didn't align well with
reality, particularly enterprise but also content hosting and other
deployment scenarios.

> I understand that the ISPs really don’t want
> customers to be able to serve content from consumer connections.
> This is likely why they are randomly changing the /64 allocated to
> the end sites especially on consumer lines.

The reason for this relates to address aggregation at the ISP rather
than wanting to prevent consumers from serving content. Honestly most
ISPs don't care whether people put content services on their house
connections because usually this doesn't create much extra cost (DOCSIS
and cell-phone systems excluded). What does cost a lot, though, is when
you have massive prefix disaggregation and you need to deal with
provisioning hell and gigantic IGP tables in order to provide people
static assignments, even if most people don't really need them. This is
why it's mostly a commercial problem rather than a protocol issue.

> event occurs. I have personal experience with multiple devices that
> use SLAAC breaking connectivity for some indeterminate period of time
> when a network renumber event occurs. Yes this could be due to
> poorly implemented end devices etc. but the end point is people just
> disable IPv6 because of the headaches caused by it.
Yep.

Nick