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

Timothy Winters <tim@qacafe.com> Mon, 27 November 2023 15:40 UTC

Return-Path: <tim@qacafe.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 4006DC151090 for <ipv6@ietfa.amsl.com>; Mon, 27 Nov 2023 07:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.507
X-Spam-Level:
X-Spam-Status: No, score=-0.507 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, HTML_MESSAGE=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 (1024-bit key) header.d=qacafe.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 J8yO6oO7NXQz for <ipv6@ietfa.amsl.com>; Mon, 27 Nov 2023 07:40:18 -0800 (PST)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 43928C15108F for <ipv6@ietf.org>; Mon, 27 Nov 2023 07:40:18 -0800 (PST)
Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-280351c32afso3932452a91.1 for <ipv6@ietf.org>; Mon, 27 Nov 2023 07:40:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; t=1701099617; x=1701704417; 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=xEfoD+iHfacIyIzZraRHtp715Euht/UkJe9tZSVO2Y8=; b=J0EG6uApgsFwEATy3tNQwP8nH1XaOgpA5iQVSdOeB6ZL2R/pBbGLNyJwjjAmJE61Sx mWSQ6ZCIAnNhfroT6A166Q1mDZ672xrcMfJYEoRs5iaCpn20kLnB5eBivcP1xkNQ+Bcl llGPiz+XlRMg60YYkzwpiSMlI4utIRIbX24Y8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701099617; x=1701704417; 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=xEfoD+iHfacIyIzZraRHtp715Euht/UkJe9tZSVO2Y8=; b=tY3QLp9AKHMvHqP3rHU9y321ZhUwza1wcAHaBTTZZlkz8jLgXNjUEC94COei9IS8kj yaWZPGpPRxwCfNpg4J+xzKrXDLxDzXHVMU8E5URyfvCKhXPtDfBeMYQUpfpWm6k8xXwa zlXsT8DuvsEZwGc79hChLrnnNQxjUvPSRQmfWQbVe/RAjGj4r3SiKmLCd1G2D/cZF/vC m3Pdmc+jfRbu8qMphkToocBAKs90i7KVc6isZV9zj7kln7FXMUbgmNfySVgECCxd1FHN jC83vLc5Clpshkgm6wwOBQX4EswxIeHMh5V3eGfbHYmZFJowENV7zMmXmRAOs1RIzqmX efHQ==
X-Gm-Message-State: AOJu0YxM+QZpHI3f1odQJZJAg/OTs+G0fDC/HUWdfZaAV9tHHRYSjYU/ j97FbvHZ8DY1NBPuVvfWPuWu7F1mVUHLFtZEKkr8cg==
X-Google-Smtp-Source: AGHT+IFjBJiBrPvvNqSBdQ8L2ka+MtTnA8aveM552SsKT/3FSVYJQsupv7yKRWkOvksiJCSYRVAGro68/81CrY9vxpI=
X-Received: by 2002:a17:90b:3a90:b0:285:8079:ebbc with SMTP id om16-20020a17090b3a9000b002858079ebbcmr14832452pjb.26.1701099617180; Mon, 27 Nov 2023 07:40:17 -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> <CAO42Z2zQORo08vFV34BAKKu+vK6t8GnHLLTSiBUsERNK0zHV8Q@mail.gmail.com>
In-Reply-To: <CAO42Z2zQORo08vFV34BAKKu+vK6t8GnHLLTSiBUsERNK0zHV8Q@mail.gmail.com>
From: Timothy Winters <tim@qacafe.com>
Date: Mon, 27 Nov 2023 10:40:05 -0500
Message-ID: <CAJgLMKuk+_GhymY3cEJvTW+UC=Eo+xtC3dhPVhNkviT1Qg2v4A@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org>, 6man Chairs <6man-chairs@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068faa1060b241ece"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OTPbtcPKJ1ZA1grFLq2BbGM-mQU>
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: Mon, 27 Nov 2023 15:40:22 -0000

Hi Mark,

As luck would have it, a design team is working on a 7084-bis.  I've made a
ticket for the team to look at 7084 side of ULAs.  Thanks for the text as
that will speed up the discussion.

~Tim

On Wed, Nov 22, 2023 at 11:32 PM Mark Smith <markzzzsmith@gmail.com> wrote:

> 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
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>