David Conrad wrote:
Paul,
On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote:
If you change ISPs, send out an RA with the new addresses, wait a bit, then
send out an RA with lifetime 0 on the old address.
Even if this works (and I know a lot of applications that use the socket() API
that effectively cache the address returned by DNS for the lifetime of the
application), how does this help situations where IPv6 address literals are
specified in configuration files, e.g., resolv.conf, glue for authoritative DNS
servers, firewalls/filters, network management systems, etc.? See sections 5
and 7 of
http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt
The point here is that if there is a non-zero cost associated with renumbering,
there will be non-zero incentive to deploy technologies such as NATv6 to reduce
that cost. Some folks have made the argument that for sites large enough for
the cost of renumbering to be significant, they should be able to justify
provider independent space and be willing to accept the administrative and
financial cost. While this may be the case (I have some doubts that many of the
folks using PA space now will be all that interested in dealing with the RIR
system, but I may be biased), it does raise concerns about routing system
growth and forces ISPs to be willing to accept long IPv6 prefixes from end
users (which some ISPs have already said they won't do).
Put your recursors, network management systems, fileservers, etc on ULA
addresses like I was talking about earlier. Then you don't have to
renumber those.
So the only change you should have to make is a firewall change.
Imagine a world with RFC-1918 and public ip space safely overlayed. For
anything you hardcode somewhere, unless it has to be publically
reachable, use ULA addresses and don't ever change them.
You could even choose to not have public IP space on your servers by
removing autoconf, though you could have public space on them so they
can apply updates, and simply block any inbound access to those
statefully with a firewall to prevent any outside risk.
-Paul
