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
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
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
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
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.
Ietf mailing list