Iljitsch - I understand the theory behind what you're describing...in
practice, it's a hard problem to know where all the prefixes are that
should be changed; worse yet, it's hard to know which prefixes in
which parts of the configuration should be replaced with new prefixes,
and which shouldn't be changed.
In theory (where theory == reductio ad absurdum), renumbering is just
a network and host management problem. In practice, while SLAAC and
prefix delegation address some (I'll wager a fairly small percentage;
for that matter, DHCPv4 addressed the host renumbering problem years
ago) renumbering problems, most of the places where IP addresses are
configured were never designed with renumbering or any sort of
"signaling" in mind, and will be very difficult to automate.
- Ralph
On Dec 2, 2008, at Dec 2, 2008,2:11 PM, Iljitsch van Beijnum wrote:
On 2 dec 2008, at 20:02, Scott Brim wrote:
One way to fix that would be multipath transport protocols. Rather
than
try to guess what works best, just use all of them (or at least
several)
and get better performance without having to make difficult choices.
This doesn't help with site renumbering problems, just endpoint
renumbering.
NAT also helps very little with renumbering. The only thing that it
buys you is that you don't have to renumber routers and other
devices that have their addresses configured staticially sitting
behind the NAT. But routers can receive prefixes over DHCPv6 and
then use those prefixes to number their stuff rather than have this
done by hand, so there is _very_ little need for static address
configuration.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf