Re: [v6ops] Robert Wilton's No Objection on draft-ietf-v6ops-transition-comparison-03: (with COMMENT)

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 21 April 2022 14:46 UTC

Return-Path: <prvs=1110d8e56e=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9862D3A1870; Thu, 21 Apr 2022 07:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 EXYEXOEzEFBp; Thu, 21 Apr 2022 07:46:40 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 202DB3A185B; Thu, 21 Apr 2022 07:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1650552389; x=1651157189; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=j+ddfkyaTzO4U6KjwVFDiczmIUIfflZxJQqibBOeAlw=; b=CzzqbuNvQaJWl iZ0tiZW6fhfjAusHReON+BgYDxMWVxA4tkoibw+WPqTkCeNOKVjxhMkcVN+1eu7m KvqZmgaKXqQc3bBVIxn+P7cSy6sacoMBMbvtwgcaNzHDHZmL02NMlvnV3Q0PEXX7 ywvbBwkM8jKRcDqbHvIV4ROLv86EUk=
X-Spam-Processed: mail.consulintel.es, Thu, 21 Apr 2022 16:46:28 +0200
Received: from [10.10.10.145] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000848553.msg; Thu, 21 Apr 2022 16:46:28 +0200
X-MDRemoteIP: 2001:470:1f09:495:60bf:9f07:f69c:e0dd
X-MDHelo: [10.10.10.145]
X-MDArrival-Date: Thu, 21 Apr 2022 16:46:28 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1110d8e56e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/16.60.22041000
Date: Thu, 21 Apr 2022 16:46:26 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
CC: draft-ietf-v6ops-transition-comparison@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, rbonica@juniper.net
Message-ID: <5380676B-E42F-4374-B5F0-B8DB1B3A8FA2@consulintel.es>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-v6ops-transition-comparison-03: (with COMMENT)
References: <165053738993.9602.8757008086793686084@ietfa.amsl.com>
In-Reply-To: <165053738993.9602.8757008086793686084@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/PygXDK4ypaS-Mlo87MMQ1tdLJlM>
Subject: Re: [v6ops] Robert Wilton's No Objection on draft-ietf-v6ops-transition-comparison-03: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2022 14:46:52 -0000

Hi Robert,

    2.1.  464XLAT
       The customer-side translator (CLAT) is located in the customer's
       device, and it performs stateless NAT64 translation [RFC7915] (more
       precisely,

    Is NAT64 definitely right here, and not NAT46?

[Jordi] Yes, definitively there is some "copy and paste" mistake here.

Actual text:
The customer-side translator (CLAT) is located in the customer's
   device, and it performs stateless NAT64 translation [RFC7915] (more
   precisely, stateless NAT46, a stateless IP/ICMP translation from IPv4
   to IPv6).

To be replaced and shortened with:
The customer-side translator (CLAT) is located in the customer's
   device, and it performs stateless NAT46 translation [RFC7915] (more
   precisely, a stateless IP/ICMP translation from IPv4
   to IPv6).



    3.4.  IPv4 Pool Size Considerations

       Often it is assumed that each user-device (computer, tablet,
       smartphone) behind a NAT, could simultaneously use about 300 ports.
       Typically, in the case of a residential subscriber, there will be a
       maximum of 4 of those devices in use simultaneously, which means a
       total of 1,200 ports.

    Is a maximum of 4 devices in simultaneous use on a residential internet
    connection realistic?  This feels low to me, and potentially this is likely to
    be increasing over time.

[Jordi] We are expanding a bit that text. Actually if more than 4 devices (and I agree) are being used, the argument is better supporting the need for more ports per subscriber (or said in another way, less subscribers per IP), depending on the each specific IPv4aaS technology.

       If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E
       and MAP-T) make use of a 5-tuple for tracking the NAT connections,
       the number of ports required per subscriber can be limited as low as
       4 ports per subscriber.  However, the practical limit depends on the
       desired limit for parallel connections that any single host behind
       the NAT can have to the same address and port in Internet.  Note that
       it is becoming more common that applications use AJAX and similar
       mechanisms, so taking that extreme limit is probably not a very a
       safe choice.

    Previously we were talking about 300 - 1200 ports/subscriber.  It wasn't really
    clear to me how this goes down to just 4 ports per subscriber.

[Jordi] This depends on the implementation at the CE or CGN. Not all the implementations make an efficient use of a 5-tuple for tracking NAT connections. That why, at the beginning of the paragraph we have "if". We can try to find a more "explicity" way to stress it. May be "If the implementation of the CGN (in case of DS-Lite) or the CE implementation ...".

    If QUIC/HTTP3 deployment continues to pick up then I would expect that may
    reduce the number of ports required since it handled better multiplexing of
    streams.

[Jordi] Agree, we could add a final paragraph in that section, such as:

"Assuming that QUIC/HTTP3 deployment continues to pick up, then it can be expected that the number of required ports decreases, considering the multiplexing of streams."

    Finally, I think that having some sort of high level summary (maybe in tabular
    form) may be beneficial, e.g., comparing relative MTU overheads of the
    approaches, stateful vs stateless, IPv4 address scalability/usage.

[Jordi] We will definitively consider that. Tks!

    Thanks,
    Rob






**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.