Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

otroan@employees.org Mon, 30 November 2020 14:37 UTC

Return-Path: <otroan@employees.org>
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 56E1A3A0BEF for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 06:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 R33PkrFaTz0t for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 06:37:33 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A39F3A0BCC for <ipv6@ietf.org>; Mon, 30 Nov 2020 06:37:32 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:dce1:febc:423f:7934]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 24EA54E11B1B; Mon, 30 Nov 2020 14:37:32 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 235B84671822; Mon, 30 Nov 2020 15:37:30 +0100 (CET)
From: otroan@employees.org
Message-Id: <604EC7F4-E1EB-42A7-BD54-24A9F594473D@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_30D5A12A-4118-4AA5-91C1-8D00A7EA8116"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Date: Mon, 30 Nov 2020 15:37:29 +0100
In-Reply-To: <m1kjjtu-0000ICC@stereo.hq.phicoh.net>
Cc: 6man WG <ipv6@ietf.org>
To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
References: <m1kiLjK-0000EaC@stereo.hq.phicoh.net> <7BB64BE0-6A62-4711-91E4-1393EDC0809E@employees.org> <m1kiaW6-0000IFC@stereo.hq.phicoh.net> <5EB013E0-CC25-42AB-B5EF-3DBC82782B44@employees.org> <m1kidK6-00001eC@stereo.hq.phicoh.net> <965999C8-31C2-415C-9AB7-0B8129918BB9@employees.org> <m1kigqX-0000ETC@stereo.hq.phicoh.net> <A2BB24C1-F529-4712-AF8D-F0CE62066BC7@employees.org> <m1kjjtu-0000ICC@stereo.hq.phicoh.net>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BVeAA-_3bxTSxDlJr6M7f1MaR5g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Nov 2020 14:37:34 -0000

>> For the case you cite IPv4 NAT would work equally well.
> 
> You keep bringing that up. IPv4 NAT doesn't work very well if you can't get
> IPv4 addresses for your servers.
> 
> In addition, NAT CGN boxes are more expensive than IPv6 routing.
> 
>> This started with a discussion how to support multiple links (i.e.
>> more than a single /64).  We are the IETF and have a responsibility
>> to solve the general problem.  A site with an arbitrary topology.
>> Can you now please describe your solution?
> 
> For site with arbitrary topology, the solution is simple:
> - for inter-site prefix delegation use DHCPv6 PD, or (if we get agreement on it)
>  PD using RA.
> - intra-site use homenet.
> 
> Personally, I'd like to see a good solution for an intra-site tree topology
> where parties don't trust each other.
> 
> But homenet seems to have sacraficed practical security to support arbitrary
> topologies. And that seems to be your focus as well.

Right, so can you know describe how the network, hosts and applications are supposed to deal with flash renumbering?
Including servers in that network.

Specification, implementation and deployment status?

I'm drilling down on this to see if we can get a common understanding of what the IETF gaps are, and what the implementation and deployment gaps are.
(Not making any assumption that the IETF would ever recommend an ephemeral addressing model of course.)

Best regards,
Ole