Re: [v6ops] <draft-ietf-v6ops-464xlat-optimization-00.txt> - pre-(shepherd-writeup) review
JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sat, 11 July 2020 12:32 UTC
Return-Path: <prvs=1461d49966=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 98E113A0EA4; Sat, 11 Jul 2020 05:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 xQjFiXt3Kq2H; Sat, 11 Jul 2020 05:32:05 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id F0CDE3A0EA2; Sat, 11 Jul 2020 05:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594470721; x=1595075521; 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=mzXT7E0BZ8GbFsuHLu2VThx4DgndPoE6D/e2lF0woOI=; b=tVQTcSv0lUzrX 0SCtKfyHX8ARBR4YZPII+w+DHjc0tI/Uh2BxtSgGFcq9KmlU8g3JVMNwJ5x695jp SqdI1N18xlR9x72WOidyTbfqo7UHBSjMuY9YfLLNi+5hu6qbEO7+tzRsiOPyxTPh NekOEn3vh/Q4npF5TKDWs2SoZmrBLw=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sat, 11 Jul 2020 14:32:00 +0200
X-Spam-Processed: mail.consulintel.es, Sat, 11 Jul 2020 14:32:00 +0200
Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000273711.msg; Sat, 11 Jul 2020 14:31:59 +0200
X-MDRemoteIP: 2001:470:1f09:495:e8e7:5a00:b336:2a1e
X-MDHelo: [10.10.10.144]
X-MDArrival-Date: Sat, 11 Jul 2020 14:31:59 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1461d49966=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/16.38.20061401
Date: Sat, 11 Jul 2020 14:31:57 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Jen Linkova <furry13@gmail.com>
CC: Fred Baker <fredbaker.ietf@gmail.com>, draft-ietf-v6ops-464xlat-optimization@ietf.org, warren <warren@kumari.net>, V6Ops Chairs <v6ops-chairs@ietf.org>, "Alejandro D'Egidio (Telecentro)" <adegidio@telecentro.net.ar>, V6 Ops List <v6ops@ietf.org>
Message-ID: <AE47469D-92E4-44C2-A105-0800A7243451@consulintel.es>
Thread-Topic: <draft-ietf-v6ops-464xlat-optimization-00.txt> - pre-(shepherd-writeup) review
References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> <CAFU7BATueaCH5KL=-WVKZphs3fuwkOFvtmELPyQ9h9i4GBnkJw@mail.gmail.com> <CAFU7BAR8CaA6uKfm001J6fSfTNTrvyLffWfVurpBUs2HBxgPqw@mail.gmail.com>
In-Reply-To: <CAFU7BAR8CaA6uKfm001J6fSfTNTrvyLffWfVurpBUs2HBxgPqw@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8vzGZlSWSfLg-Lm6BRM92D2pM5s>
Subject: Re: [v6ops] <draft-ietf-v6ops-464xlat-optimization-00.txt> - pre-(shepherd-writeup) review
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: Sat, 11 Jul 2020 12:32:08 -0000
Hi Jen, Tks a lot, very useful inputs! Responding now to this ... sorry bit busy today with another document ;-) and as a consequence, a new version (-02) being published in a while ... El 10/7/20 5:58, "Jen Linkova" <furry13@gmail.com> escribió: OK, I"ve read the document and before I finish the write up I'd like to discuss a number of comments I have. My apologies for not raising them during the WGLC - I was not paying attention, got busy with work... 0) I might need coffee but I found the Abstract a bit confusing so if I may suggest some text.. ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case the traffic flows are translated twice: first from IPv4 to IPv6 (at the ingress point to then IPv6-only network) and then from IPv6 back to IPv4 at the egress point. If the destination is IPv6-enabled that second translation might not be required. This document describes some optimization to 464XLAT and MAP-T deployments to avoid translating IP6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilisation in the operator's network" [Jordi] Yep, tks, I'm happy to use this alternative text (slightly changed): IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network. 1) Introduction section The draft says: "allow IPv4-only devices or applications to connect with IPv4 services in Internet, by means of a stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]." Do you think it would help saying "with IPv4 services in Internet over IPv6-only infrastructure"? Otherwise it sounds confusing - why do we need anything at all to help IPv4-only clients to talk to IPv6-only services? [Jordi] Yep, tks! 2) ""This allows to translate the IPv6-only flow back to IPv4, in order to forward it to Internet." I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used extensively in the draft. [Jordi] Yep, tks! Reviewed across all the doc. 3) "In both cases (NAT46 and NAT64), the translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 addresses following [RFC6052]." IMHO this text would be more readable if we split it in two sentences: " In both cases (NAT46 and NAT64), the translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] . Translation between IPv4 and IPv6 addresses is done as per RFC6052]." [Jordi] I'm sure I've read/used this text in other documents and got no complains, but I'm happy to change it. 4) Section 3 is called "Possible Optimisation". However it comes before the Section 4 (problem statement) and the text seems to be more about the problem. Also, the first 3 paragraphs of Section 4 (until "until "As shown in the Figure 4" text) seem to repeat Section 3. Shall those two sections be merged? Or am I missing anything and they are actually talking about different things? [Jordi] This was a single longer section before, including the intro (which explains also some of your other inputs later on), but a previous review from the WG suggested to split it. I think it makes sense to keep the actual distribution of the text, as it follows a natural reading flow, even if the problem statement comes "later". May be an alternative is to rename section 4 as "problem statement summary" ? 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge of the synthesis of AAAA records from the A records, so they can use a NAT64, without the need of doing a double-translation by means of the NAT46/CLAT." - who are "they"? This is the first sentence of the section so not sure who you are referring to. [Jordi] Caused by the split of the section ... resolved now. 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? [Jordi] I think it was originally just LAN's or just Dual-Stack and when adding the other wording ... changed. 7) ""As it can be observed in the preceding picture, the situation is the same, regardless of in case of a wired network with a CE Router or a cellular network where a UE is connecting other devices (which may be IPv4-only or have IPv4-only apps), by means of a tethering functionality." IMHO it's a bit hard to parse...Maybe smth like: "Examples of a topology shown on the picture above includes: - a residential ISP IPv6-only access network with a dual-stack LAN behind a CPE performing NAT46 (CLAT); - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only applications running on that UE or for traffic originated by other devices connected to the UE via tethering." [Jordi] Yep, reworded. 8) Section 5.1. Approach 1: DNS/Routing-based Solution "5.1. Approach 1: DNS/Routing-based Solution "Because the WKP is non-routable, this solution will only be possible if the CDN/cache is in the same ASN as the provider network, or somehow interconnected without routing thru" Internet." Maybe it's worth explicitly mentioning that this approach would require that the path to the destination is NOT traversing NAT64 devices. Otherwise the simple configuration of such devices 'translate everything with the destination address in the WKP' would become much more complex. [Jordi] Is there "having more specific routing prefixes", anyway, I've added test to remark it. 9) Section 5.2.3 ""In normal conditions the TTL for both A and AAAA records, of a given FQDN, should be the same," I'm not sure it's the case actually and we can expect that to happen 'normally'. Do you have any references proving that point? [Jordi] I don't have in mind a reference. Tried to find it now, and no luck, but I'm sure is the correct way. If you have different TTLs for A and AAAA records strange things will happen to IPv4-only or IPv6-only or dual-stack users. Anyway, even if I'm wrong, the text we have doesn't get impacted, because for the optimization the important one is the AAAA record, as already indicated in the actual text. 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs Sorry but I have difficulties understanding those two sentences. What 'existing procedures' the resolver must be using? IMHO this section would be much easier to understand if there is an example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries would be created? As most CDNs would have multiple entries, this is a key point of the proposal. [Jordi] Existing procedures are either using the first RR, or shuffling among them (RFC1794). Whatever is done must be transparent to the CDNs. In fact, CDNs and caches usually (just done some random test to verify it) do the round robin. What it is clear, and this what I'm trying to say, is that whatever is doing the CE, should not be "modified" with the optimization, because the CDN is making sure that the response is good never mind it is any of the A records or any of the AAAA records. I will try to reword the text to make it clearer. 11) Section 5.2.8. Behavior in presence/absence of DNS64 "Furthermore, because as indicated in Section 5.2.2, the EAMT entry is not created when the service is IPv6-enabled." Is it correct? The section 5.2.2 seems to be talking about detecting IPv6 enabled services and using their AAAAs for creating EAMT entries. [Jordi] The "not" is a typo. Some wrong copy and paste. Anyway, I think I will reword the full paragraphs to make it clearer and actually shorter. 12) (related to 11) The draft seems to assume that the CPE/UA knows the NAT64 prefix somehow. As it's an operational document I believe it would be beneficial to provide some guidance on how exactly the device should discover the prefix. Obviously, the operator could use RFC8781 (PREF64 RA option) or PCE. Or the device and use RFC7050. However if the device uses RFC7050 then the Section 5.2.8 shall discuss this. [Jordi] I was having in mind using RFC8585, but actually never put it, because the other references (464XLAT, NAT64, etc., already have it). However now I think it is a good point having a reference to RFC8781, and all the other choices. 13) IMHO sections 5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should be follow each other or sections 5.2.9. might have a reference to 5.2.12. [Jordi] Ok. Moved 5.2.12 after 5.2.9. 14) Section 5.2.11 Behavior in presence of Happy Eyeballs IMHO, this section should make it explicit and very very clear: as soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs fallback to that IPv4 address becomes impossible. In case of connectivity issues with the IPv6 address used in that EAMT entry, the client would not be able to reach the destination. I feel like the draft does not discuss the impact enough. It's not about delay, it's about IPv6 becoming the only protocol to reach IPv6-enabled destinations for both dual-stack and IPv4-only hosts. Maybe it's a good thing in 2020 ;) [Jordi] I've pointed to this in the other email ... So, I think we agree on the possible tradeoff. I will see how I can improve the text to made it clearer. 15) Later in that section the draft says: " So even if Happy Eyeballs is present, the fallback to IPv4-only typically, will be slower than native IPv6 itself, because the added delay in the NAT46+NAT64 translations, when not using this optimization." I think it should be saying "IPv4 would be slower", not "fallback to IPv4". So maybe smth like " 'IPv4 is expected to be slower than native IPv6 due to delays added by NAT46+NAT64. This optimization reduced that delay by eliminating the need of the second translation (NAT64)"? [Jordi] Yep. All the happy eyeballs section re-worded and made more explicit. Note that depending on "where" the IPv6 failure is happening, IPv6 to a destination could be failing and IPv4 still working ... see the new text. 16) The draft does not discuss the troubleshooting implication. For example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and there is an EAMT entry for 8.8.8.8. IMHO this draft needs to discuss this and potential impact on tech support procedures. [Jordi] This is already considered, either via a CLI, GUI or both, you can configure static "invalid" entries: 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT be used and consequently no optimization performed. It may be used also for an explicit configuration (GUI, CLI, provisioning system, etc.) to disallow optimization for explicitly configured IPv4 addresses. 7. Auto/Static: When set to 1, means that this EAMT entry has been manually/statically configured, for example by means of an explicit configuration (GUI, CLI, provisioning system, etc.), so it doesn't expire with TTL. Anyway, I will add a specific section to remark it. 17) Another thing which seems to be missing is some guidelines on controlling this feature. I'd suggest adding some text about that. IMHO, the router vendors SHOULD (I'd vote for MUST even) have that optimization disabled by default. The routers MUST have a knob to turn it off if it's enabled. [Jordi] In my previous email already discussed about this. I've added this text: Note that this optimization MUST NOT be enabled when the WAN link is IPv4-only or dual-stack. In other words, only can be enabled if the WAN link is IPv6-only and consequently, the NAT46/CLAT is enabled in the CE 18) Acknowledgements Section Pls remove "....and TBD". [Jordi] I usually keep it open for last minute contributors, and the RFC editor close it (and they order them alphabetically, etc.). Done now. -- SY, Jen Linkova aka Furry ********************************************** 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.
- [v6ops] <draft-ietf-v6ops-464xlat-optimization-00… Jen Linkova
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… Jen Linkova
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… JORDI PALET MARTINEZ
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… Jen Linkova
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… JORDI PALET MARTINEZ
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… JORDI PALET MARTINEZ
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… Lencse Gábor
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… JORDI PALET MARTINEZ
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… JORDI PALET MARTINEZ
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… Erik Nygren
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… Jen Linkova
- Re: [v6ops] <draft-ietf-v6ops-464xlat-optimizatio… Erik Nygren