> From: Christopher Morrow <morrowc.li...@gmail.com>
> The original version of this discussion started on ipv6@, and was about
> what to do if/when a 4to6 (say a nat64 device) translator gets a packet
> that would match the criteria in question.
Now that it's morning, and my brain is actually functioning, this is a
non-issue. If LISP ever gets to production phase, the solution is trivial.
An ITR can tell from the mapping for the destination EID whether the ETR(s)
for that EID has/have IPv4 or IPv6 address(es) (or both). The spec can simply
mandate that packets destined for an ETR with only an IPv6 address have to be
emitted inside an IPv6 packet, and vice versa. So there will never be a need
for translation. Arrival of a LISP packet at a translator is an error, and the
translator _should_ silently drop it - a checksum error will do this nicely.
I'm not sure we want to include this mandate in the experimental phase of
LISP, for two reasons. First, it requires dual-stack implementations in all
xTRs, which to me seems an unneccessary burden for an experiment. Second, and
more important, there's still this whole issue of 'what happens if there's no
direct IPv6-native path between two IPv6 xTRs'?
Note that this problem exists whether we fix the translator problem using the
method above, or not. Two IPv6-only xTRs may or may not have an IPv6-native
path between them - if not, a tunnel will have to be arranged. (Barf.) You
_cannot_ use _translation_ to fix this problem, because that would mean you
have a way of mapping the entire IPv6 address space into IPv4 addresses -
clearly impossible.
Noel
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
