Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt

Mark Smith <markzzzsmith@gmail.com> Thu, 23 November 2023 04:32 UTC

Return-Path: <markzzzsmith@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 A1D8BC14CF1D; Wed, 22 Nov 2023 20:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.005
X-Spam-Level:
X-Spam-Status: No, score=-0.005 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, THIS_AD=1.599, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 lP3mk6XS1VR3; Wed, 22 Nov 2023 20:32:15 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 E999EC14CEFF; Wed, 22 Nov 2023 20:32:14 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-507a0907896so537143e87.2; Wed, 22 Nov 2023 20:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700713933; x=1701318733; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H2dmF6vKocCfPUSVOHpIfln2/Z7gDV7pDk39yAcDkTg=; b=IB6fhb1o4zcfgngSAs/5IQKdcicsqnZWpNKqjZGqo6FBmRSdh6KJ9gMtw6hqycyOvP li8p9KK0QU6pG7IxRFtHsH7hmJ3NsSOUj52vo4LuPUhkYgf2a1yVfNvxYiclnaWEFaqk J+I55J1H5kaiZpw2BEL7TkWXz2piPfNnnmxEnLGnHEsetyrBRsYPb2I9+twGrk5kKPvD ikhBcK7M6DSiEV7Yg6nWRFSpgeXxrDGrLlkWVWiyG4mu4VI0R6xNbIUGHEyJbFhOnqRH tfmXffmgQBu2LJYc4FM1D1mvcWuUDXXQjtJL2dX2+nEYJcdp5oXGq2ZY7qnpKpzk2QZb eZsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700713933; x=1701318733; h=content-transfer-encoding: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=H2dmF6vKocCfPUSVOHpIfln2/Z7gDV7pDk39yAcDkTg=; b=DSb+zPX4Y6SrY+f8tW3ZxMODUwGmmCuyuzIGvQZlTu96XKNvYx3u75gWheSva8Awv5 D8BBMmUSnb2raqU2UsQq/LPJFusyB/BMsgCN1VM6TLWQnSpL/nsD7TgspeIdhgN7siGZ 9Lgrwys3zePNdOS4msUePhdVkuHLcj7lpDLh9jqbaXizeL40FMUo9M6ZWSBUDzmRs/DR FJS50L81FcN6tKnHKS1TklQ9xn3Mu64lR18wCIGICaiFetkbG0/hzxG9L7o6wUf5o1gB pWnxicWkWeJ5RIOptisfxjvpaCPfAip/Om5UTLB04+Me47GLVUxQiiwwOeGBTQuRD+eR RJbg==
X-Gm-Message-State: AOJu0YwTUVFJVlYOvWmaS0iO+Mw84XBvsK3cgw/8Xto+cx4BI4h3l7Rc XxFWm1I3CKQEXO+XC7k8L9Z0Nh3T94nkgbzxw4ysuvRlMgM=
X-Google-Smtp-Source: AGHT+IE+oFiqpi8stRTpnOl7mmcUusIIbXHzwSn45vA7SQDw/iKpy+zntC/LOjqdmgW+v0zJAzNYhAQ8nijfAxPt5jc=
X-Received: by 2002:a19:7115:0:b0:509:4ab3:a8a3 with SMTP id m21-20020a197115000000b005094ab3a8a3mr2632031lfc.22.1700713932613; Wed, 22 Nov 2023 20:32:12 -0800 (PST)
MIME-Version: 1.0
References: <170059183545.4282.16453796503536671445@ietfa.amsl.com> <CACMsEX_RhsLq1eX5d6m0w93zjLdTNOmuK1-FqVvN3DRCoQkpVQ@mail.gmail.com> <3C840B68-1C34-44C9-9803-7C9468AC98C8@jisc.ac.uk>
In-Reply-To: <3C840B68-1C34-44C9-9803-7C9468AC98C8@jisc.ac.uk>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 23 Nov 2023 15:31:45 +1100
Message-ID: <CAO42Z2zQORo08vFV34BAKKu+vK6t8GnHLLTSiBUsERNK0zHV8Q@mail.gmail.com>
To: Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org>
Cc: 6man Chairs <6man-chairs@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eYjmjN82F9ScZQorOy6D3-Zl5f8>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt
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: Thu, 23 Nov 2023 04:32:18 -0000

Hi,

If it's going to put ULAs below GUAs, then both RFC 4193 (ULA RFC) and
RFC 7084 (IPv6 CE (CPE) RFC) need to be updated by this draft. I don't
agree with that preference of ULA below GUAs, however if that is going
to be the WG's consensus, then the consequences are greater than just
an update to RFC 6724.


RFC 4193:

The following advice and use cases need to be updated/negated/removed,
as if a local network's hosts have both GUA and ULA addresses, and
they're provided to a local network host via DNS, such as via
multicast DNS in RFC 7084, then the ULA addresses will never be used,
because the GUA addresses are preferred, making renumbering GUA
prefixes impossible without disrupting local network communications.

Consequently, it would be best if ULA addressing wasn't be deployed if
a network has GUA addressing, or ULA addressing should be deprecated
when GUA addressing is deployed, with the benefit being saving on
router and host processing of an address space that is unlikely to
ever be used.

Update:

1.  Introduction

   "This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications [IPV6]."

to something like:

   "This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications when Global Unicast
Address space [RFC4291]
   is not deployed [IPV6]."


Remove this paragraph:

RFC 4193:

4.1.  Routing

"It is expected that they would share the same Subnet IDs with
   provider-based global unicast addresses, if they were being used
   concurrently [GLOBAL]."


Rename and update this section:

4.2.  Renumbering and Site Merging

  " The use of Local IPv6 addresses in a site results in making
   communication that uses these addresses independent of renumbering a
   site's provider-based global addresses.

   When merging multiple sites, the addresses created with these
   prefixes are unlikely to need to be renumbered because all of the
   addresses have a high probability of being unique.  Routes for each
   specific prefix would have to be configured to allow routing to work
   correctly between the formerly separate sites."

to something like:

4.2.  Site Merging

"   When merging multiple sites, the addresses created with these
   prefixes are unlikely to need to be renumbered because all of the
   addresses have a high probability of being unique.  Routes for each
   specific prefix would have to be configured to allow routing to work
   correctly between the formerly separate sites."



RFC 7084 is an example of where ULA and GUA addresses can both be
provided by DNS to hosts, specifically by Multicast DNS (as LLAs
should be too).

Update:

3.2.1.  Local Communication

"Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used
   by hosts communicating within the end-user network across multiple
   links, but without requiring the application to use a globally
   routable address."

to something like:

"Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used
   by hosts communicating within the end-user network across multiple
   links, when the network and its hosts do not have globally routable
addresses."

Update:

"ULA addressing is useful where the IPv6 CE router has multiple LAN
   interfaces with hosts that need to communicate with each other."

to something like:

"ULA addressing is useful where the IPv6 CE router has multiple LAN
   interfaces with hosts that need to communicate with each other, when
   the local network does not have globally routable addresses available."


Add something like:

ULA requirements:

ULA-6:

"A CE SHOULD deprecate any ULA prefixes it is announcing when it
commences providing GUA addressing to hosts, by announcing its ULA
prefixes with a Preferred Lifetime of zero seconds, and a decrementing
Valid Lifetime, and then cease announcing its ULA prefixes when the
Valid Lifetime reaches zero seconds.

Should a GUA address space become unavailable, the CE's ULA address
space again be announced with the CE's ULA appropriate Preferred and
Valid Lifetimes."

Note that a 2011 era IPv6 CE implementation (Fritzbox) attempted to
perform this sort of ULA/GUA prefix "swapping". See Slide 28, "ULAs
with random part of all
zeros"

"Residential IPv6 CPE - What Not To Do and Other Observations"
https://www.ausnog.net/sites/default/files/ausnog-05/presentations/ausnog-05-d02p02-mark-smith.pdf


LAN requirements:

Update:

 " L-2:   The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) for each of its LAN interfaces."

to something like:

 " L-2:   The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix(es) (or its ULA prefix if configured to provide
          ULA addressing, conditional upon global prefix availability
- see ULA-6) for each of its LAN interfaces."


Update:

 "L-3:   An IPv6 CE router MUST advertise itself as a router for the
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) using the "Route Information Option" specified
          in Section 2.3 of [RFC4191].  This advertisement is
          independent of having or not having IPv6 connectivity on the
          WAN interface."

to something like:


" L-3:   An IPv6 CE router MUST advertise itself as a router for the
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing, conditional upon global prefix availability
- see ULA-6)
          using the "Route Information Option" specified
          in Section 2.3 of [RFC4191].  This advertisement is
          independent of having or not having IPv6 connectivity on the
          WAN interface."


Update:

"L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero or b) the lower of the current
          Valid Lifetime and two hours (which must be decremented in
          real time) in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862]."

to something like:

"L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, or the existing delegated prefix becomes unavailable,
          then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero or b) the lower of the current
          Valid Lifetime and two hours (which must be decremented in
          real time) in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862]."

Regards,
Mark.


On Thu, 23 Nov 2023 at 13:21, Tim Chown
<Tim.Chown=40jisc.ac.uk@dmarc.ietf.org> wrote:
>
> Hi chairs,
>
> Please hold the WGLC, we still have some further changes to make as a result of the 6man WG discussion in Prague.
>
> These include updating the abstract, the addition of text clarifying how the change will affect behaviour more clearly (Jen’s point), simplification of sections 3 and 6, and reduction and possible removal of Section 7.
>
> There’s also a potential change of title given the re-instantiation of the 5.5 text.
>
> Thanks,
> Tim
>
> On 21 Nov 2023, at 19:13, Nick Buraglio <buraglio@forwardingplane.net> wrote:
>
> Chairs,
>
> We have updated our draft to reflect feedback from the list as well as from IETF 118 and respectfully request consideration for WGLC. We believe this addresses the input and the problems it is aimed at remedying.
>
> Thanks,
>
> Nick, Jeremy, Tim
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Tue, Nov 21, 2023 at 12:37 PM
> Subject: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt
> To: <i-d-announce@ietf.org>
> Cc: <ipv6@ietf.org>
>
>
> Internet-Draft draft-ietf-6man-rfc6724-update-04.txt is now available. It is a
> work item of the IPv6 Maintenance (6MAN) WG of the IETF.
>
>    Title:   Preference for IPv6 ULAs over IPv4 addresses in RFC6724
>    Authors: Nick Buraglio
>             Tim Chown
>             Jeremy Duncan
>    Name:    draft-ietf-6man-rfc6724-update-04.txt
>    Pages:   11
>    Dates:   2023-11-21
>
> Abstract:
>
>    This document updates [RFC6724] based on operational experience
>    gained since its publication over ten years ago.  In particular it
>    updates the precedence of Unique Local Addresses (ULAs) in the
>    default address selection policy table, which as originally defined
>    by [RFC6724] has lower precedence than legacy IPv4 addressing.  The
>    update places both IPv6 Global Unicast Addresses (GUAs) and ULAs
>    ahead of all IPv4 addresses on the policy table to better suit
>    operational deployment and management of ULAs in production.  In
>    updating the [RFC6724] default policy table, this document also
>    demotes the preference for 6to4 addresses.  These changes to default
>    behavior improve supportability of common use cases such as, but not
>    limited to, automatic / unmanaged scenarios.  It is recognized that
>    some less common deployment scenarios may require explicit
>    configuration or custom changes to achieve desired operational
>    parameters.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6724-update-04
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-rfc6724-update-04
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------