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