Philip Homburg wrote: > I think that would have been a much better use of thse bits then simply > storing the ethernet address there. IPv6 address was (when it was SIP) and should be 8B, but extended to be 16B to store ethernet address with wrong reasoning of RFC1715 only to make IPv6 inoperational. At that time, it was 10B+6B, but as I pointed it out that IEEE1394 MAC is 8B long, it became 8B+8B. > But anyhow, it should be possible to do that with a destination option with is > then inspected by some middle box that makes a routing decision. But > that would require a lot of changes to retrofit it in todays operating > systems. That's no different from legacy NAT to violate the end to end principle. For example, just as legacy NAT, transport check sum depends on actually used address family and address. Thus, transport check sum must be recalculated by the middle box which changes address family. > That would require the dns64 box to do destination selection. Possible, but > maybe also tricky to keep a dns resolver informed about the current state of > the network. That's guaranteed to be impossible by the end to end argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Destination address selection is the function in question and complete and correct implementation by middle boxes is just impossible. The only approach for the address selection function is to do it at the end systems using "knowledge and help" of the end systems, which requires end systems have "knowledge" on default free global routing tables. Masataka Ohta _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf