Re: Limited Domains:

Toerless Eckert <tte@cs.fau.de> Wed, 14 April 2021 22:23 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 BBC6C3A2251; Wed, 14 Apr 2021 15:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 c0ew4LBKN0mC; Wed, 14 Apr 2021 15:23:41 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F783A2279; Wed, 14 Apr 2021 15:23:41 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 97B8C54804B; Thu, 15 Apr 2021 00:23:34 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8F06E4400B2; Thu, 15 Apr 2021 00:23:34 +0200 (CEST)
Date: Thu, 15 Apr 2021 00:23:34 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Nick Hilliard <nick@foobar.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" <draft-filsfils-6man-structured-flow-label@ietf.org>
Subject: Re: Limited Domains:
Message-ID: <20210414222334.GB34032@faui48f.informatik.uni-erlangen.de>
References: <CALx6S35NBfVJmjqVwhNV3nui2avUOXn6ySMG3cxx2AvGkwr_Ow@mail.gmail.com> <08A6C3D2-A81C-413A-81B3-EFAAA9DBCCE5@cisco.com> <5b68beb6-a6f9-828b-5cca-9c5ec2bfbea7@foobar.org> <126B0A5E-B421-4B1F-AAEB-ABD48FFA4289@cisco.com> <CALx6S35yxqAqWJVhav-=+TB2ZyYttAFfsLNs6Btt+QUx__aQ1w@mail.gmail.com> <9b22cfe4-22eb-3977-2d25-79eb61370291@gmail.com> <17DC585D-3378-42BF-8CD0-67676BF0CFD3@gmail.com> <fa412769-893d-8bd8-ebfe-abfb741412a0@gmail.com> <20210414220141.GA34032@faui48f.informatik.uni-erlangen.de> <ef41dce7-6542-d91c-1648-9d420ce3caea@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ef41dce7-6542-d91c-1648-9d420ce3caea@foobar.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7jGQjC81oVMF0a4r-DE5-9ai3XY>
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: Wed, 14 Apr 2021 22:23:46 -0000

On Wed, Apr 14, 2021 at 11:10:54PM +0100, Nick Hilliard wrote:
> Toerless Eckert wrote on 14/04/2021 23:01:
> > Which IMHO does not exclude the option to design such a protocol for
> > limited domain in a way that it also supports "non-limited domains".
> 
> we already have this with MPLS, but it was designed from the outset as a
> limited domain protocol and was only later extended to interoperate outside
> the domain boundary, and only then in specific and carefully controlled
> circumstances.

Indeed. And this could probably improved.

> Re-scoping an existing inter-domain protocol like ipv6 into a limited domain
> situation is a fundamentally different proposition.  Unless the scoping can
> be managed on a mandatory per-packet basis, it's the sort of proposition
> that will end up causing a long wake of operational problems and
> consequences.

True. But i think we can collect the experiences we have, especially from
rfc1918 (multiple instances), ULA, IPv6 PD addressing /multiohoming and construct
from them the principles for a better protocol framework. Of course also
aspects such as the (now dead) site local addressing and (still alive)
4 bit of scope addressing in IPv6 multicast.

If we just stay where we are now, i am afraid that a lot
of industrial use of IP, which is IPv4 only will never move to IPv6
because the longer addresses and ULA are not really an improvement
over RFC1918 + NAT in the mindset of such operators. rfc1918 provides
"generic addressing", ULA not (for example). IPv4 addresses can be
memorized by operators, IPv6 addresses not (unless you use illegal
prefixes). Etc. pp.

> 
> Nick

-- 
---
tte@cs.fau.de