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 <[email protected]> Sent: Wednesday, October 23, 2019 7:35 AM To: Michael Sturtz <[email protected]>; [email protected] Subject: Re: ipv6-ops Digest, Vol 159, Issue 1 Isn't that what ULA's are for? ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Michael Sturtz <[email protected]<mailto:[email protected]>> Sent: October 23, 2019 10:26 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of [email protected]<mailto:[email protected]> Sent: Wednesday, October 23, 2019 3:00 AM To: [email protected]<mailto:[email protected]> Subject: ipv6-ops Digest, Vol 159, Issue 1 Send ipv6-ops mailing list submissions to [email protected]<mailto:[email protected]> 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&data=02%7C01%7Cmichael.sturtz%40paccar.com%7Ce0b1f347a5cf432a761e08d7579fc9b3%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C1%7C637074216137461832&sdata=jmfELsU1SabFN%2BnPssOkByWoExIqjKfLhJCotAe40FA%3D&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 [email protected]<mailto:[email protected]> You can reach the person managing the list at [email protected]<mailto:[email protected]> 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> ________________________________
