Re: [IPv6] [v6ops] 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: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B52C151545 for <ipv6@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: -22.596
X-Spam-Level:
X-Spam-Status: No, score=-22.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_HI=-5, 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=ham 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 vEkL4c8yuunI for <ipv6@ietfa.amsl.com>; Mon, 3 Apr 2023 00:25:22 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 52A3CC151543 for <ipv6@ietf.org>; Mon, 3 Apr 2023 00:25:22 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id t5so3561238ilu.5 for <ipv6@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=XuMtY2ZnYqJ+SQfXh/JJo7ZpUmQq7qLGMNrdkMf8kWQVxV2NDcnqgof44kY+mIs0ut 8CtILXq9PjbIWMG94P8C/NlflJBEi8xDk/JQxQFSst1sIdv27T7JETJoYqIu29BxSGh4 Cb2dd1wWz28kqxmD/VigPvy3YDt1B2xEStH04VtWZIYw+vztQOQIXjE1HA32zj1Zg4Jr aAI8+24SBa/7F/iUno/oRwURYfKw7ScVCkAyMao32oVQRmYityJV7FBxEGJHCJk6ygVJ xwgKSzpgukUj3k5mEHoDE4CiUd29V4zZsOoTAllDCQyIb6ObfAGNZjA56o9DXtUKG4Op WCcw==
X-Gm-Message-State: AAQBX9cPlAO4ivIXcsH+vq4RLLmjlWJIF+NLmELLjfcin2mmQn68vT8/ G8pjO6t9ESGuZ74KKYLXGYea51xP6OBRmVdYjIB2Zg==
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/ipv6/VWr37JcDhCwpfr-n1wyGUPNDtDY>
Subject: Re: [IPv6] [v6ops] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-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.