I was a bit impetuous in saying that I would prefer not to modify libraries or implementations etc. However, my aim so far is more to obtain for myself a clear understanding of the problem we are trying to solve, rather than trying to state requirements of the possible solutions to that problem. My apologies for such a stupid statement.
I do believe that there are issues to be resolved and they are being currently reflected in threads like the one about deprecating site-local addresses and the need for provider independent addresses that is currently active, as well as the thread "solving the real problem" started by Tony Hain. I believe the issues being discussed there are real. You might not agree that they are.
If the issues are real, then we need to specify or formulate them in a way that is amenable to deriving solutions for them. If the issues are not real, then they are likely the artifacts of wrong perceptions or ideas that users and engineers in the IPv6 community have. In that case, we need to replace those wrong perceptions or ideas with correct ones. It seems to me though, that nobody has stated clearly what those wrong perceptions and ideas are, much less to say what is wrong with them and thus replace them with correct perceptions and ideas.
Yours sincerely, Robert Honore.
Masataka Ohta wrote:
Robert Honore;
I would also prefer not to modify any of the libraries or implementations of those protocols, lest we break something.
It is a wrong requirement wrong in various ways.
First of all, we must change something, which means we must change some code.
Though the changes should better be simple, whether the changes can be inserted as a module or not is irrelevant,
To make the changes simpler, the modification MUST be confined in libraries or kernel. So, we should try to change libraries or kernel to avoid changes on application code.
It, of course, is necessary to change application code for UDP cases for address selection that it is necessary to an API to control address selection in IP headers from applications that IP and transport layer code MUST be modified .
Secondly, preservation of code is less important to preservation of protocol and protocol is defined on the wire.
If you put some code below transport layer to modify packet content visible from the transport layer, which is the case with MAST, you change the transport layer protocol.
But, again, we must change something of the protocol.
So, the requirements are:
to modify existing code
to modify existing protocol
and any attempt, including but not limited to MAST, to avoid them is not constructive only to constraing the solution space to result in less capable and less efficient solutions.
Of course, it is desirable
to preserve existing application code
whenever possible. But, we must be aware that it is NOT always possible.
In addition, it is desirable
to preserve interoperability with existing protocols
which automatically means "to preserve interoperability with existing code of the peer". In this case, it is doable. Of course, all the freedom to use multiple addresses is lost when the peer is a leagacy one.
Masataka Ohta