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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf