Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

Naoki Matsuhira <matsuhira.ietf@gmail.com> Wed, 27 March 2024 00:57 UTC

Return-Path: <matsuhira.ietf@gmail.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 247A3C14F701 for <ipv6@ietfa.amsl.com>; Tue, 26 Mar 2024 17:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 we_4e4q1yxcc for <ipv6@ietfa.amsl.com>; Tue, 26 Mar 2024 17:57:50 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 49218C14F6B9 for <ipv6@ietf.org>; Tue, 26 Mar 2024 17:57:50 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-51588f70d2dso7443594e87.3 for <ipv6@ietf.org>; Tue, 26 Mar 2024 17:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711501068; x=1712105868; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J6bM7RApbsbsOOGpO2IQ3QNmbV17uFSAPC0/WHEVtT4=; b=mNwH2Qwk2YI6CIrGuzxlZ5eAfuY+PkwqZM2ynMIKDk6jqx+7w8YENfPxPIbsHDS0Ux k3neX5z4jNyWCEH8K5bGdl7Ie/dh7f66vrGHaKAghVXu1qcZE9uWebcBca01CLkTwXHR wN+kAZfvRvqDB+Rts9iOi11sj7B6pb2smdRVRnIapA/+Zriy4zltPjM8N9oP1+DOg7vH tyl5HM0Y6aJUgeBxebUOWxdwXOaPGX75bPc9Hy2THnZXmnWioJSz1o/t+s4k03AExYcA DOqSv5lIvxDoGuxVmLG3NOOSk2bTWFZrbCwtlblkDfwmKw+3SQS7R+NvM0aZ2C59Dcff 2XoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711501068; x=1712105868; 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=J6bM7RApbsbsOOGpO2IQ3QNmbV17uFSAPC0/WHEVtT4=; b=wWsAdfjQuOFCmNhAXLTcWmSYo23KMsNBjcso4jgZ3nNmoSL7VRjM5Kfwfdy8MgTrDr jVQMPxQasHxs2wy71BxLus+7IsA7dZ+vCfqomKFyqP74ZkPzPKMk6MDf16uaerkJWMdp TY6+GtwRbVzY7GwgkpO0sXkXkTP3xqAbfc1pOZFK9ob4JBL1cncS8yNBCCZK26ZhFcRc OQAluR/kj5VPoIKBx00msOhZm1eh0FxBZrjmbDWjmapgRk4cM1wkANj0sxmsKJFq+ViV NclrBQR6GYaz+x4hDuz0suuNXxnV8FjdrQLXdC69hfXN2PpZCNwRlAb4mPdQz35jkX38 yPYQ==
X-Forwarded-Encrypted: i=1; AJvYcCU1gzIKcENYclAwTi81KJyTa4TX9V7ngBASp6BRM9lCnBMq3xQyqxr5XdicVl+VxNK2JmpLJ1TUZ4bkRNqw
X-Gm-Message-State: AOJu0Yz0CFNHVvF0vxGu3yVhyyKBNBnUK5eB5QNAmK3bpwTLCZ9E2mxp GJ1x+vVcbZw6hd2MclJA46mxQVXZmzNoCOjp/5fxJcpR2V+45sLo3iV94wTLs+dOVU0G3nf/TSX WKzohNx/gIdSPYA/NBAsaYhYCMvs=
X-Google-Smtp-Source: AGHT+IHqpf96NoDgO0733PnrBkfoWQBmeO93ZVxrDAQy4lqAvQUekRYoN72bgZueJKexudoHLpfadp6rkiggIaK2hqA=
X-Received: by 2002:a19:f014:0:b0:513:dda5:a379 with SMTP id p20-20020a19f014000000b00513dda5a379mr2005153lfc.57.1711501067536; Tue, 26 Mar 2024 17:57:47 -0700 (PDT)
MIME-Version: 1.0
References: <df333346-f108-3782-0ff5-4bd85d7b49ac@gmail.com> <015F13BE-32F7-4C8B-8C86-C9153FE9C9E9@employees.org> <CAKD1Yr3dJ0EcMVPEGz-oHzNdWzJO1fE1u73Xxiw44BObuYTXbQ@mail.gmail.com> <CADmxuPExdq93HFRBpk6EeJdZsXOFQFDwB2EfVvkM++CDPb2gkg@mail.gmail.com> <CADmxuPEtbaehHwJhxfuhWzTeiZ7sHsveTrm69U2R67Swd1n0Bg@mail.gmail.com> <5ED8B6B1-991F-4D45-A3C3-C6BE20B00518@employees.org> <22452b49-227b-435c-9f2a-79bc231b00d9@gmail.com> <CADmxuPF1AReQCSY13HjqXE+8Jofy_uoo1wmnzs8+whG7Tdc+UQ@mail.gmail.com> <441440.1711451207@dyas>
In-Reply-To: <441440.1711451207@dyas>
From: Naoki Matsuhira <matsuhira.ietf@gmail.com>
Date: Wed, 27 Mar 2024 09:57:36 +0900
Message-ID: <CADmxuPG9p425O_r6MYb0GFGH9UsVaTYssNQdceiks=rP5-ajng@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000029cf1e061499e577"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/W0Br9Lua-QvQIGnOnCh1h25YxmU>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
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: Wed, 27 Mar 2024 00:57:54 -0000

Thank you for sharing the difficulty of obtaining PI IPv6.

I understood that there is a need for a method to implement both
multihoming using PI and multihoming without PI.

Naoki

2024年3月26日(火) 20:06 Michael Richardson <mcr+ietf@sandelman.ca>:

>
> Naoki Matsuhira <matsuhira.ietf@gmail.com> wrote:
>     > I understand that there have been many discussions over the years,
> and I
>     > think this is a very difficult issue. In the IPv4 era, there was no
> choice
>     > with assuming exhaustion of IPv4 addresses, but in the IPv6 era,
> there are
>     > plenty of addresses. If so, I think we should make use of our NAT
>     > experience from the IPv6 era.
>
> The rfc6296-bis document has short introduction that goes into the why.
> As you say, it's not about address exhaustion.
>
> I find that the applicability section (1.2) says a few small things and
> then
> gets into a feature/benefit analysis rather than a "when" to use this.
> I think that section 1.1 does a better job at what it sets out to do.
>
> I've said for over ten years that it's just way too hard to get PI IPv6.
> Particularly in the ARIN region.   I would be much happier with this
> document
> and technology if SME's could easily get PI IPv6.
> I don't mind if they have to NPTv6 it when their primary internet
> connection
> dies. (It might be annoying to applications though)
> It could be that many will arrange with all their ISPs to announce it, and
> some will worry that we'll blow up the DFZ.  Maybe.
>
> There have been other proposals, for instance the geographically assign IP
> address scheme from Tony Hain:
> https://datatracker.ietf.org/doc/draft-hain-ipv6-geo-addr/
> There are a number of ways to use it.  Probably never appropriate for
> single
> occupant homes, because of privacy.  But 100 storey buildings might be okay
> with it, and certainly SMEs will not have the same concerns.
> But a brilliant part about it is that far from that location, the addresses
> naturally aggregate.   At the time, we imagined that address to be the
> primary one for connection establishment, and then SHIM6 could negotiate
> some
> number of PA addresses.  We can't do that with SHIM6 (yet?!), but we could
> do
> that with QUIC and/or MPTCP.
>
> If this document is adopted and published, would you support adding a
> signaling mechanism to indicate that NPTv6 is in use?
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>