The solutions should be end to end that complex functionality must
be performed only on hosts.
I agree in principle. However, if we can give people the option to
offload this to a middlebox if they so desire, that's a plus. (Which is a
very different thing from requiring middleboxes or requiring routers or
other non-middlebox boxes in the middle to do it.)
I think the right approach is to allow the functionality to be implemented
hierarchically.Hosts needs help from routing protocols.
That's the same logic as suing a lawyer. At the surface it seems to make
sense but you really don't want to do it if you can avoid it.
However, with multiple addresses to an interface, selection of source
address/locator can be performed properly only with the help from
routing protocol, which is a reason why IPv6 is broken in
source address selection.
The trouble with current transport protocols is that once you've selected
your source address you can't change it. So we change it and then listen
for ICMP messages to see when we have the wrong source address.
I think the right way to think about this is that whatever device is
responsible for making decisions about dynamic source address selection can
usually benefit from hints from the routing protocols.Remember that path MTU discovery is pretty much mandatory in
IPv6 so you need those ICMPs.
No. PMTUD is one, among many, of a useless feature of IPv6.
Why is it useless?
Just send packets not loger than 1280B.
That's unacceptable.
In fact, we need to go even further and implement functionality in
neighbor discovery to enable the use of jumboframes between two hosts
that support them even though other hosts on the same subnet may not.
Exactly, although probably not important for small flows (< 100 Mb/s).