Re: rfc4941bis: Change to Valid Lifetime of temporary addresses

Gyan Mishra <> Tue, 11 February 2020 00:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B3FC120895 for <>; Mon, 10 Feb 2020 16:02:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DaqcUvoP0TEs for <>; Mon, 10 Feb 2020 16:02:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14E3A120894 for <>; Mon, 10 Feb 2020 16:02:44 -0800 (PST)
Received: by with SMTP id h8so9744927iob.2 for <>; Mon, 10 Feb 2020 16:02:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IvZauG7goZT5EiUJUsgc7zk4fHy6yngKhA+2ncb1Ovo=; b=AI5ulHhqGjesmkN8CgofJbs1oJ9tqxdtVc3WzAp+pHNLXaMwxC/EsoJMqFTRDq/7eV ApkPO42sAy698y/sfTEKj5YWZaNXCCcbSPHuBKPCm2TetaMvBxLim1hIRVEJw52DkhXc HNPSj0PHqirL8g+3ABZ+9QitjdC1yL/rI6oIypJSefwcqk5Hq7R9h6HRlS7EpG1ZNvRQ KmHgjOnkh7aAcpKNcNKg76EkTJDNiKxXh/gBPuqPeplRoZG7im3yawJp3bfgTW41kwI8 NW7TyJOfdi1lfq3LitlcBiDRTTFF4UWVJ9UWArE0FTrUV584deOJ4xpBApl/FYGNTPtE lFkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IvZauG7goZT5EiUJUsgc7zk4fHy6yngKhA+2ncb1Ovo=; b=L0G2dbSMoyU/Dg1S8LOe0TuW+hn3VL8wQL891Hho6aqSTvb3FZZrYbDGSOYRaL4fma c3KX29LlvT9FriKqz7Fv2Wa4dYZzico4HOrd9tmvT2bRp7oerzFAW8/DMPb/V7udk+UB PJW3iByt6OkezEgZzrwePTv3L7H4KAr3F1gtvAVNnI9BXJkligUTle8kCjasJlUl04Vl ZjOWAP5vpcoMGu1mEPz990XgUiTVl2lOAXYYAWC2gd3jrZiPLp1HJFABNKNRZP8TxKQ8 nkQ0if7Uf0Dmm/PyfbM7PkOHt9J/zkzVqdBLnMhSYUfuHbWs6N8p4o0JVBVTKqzOJJX9 OCRA==
X-Gm-Message-State: APjAAAWnM1BnqyaA3NIzrjJUhVeOwp8gWL6YxHUUy0Cpg+4s6bUAN5gN iAF8UJGdnJ786/ox7cFWkLcfmtJHHvpA9C1+t2UY0g==
X-Google-Smtp-Source: APXvYqztDgftHS/K4GLHf77vaXq6Pj6KIFqq8qQY0d0ISaW6CWFlJ8AHM7M4XDLEa7WjrG8i/NcmVB114TIWzDKRq0o=
X-Received: by 2002:a5e:8505:: with SMTP id i5mr10876727ioj.158.1581379363261; Mon, 10 Feb 2020 16:02:43 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Mon, 10 Feb 2020 19:02:32 -0500
Message-ID: <>
Subject: Re: rfc4941bis: Change to Valid Lifetime of temporary addresses
To: Fernando Gont <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000033d0f5059e41930f"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 00:02:48 -0000

On Mon, Feb 10, 2020 at 10:52 AM Fernando Gont <>

> On 10/2/20 11:58, Gyan Mishra wrote:
> >
> >
> > On Mon, Feb 10, 2020 at 4:14 AM Fernando Gont <
> > <>> wrote:
> >
> >     On 10/2/20 01:44, Gyan Mishra wrote:
> >     [....]
> >     >     Comments? Objections?
> >     >
> >     >    Since we are proposing change of valid lifetime from 2 to 1 why
> not
> >     > make the valid lifetime 1 day as well - same as the preferred.
> >
> >     That's bad. That would mean that a connection that is started T
> seconds
> >     before the address becomes invalid could only have a maximum
> lifetime of
> >     T seconds.
> >
> >     Put another way, in the worst case scenario where a new connection is
> >     initiated with an address that is just about to become unpreferred,
> the
> >     maximum lifetime of the connection is ValidLifetime -
> PreferredLifetime.
> >
> >
> >     Walk me through it as far as end user impact when the address
> > becomes unpreferred versus deprecated.
> >
> >  So N = valid 1 day / preferred 1 day = 1 day
> >
> > As soon as the T time expires for preferred life it would become
> > unpreferred but not deprecated.
> unpreferred == deprecated
> > What is the difference from end user standpoint and impact in
> > connectivity with the address becoming unpreferred versus deprecated?
> Both are the same.
> > With existing connections would still be able to use the deprecated
> > addresses at time T at the preferred expire time or would their
> > connection be reset and they would have to re-establish on the new
> > preferred address?
> >
> > If existing connections get reset with 2 day valid lifetime at time T,
> > then if seems no different then unpreferred which would get reset as
> well.
> Please see RFC4861/RFC4862.

Found it

So now I understand what is bad about valid = 1 day which I surmised but
was not sure.  So the bad is the connection would reset immediately and the
address would become invalid once the valid expire time is reached being
the same as the preferred lifetime.  Very bad for any IPv6 user.

My concern is for long lived connections that may exist for enterprise
mission critical applications.  So given the scenario of valid = 2 days and
preferred = 1 day as proposed - once the preferred lifetime expires the
address is deprecated- for en existing long lived connection would continue
to use the deprecated address until the valid lifetime is reached at 2 days
-  at which time the address would become invalid.

The current RFC 4291 valid =7 preferred=1 in that same scenario for a long
lived connection the flow could continue to use the deprecated address
until the valid lifetime expires which is 7 days at which time it would
become invalid and the connection would reset and have to re-establish on
the new preferred address.  The major downside as we have discussed is
limiting the number of addresses on the host which a valid lifetime change
to 2 drastically drops the multiple prefixes from 7 down to 2.  From an
operations perspective even though the 7 day valid lifetime extends life of
long lived but in those cases if we have flows that last that long the
operators can chose to disable the temporary address as a workaround.
Having less addresses is a better choice from an operations perspective
then being able maintain very long lived connections.

5.5.4 <>.  Address
Lifetime Expiry

   A preferred address becomes deprecated when its preferred lifetime
   expires.  A deprecated address SHOULD continue to be used as a source
   address in existing communications, but SHOULD NOT be used to
   initiate new communications if an alternate (non-deprecated) address
   of sufficient scope can easily be used instead.

Note that the feasibility of initiating new communication using a
   non-deprecated address may be an application-specific decision, as
   only the application may have knowledge about whether the (now)
   deprecated address was (or still is) in use by the application.  For

example, if an application explicitly specifies that the protocol
   stack use a deprecated address as a source address, the protocol
   stack must accept that; the application might request it because that
   IP address is used in higher-level communication and there might be a
   requirement that the multiple connections in such a grouping use the
   same pair of IP addresses.

   IP and higher layers (e.g., TCP, UDP) MUST continue to accept and
   process datagrams destined to a deprecated address as normal since a
   deprecated address is still a valid address for the interface.  In
   the case of TCP, this means TCP SYN segments sent to a deprecated
   address are responded to using the deprecated address as a source
   address in the corresponding SYN-ACK (if the connection would
   otherwise be allowed).

   An implementation MAY prevent any new communication from using a
   deprecated address, but system management MUST have the ability to
   disable such a facility, and the facility MUST be disabled by

Other subtle cases should also be noted about source address
   selection.  For example, the above description does not clarify which
   address should be used between a deprecated, smaller-scope address
   and a non-deprecated, sufficient scope address.  The details of the
   address selection including this case are described in [RFC3484
<>] and
   are beyond the scope of this document.

   An address (and its association with an interface) becomes invalid
   when its valid lifetime expires.  An invalid address MUST NOT be used
   as a source address in outgoing communications and MUST NOT be
   recognized as a destination on a receiving interface.

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> --

Gyan  Mishra

Network Engineering & Technology


Silver Spring, MD 20904

Phone: 301 502-1347