Subject: [lisp] xTR to xTR via nat64 (Was: Re: Flow label redux)

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Sep 2009 21:41:02 +0300

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Sep 2009 20:28:11 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> 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?
    >> 

Jari> My preference is to not design the protocol to handle this case.

We've heard a numhber of people speak on this issue all wanting to
rule it out of scope.  So, I now think I have enough input to rule it
out of scope.