ipv6-ops Digest, Vol 159, Issue 1
Ole Troan
otroan at employees.org
Thu Oct 24 14:41:28 CEST 2019
>> 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
More information about the ipv6-ops
mailing list