[lisp] LISP NAT Traversal [Was: Virtual meeting]

Albert López <alopez@ac.upc.edu> Mon, 30 March 2020 05:59 UTC

Return-Path: <alopez@ac.upc.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AD93A0DD9 for <lisp@ietfa.amsl.com>; Sun, 29 Mar 2020 22:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjmVMjW2nFe1 for <lisp@ietfa.amsl.com>; Sun, 29 Mar 2020 22:59:32 -0700 (PDT)
Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC4D3A0DD8 for <lisp@ietf.org>; Sun, 29 Mar 2020 22:59:31 -0700 (PDT)
Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 02U5xQVi029753; Mon, 30 Mar 2020 07:59:26 +0200
Received: from [192.168.1.130] (1.33.23.95.dynamic.jazztel.es [95.23.33.1]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id A2369204B; Mon, 30 Mar 2020 07:59:20 +0200 (CEST)
From: Albert López <alopez@ac.upc.edu>
To: lisp@ietf.org
Cc: Alberto Cabellos <acabello@ac.upc.edu>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "Jordi Paillisse Vilanova -T (jpaillis - AAP3 INC at Cisco)" <jpaillis@cisco.com>, Marc Portoles <mportole@cisco.com>
Message-ID: <55b348e3-66c3-0e5c-8028-446a3afa4249@ac.upc.edu>
Date: Mon, 30 Mar 2020 07:59:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------765646050D1A1252FE1E6EDF"
Content-Language: ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/M_MHD6sFtPx9NaCPE-1BXROWSyo>
Subject: [lisp] LISP NAT Traversal [Was: Virtual meeting]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2020 05:59:35 -0000

Hi Joel & all

I would also like to add the NAT Traversal draft discussion into the agenda.

We have experience implementing the NAT traversal functionality in our 
LISP open source implementation (OOR) which have support for Android and 
IOS devices. We believe that NAT traversal is a critical point for 
LISP-MN and we would like to share our experience on that. .

Our implementation is based on the draft-ermagan-lisp-nat-traversal and 
during its study some questions have emerged that could be interesting 
to discus:

  * What happens when a device handovers between NAT and not NAT
    interfaces? The xTR has to notify the remote ITRs, however an xTR
    behind NAT usually only has a default map cache entry with the RTR
    as a default gateway. Therefore, the xTR cannot notify directly ITRs
    of the change of the mapping.

  * What happens in the previous case if the not NAT interface is IPv6?
    IPv6 is a ­special case. We want to maintain the connectivity with
    established connections (keep using the same RTR, which has the
    map-cache). For that to work, the RTR needs to have an IPv6 to
    receive an SMR from the xTR after the handover (from the new xTR’s
    IPv6 RLOC). Therefore RTRs announced by the Map Server should have
    both IPv4 and IPv6. As we don't know which RTR IPv6 addresses map to
    which IPv4 addresses, all RTRs should be notified.
  * Which should be the procedure of an RTR in front of receiving an SMR
    from the xTR that just handover from NAT to not NAT? Probably the
    answer is that the xTR sends an SMR to the RTR which then has two
    options 1) the RTR can do an SMR to the appropriates ITRs based on
    the map-cache entries (but then how to know which of the map-cache
    entries were used by the xTR) or 2) it can act as a PxTR for the xTR
    that performed the handover. In that case, until when? Until the
    expiration of the TTL? Furthermore, what happens when an xTR roams
    again before the previous TTL expires.
  * Which is the mechanism to change the RTR used by and xTR?
  * Is there any procedure from MS point of view to notify associated
    xTRs to change the RTR they are using?
  * If a NATed device wants to manage their map request and map replies,
    which ITR RLOCS should use to fill the Map Request?

Best regards

Albert López