Re: [v6ops] [IPv6] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd

Lorenzo Colitti <lorenzo@google.com> Mon, 03 April 2023 07:25 UTC

Return-Path: <lorenzo@google.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 81A57C151543 for <v6ops@ietfa.amsl.com>; Mon, 3 Apr 2023 00:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.596
X-Spam-Level:
X-Spam-Status: No, score=-17.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZI_4FrVXPGz for <v6ops@ietfa.amsl.com>; Mon, 3 Apr 2023 00:25:22 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19661C151532 for <v6ops@ietf.org>; Mon, 3 Apr 2023 00:25:22 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id n1so14165618ili.10 for <v6ops@ietf.org>; Mon, 03 Apr 2023 00:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680506721; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u+yKGWUsCzR3lIRNks1zRxNBGdh874birBG7o4tV1mA=; b=KyMNDlous+Nq0EzVRXye8q12jdKWyBCYvHBtdhDmXSt3vlTVbpVVzTpTBHBeuw97rN M4vzjw7UPvgNL2tozvQdnOoDiTHJ2YOTBDA+vvkuDCQhGcWie6EqdAQ3gK7eaiA9AyoU M8cc9tA+H8kmLTpOcW6QCiDC+xqPzERwMtmcxj3eSckYTTfzueZshdB9asfEMYbkC+X5 fnb7uYvVVnG5TWLQk47ZJTZ+VBnDUUep1ibZlSCcm4uMuUTIXJQ1xsu0mw6w7n/qCDHT gdgvyeWzQWSq8gB4KeaWM2SdXHtD/iZeJKRu4VuCx5+SJSTqnGId3FEY85mE/Jb47GrI nqfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680506721; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u+yKGWUsCzR3lIRNks1zRxNBGdh874birBG7o4tV1mA=; b=ubqxnq/sdLPnz0JtWvLzespveYjMkL0Mz1+dUtNMGPrpPhttYggK4pSfA+VXg6xOXK 3w7jTMw/f9adR+AzcsaQpQ8JNrvDnmwu8KmTm7AJU9t16sYQ1NzYBQNwsF/h51IrngZJ x51/FPvahUzIkdAGoHnkFQ6DVHhtDuzc2YcDIQAPLCwpa90vzuc+gDrtdwUMPxjsR/9Q AA2qNoGVIxToi5SYQzrJiI34xK+J6Bt6PzFvWamw/xB887YIb3gW/SOXY4LuvEB7EVw1 4awTAe4raKR3QeS73di1dnXwhz3EcvMr48xSEEEDMKb6+5h0v4L8RLaJFeLXhMNBGXez CbQA==
X-Gm-Message-State: AAQBX9cu4k5RVaSnykMXWSb939yE2C61EIYfPdLVVbu81TaIO2x8auMm IYFawYVl0xjF6EMx5DGt87ombD5f6cqfXMgZIGbqRg==
X-Google-Smtp-Source: AKy350ZJpm7dITFDv2rqHK9fU2maiv7twTWtleFGfhto/cLxkwmVBLcFAIpJxblIM7d1OKqN83hVM5jglMrLFWHZ5CE=
X-Received: by 2002:a05:6e02:180f:b0:325:dae2:4238 with SMTP id a15-20020a056e02180f00b00325dae24238mr11055530ilv.2.1680506721129; Mon, 03 Apr 2023 00:25:21 -0700 (PDT)
MIME-Version: 1.0
References: <95e199dae3234a7ca7d64747d1fdc7be@huawei.com> <039F9553-EDDE-4D9E-A442-407A1CA711FD@employees.org> <6E715018-3096-4BDA-BD18-CF503BF7A91F@gmail.com> <CAFU7BAQr3MRTVOLJ+fEOPzV9hDFuc+N_fp_Y=Uo-_em4w+0HmQ@mail.gmail.com> <5EF90919-2064-4D29-A20D-152F7DFD38C0@tiesel.net> <AF7D285F-50DD-44F9-9B42-4A9F68D740A6@employees.org> <C9488569-C7A2-4D85-86FA-14F2E8A9D4CD@tiesel.net> <fb3d1c0b-f9a4-2d92-6224-cc538c3b1fca@gmail.com> <CAKD1Yr2CgTVTOOrQ3BF81445ye9cV+a3pjfbS79Q7bZpeGVOhw@mail.gmail.com> <EC4FA769-4737-405B-BF22-7484F46F420E@cisco.com> <11704.1680206070@localhost> <BD57E3BF-3642-43A1-BEA9-62E45E748BB9@cisco.com> <CAPt1N1k+rawdZLjzav7O_0sAmKeRiE1gPWWs+eXfWidCcJx0bw@mail.gmail.com> <334ABD09-211E-4183-BB7D-415060293FC6@employees.org> <6c84ae38-1d11-9e12-ed72-2bcecb4cef40@si6networks.com> <CAKD1Yr1VzjFJnMQTu5Dy5gmSgjT48bgGt=puA3f0vYVqZ=D2Xg@mail.gmail.com> <f918ff50-b948-0dcc-aa80-1bec696e9180@gont.com.ar>
In-Reply-To: <f918ff50-b948-0dcc-aa80-1bec696e9180@gont.com.ar>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 03 Apr 2023 16:25:08 +0900
Message-ID: <CAKD1Yr01L96ctwNJX=JaXmzT_8pqy_XpSp0qrsOCarq2zFQJ4Q@mail.gmail.com>
To: Fernando Gont <fernando@gont.com.ar>
Cc: Fernando Gont <fgont@si6networks.com>, V6 Ops List <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, Ole Troan <otroan@employees.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="00000000000028367a05f869769d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/o5w46yHUCvu65tGV9mnVfKPxQ68>
Subject: Re: [v6ops] [IPv6] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 03 Apr 2023 07:25:26 -0000

On Sat, Apr 1, 2023 at 9:36 PM Fernando Gont <fernando@gont.com.ar> wrote:

> > I would argue that at least part of the reason why kubernetes doesn't
> > use global IPv6 address is that it can't, because there is no easy way
> > to do that.
>
> Would you mind elaborating on this?
>
> My understanding of the situation is that Kubernetes use ULAs + NATs
> because that was the most straightforward thing to do: mimic IPv4.
>

Maybe. I guess my point is that even if they wanted to do global IPv6
addressing, they would have hit this limitation.

> The companion v6ops draft points out that on some enterprise networks,
> > using more than six addresses simply doesn't work at all. That means
> > that you can only use only three containers :-)
>
> Because of "first hop security" (limit on addresses/mac) or what?
>

The example I was thinking of is the one in draft-linkova-v6ops-ipmaclimi
<https://datatracker.ietf.org/doc/draft-linkova-v6ops-ipmaclimi/>. That one
is interesting because the limitation isn't even intended for security
purposes.



> > This proposal makes it possible to support an unlimited number of
> > containers without any scaling costs on the network. If it were widely
> > deployed, container setups might well switch to using global IPv6
> > addresses for every container. In addition to providing end-to-end
> > connectivity, it's much easier to implement and configure than NAT66+ULA
> > - just bridge the containers together on a virtual ethernet and use
> SLAAC.
>
> With Kubernetes you normally use a load balancer. So you typically don't
> want the containers to be visible to the external world.
>

"Visible" is not a boolean. Just because a container has a global IPv6
address doesn't mean that anyone on the Internet can reach it on any port.
But it could, for example, be visible by its global address on SSH for
connections from the corporate network. It could have a global address to
reach the Internet and download software updates. And so on.