Iljitsch van Beijnum wrote: > Well, someone has to do the dirty work... My years in multi6 taught me > that the people at each layer would be much happier if the complexity > happened at one of the other layers. Unfortunately, the routing layer, > which can solve this problem in small networks, can't do the same in > large networks because of scaling issues. Transport layers neither, unless you assume default timeout of TCP, which is no assumption for UDP nor unusual TCP. Unfortunately for IETF, there was little people being aware about that and, thanks to particularly poor chairmanship, the consensus of WG, including you but excluding people aware of the real problem, resulted in non-solutions similar to NAT. > (And our protocols aren't > especially smart: BGP knows how to avoid bad paths successfully in most > cases, but it isn't very good at picking the best path.) Protocols from multi6 is just as poor as that from IPv6 WG, of course, that is, unusable. > SCTP can do that That's simply an utter violation of layering similar to everything over not IP but HTTP. > (And IPv6 is a multi-address environment by design No. IPv6 itself is no better than IPv4 in handling multiple addresses. > The selection of the best address is currently under the purview of RFC > 3484, which doesn't have the tools to solve this issue satisfactory but > at least keeps the issue out of the applications, That's why the RFC is broken. > Really solving this means communicating > preference values and doing reachability tests and QoS measurments, No. Thank you for repeated demonstrations on your so poor understanding on the problem. Masataka Ohta _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf