Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

Erik Nygren <erik+ietf@nygren.org> Thu, 09 January 2020 20:06 UTC

Return-Path: <nygren@gmail.com>
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 C823F1207FB for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2020 12:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 qBs7LrfZ-zD4 for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2020 12:06:33 -0800 (PST)
Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3072D120047 for <v6ops@ietf.org>; Thu, 9 Jan 2020 12:06:33 -0800 (PST)
Received: by mail-wr1-f43.google.com with SMTP id j42so8704000wrj.12 for <v6ops@ietf.org>; Thu, 09 Jan 2020 12:06:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=asA2LdLtS3hDfmQy07qapvt9+aU0J4Mgl8WhEhiC3jA=; b=IFnIMNF6JmGEqJQWmom5qeEsZtfBr5+pwuGJvYF+FzEJF7RHHn1gduEcK5HaI+qPwS /PyNHwRk4zUCOBTn6Crda0aupYxdKao6xm/5ynrWEWGVHnGFU8OccCXksmLdMpB/jCdL 4COk/gzNX7Kx4JMIk8H6qrRNfSqDqWJrRhTUQbYp5fD9Bm5Z/DeRWO0jPhEnfOj8NjUS uBDoyCX0Oueai7yiqdl8SqKBw5mOFWBCpoMWnnsXir2wYrZMkJ5z7hFlAhTFBff+6boq r6SgJoRwU+5mxoqkHEpaJ2Fr2MU8wD3naYPaM7L4/F/eEuCCYXiuPmxHKunA0Kw1oDQ+ e1hQ==
X-Gm-Message-State: APjAAAUYo4rsbkipInZc2zgWya6KuRoqXeJCDeE6uyO42Kk0L2B/QELw yeD1ql69fRrZyuXTWtenv4QzA24ImiqgGbZZoZJjdxH3
X-Google-Smtp-Source: APXvYqzoXt7R5irms54VdJAu6iTvm28YsfUY99kgQFnoM79cGG1qqnrShkbK2ZD+4KXTZs1rBJYgl46S9maLUXaeR/k=
X-Received: by 2002:a05:6000:149:: with SMTP id r9mr12622297wrx.147.1578600391487; Thu, 09 Jan 2020 12:06:31 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB5699BA200FB1CF3F05062EDAAE5A0@BN7PR05MB5699.namprd05.prod.outlook.com>
In-Reply-To: <BN7PR05MB5699BA200FB1CF3F05062EDAAE5A0@BN7PR05MB5699.namprd05.prod.outlook.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Thu, 09 Jan 2020 15:06:19 -0500
Message-ID: <CAKC-DJighXri3HkCAg8-91XpXLTVG6AfB44TE-wwtaUnxJJXAw@mail.gmail.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000093b8cf059bba8ba7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SfeQ4vJxxsyVRVOB-QWls3HSVhg>
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
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, 09 Jan 2020 20:06:35 -0000

While I'm very supportive of 464xlat as a transition technology, and while
I was very optimistic about this approach
at first (and may even have suggested some of the proposals included in the
draft), on subsequent
reflections I continue to have significant concerns about the fragility of
this approach.
Implementing this in a way that works well with a generic CDN  (ie, one not
managed
by the operator) will require a significant amount of state and complexity
in CPE devices.
It only will take one or two bad CPE implementations to result in CDNs
being forced to switch
content to IPv4-only to address user complaints, which would undo what this
is trying to achieve.

In particular, the fundamental issue is that the RR sets returned for A and
AAAA records
from many CDNs are not 1:1 and also change frequently during the lifetime
of connections.

As such, I continue to have serious reservations about trying to move this
forwards
as anything other than Experimental.  If we do move forward, the DNS-based
approach
needs to be comfortable moving lots more state into the CPE than I recall
seeing
in the last version of this that I read.   In particular, if DNS sees
changes to {A,AAAA}
pairings, it is critical to only apply those to future connections and not
break existing
connections, meaning that CPEs need to keep these rewrite rules associated
with stateful connection tracking.

With the use-case for this being IPv4-only devices, a question may be
whether
it is better to focus on trying to get those devices to implement native
IPv6 support
while handling them via a CLAT in the CPE for the time-being.  Alternately,
lw4o6
addresses the "offload stateful NAT off of the CPE" in a much less fragile
way.

        Erik






On Wed, Dec 11, 2019 at 2:25 PM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> wrote:

> Folks,
>
>
>
> Each week between now and IETF 107, we will review and discuss one draft
> with an eye towards progressing it.
>
>
>
> This week, please review and comment on
> draft-palet-v6ops-464xlat-opt-cdn-caches.
>
>
>
> When reviewing this draft, please indicate whether you think that V6OPS
> should adopt it a s a work item.
>
>
>
>                                                       Fred and Ron
>
>
>
> Juniper Business Use Only
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>