Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 14 June 2021 22:14 UTC

Return-Path: <brian.e.carpenter@gmail.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 20CBF3A103F for <v6ops@ietfa.amsl.com>; Mon, 14 Jun 2021 15:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsEG6o9XPscr for <v6ops@ietfa.amsl.com>; Mon, 14 Jun 2021 15:14:44 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F183A103C for <v6ops@ietf.org>; Mon, 14 Jun 2021 15:14:44 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id n12so9795146pgs.13 for <v6ops@ietf.org>; Mon, 14 Jun 2021 15:14:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CRzqoiK7up/zL+LnoZaFNXAmOeBYbyIwdLkxuaPWe9U=; b=lzqmYhoY1TyqawfCqXkUsd9upHJe5gcZg+fbPW86ZM0icZK86U0LnJt61nhZnNn1fS 8K6Byi9uhw7WAwB13BWJT+7qZtw/3yFzT84iHfibrP/pCORg32OP2H4CkhjmCu3oC7K/ ZrNlytg0z7C20DDeP2meBu9PyD1Z1qGiti4VBw/i6jI2JBayageqxCrt6XRhX/aMDF0K 9o1BdZgsA7esSf5dh96wk+qbDoA/L8NhNj2DgY98z8ZPWvs27CnOlctC3a+Abe6JHgGJ FPdBrsPW0ukDStgtjf5ZiB2cZtldjzEoZQcnOF6lT+SQdtofE0TzK604ZzCpWX8bq3hY PsZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CRzqoiK7up/zL+LnoZaFNXAmOeBYbyIwdLkxuaPWe9U=; b=MEQpifqe3J3JxtR7mvsvbchVycP1Xw2HNIxy8mWuNO9Bg43uo6y1mnj5FQRXbJfVyp ejtnvrXtp+7lI2ncUq9E37NLrLwwMRzfJJCtPihb45hTIU0NV3pgRAXE+uBQ/m3lpX/4 6IiSaJrnCWt6ljhfnLU0XOWdJYAX/Bap1PP+hnhs+E3DuLLk3uIfk8ObW7E4klz+q7KN er9PpWGj1B5qTbd3VnkXv7iKccAvRQA8Xkv8vAaQdEuCOwYSqM30yQJr1ar9cCH0O41K QmwO8InOcXWbLkTgA6DDE0ga1BdZ3OqWCxvn2x8DRy/In3L46C9GYO4Ompmax9gpNVoB 2LDA==
X-Gm-Message-State: AOAM533pHlZOuL//6vqrKnrEShnVQI+FkZ8RHP9XvgJAWLZfAwzaJpO1 tx5/SeJysMlTKwToInUpS7oCxK9EwK3U6A==
X-Google-Smtp-Source: ABdhPJwk7aeaG4j4sJwjTFqTEmqcCOdQVUZmp9G0KZFaCcN3VKLas9JinIWVJLR6Xq+/3/KwfIZ+Ng==
X-Received: by 2002:aa7:9569:0:b029:2f8:15b7:efc4 with SMTP id x9-20020aa795690000b02902f815b7efc4mr1363565pfq.2.1623708882194; Mon, 14 Jun 2021 15:14:42 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id nv1sm3272792pjb.43.2021.06.14.15.14.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jun 2021 15:14:41 -0700 (PDT)
To: "Dale W. Carder" <dwcarder@es.net>
Cc: IPv6 Operations <v6ops@ietf.org>
References: <162293202497.20978.11278185466573537743@ietfa.amsl.com> <d928f260-e0b1-7672-7114-7ac09dace037@gmail.com> <YMeqmaptccNjQnDM@dwc-desktop.local>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f97695ea-bb22-bdf6-9c35-c43a697338dc@gmail.com>
Date: Tue, 15 Jun 2021 10:14:37 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <YMeqmaptccNjQnDM@dwc-desktop.local>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vIBmFxo7up9kODQzMIw9TqCOcjA>
Subject: Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Jun 2021 22:14:46 -0000

On 15-Jun-21 07:14, Dale W. Carder wrote:
> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Fri, Jun 11, 2021 at 10:22:51AM +1200:
>> My concern about this draft is that it intentionally creates ambiguous address space, something we have very carefully avoided since the beginning of IPv6.
> 
> I'm not sure I worry as much about ambiguous as having more prefixes 
> be marked "special", some of the implications of which seem may be at 
> the heart of this proposal.
> 
> In draft-horley-v6ops-lab-00.txt,
> 
> "For instance, designing labs utilizing ULA fc00::/7
>    [RFC4193] is problematic due to the random global ID requirement
>    preventing hierarchical network prefix design possibilities."
> 
> Have the authors considered updating 4193?

I'd say that isn't even necessary. The #1 rule is that fc00::/7 must be
filtered at the IGP/EGP boundary. Inside that boundary, where's the harm
(for lab tests, staging, or training)?

The point about default address selection precedence is actually
more tricky, since it would need a config update on every host.

   Brian

> Is the randomness the issue,
> or is the resultant /48 the issue?  (of course, one could utilize
> multiple random /48's as I think has been pointed out)
> 
> "Further, default address selection behavior [RFC6724] by end nodes
>    may result in a depreferencing of such addresses and prevent lab
>    deployments from accurately modeling their desired non-lab
>    equivalents."
> 
> And this is the implication of having prefixes marked as special.  The
> default behavior (which is only a SHOULD, i think) is not configurable or
> at least not in a sane manner on a variety of platforms.  Presumably the
> closed ecosystem devices (handhelds, particularly) have a goal of
> minimizing user complaints and implement the table as specified, notably
> with ULA at a lower precedence than GUA.  Would your document also need
> to update 6724's table?  If I were a closed ecosystem vendor, once I
> found out that $new_prefix gets assigned for lab use, I would probably
> be inclined to move it fc00::/7 now that it becomes "special" rather
> than as a stock GUA.
> 
> Dale
>