But this is just an instance of the general case that some
source-destination address pairs work better than others.
Address selection heuristics don't do a good job solving this
problem - to solve this problem the network actually needs to tell
the host which source-destination address pairs will work well.
(and that's pretty ugly)
Yes, it's ugly, and it's not the only solution. Another is for the
client to initiate connections from every possible source address to
every possible destination address at the same time, and for the
transport protocol to support adding and removing L3 addresses from
the connection over its lifetime as each host gains/loses prefixes.
Good luck deciding which of the N*M paths to send payload packets over
for optimal throughput, latency, reliability, and cost (among which
the stack will likely have no indication of prioritization from the
app). And, of course, that'll entail a substantial rework of TCP and
most TCP stacks, which means it's at least a decade away. What are we
supposed to do until then?
for now, as best as I can tell:
- use PI address space if you can get it, but at any rate design your
IPv6 network to support multiple prefixes and renumbering. this
includes routing, security, network management, the whole ball o' wax.
- periodically test renumbering small portions of your internal network
(rotating through the different portions) to identify sources of
disruption. start with less critical portions and gain experience
with them, work up to more critical portions as you develop the tools
and identify which hosts, routers, firewalls, ALGs, proxies, traffic
monitors, applications, etc. need to be fixed.
- if you can't get PI space and need to multihome with different
addresses, provision your external connections so that both all address
prefixes have approximately equal connectivity and equal reliability. in
other words, it shouldn't matter which source or destination address an
application picks, they should all give good performance under most
conditions.
- make your IPv6 connectivity at least as good (for IPv6 hosts) as your
IPv4 connectivity, so that apps that pick IPv6 over IPv4 won't be penalized
- make your IPv6 security at least as robust as your IPv4 security, so
that IPv6 doesn't get the reputation as an end-run around your security.
- start out by assuming that IPv6 and IPv4 have the same filtering
policy for each service. then on a case-by-case basis assess whether
they need to be different, being aware that different policies can
confuse applications which are IP-version agile.
- if you have a need to make some hosts globally accessible via IPv6,
give those hosts 6to4 prefixes in addition to native prefixes so that
they can get connectivity from other 6to4 hosts without having to go
through relay routers.
- avoid ULAs. you might find that you absolutely have to have them in
a few cases for use by apps that simply cannot survive renumbering. but
those should be treated as exceptional cases and indications of a larger
problem, and the ULA should be treated as a temporary fix rather than a
permanent one.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf