Noel, (I know my reply is late)
I don't think LISP was ever intended to work in the circumstance where an IPv[46] xTR was talking directly to an IPv[64] (i.e. the opposite of the other one) xTR, via a IPv[4-6] translator box - just like we don't expect IPv4 routers to talk to IPv6 routers through an IPv[4-6] translator box. So I'm not sure we need to worry about that case either? Or do we need that case to work? Are there really going to be operational cases _during the term of the LISP experimental phase_ with IPv4-only xTRs needing to talk to IPv6-only xTRs?
My preference is to not design the protocol to handle this case.There's probably other similar corner cases that we should explicitly rule out of scope in the name of keeping our solution simple and being able to get it out there. It possible that even regular IPv4 NATs are something that could be ignored... though for them I understand that there are situations where being able to cross an IPv4 NAT would be useful. The problem is that supporting more of these situations leads to complexity. And sometimes it may seem easy to support something, until you try to design a failure detection and keepalive mechanism that allows the NAT bindings to stay up in a multihoming situation :-)
In any case, even if we don't support NAT64 or other corner cases, I would like to see that the LISP design is failsafe. That is, an unexpected condition should not result in a serious problem beyond loss of connectivity to the destination in question. It may be a good idea to check if a NAT did appear in the path.
Jari
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.