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.mcc...@rci.rogers.com> wrote: > Isn't that what ULA's are for? > > ------------------------------ > *From:* ipv6-ops-bounces+kristian.mccolm=rci.rogers....@lists.cluenet.de > <ipv6-ops-bounces+kristian.mccolm=rci.rogers....@lists.cluenet.de> on > behalf of Michael Sturtz <michael.stu...@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....@lists.cluenet.de > <ipv6-ops-bounces+michael.sturtz=paccar....@lists.cluenet.de> On Behalf > Of ipv6-ops-requ...@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&data=02%7C01%7Cmichael.sturtz%40paccar.com%7Ce0b1f347a5cf432a761e08d7579fc9b3%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C1%7C637074216137461832&sdata=jmfELsU1SabFN%2BnPssOkByWoExIqjKfLhJCotAe40FA%3D&reserved=0 > or, via email, send a message with subject or body 'help' to > ipv6-ops-requ...@lists.cluenet.de > > You can reach the person managing the list at > ipv6-ops-ow...@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 > > ------------------------------ >
