Re: [homenet] Let's make in-home ULA presence a MUST !?

Ted Lemon <> Fri, 17 October 2014 22:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 998AE1A86ED for <>; Fri, 17 Oct 2014 15:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b4pnoUqLSQMI for <>; Fri, 17 Oct 2014 15:37:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9E2381A7D84 for <>; Fri, 17 Oct 2014 15:37:51 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id BCE85238045C; Fri, 17 Oct 2014 18:37:50 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Fri, 17 Oct 2014 17:37:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: James Woodyatt <>
X-Mailer: Apple Mail (2.1878.6)
Cc: HOMENET Working Group <>
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Oct 2014 22:37:52 -0000

On Oct 17, 2014, at 5:16 PM, James Woodyatt <> wrote:
> p1. It looks like you agree that locally generate ULA prefixes should be allowed to expire. What I don't see is any conceptual outline for deciding, in a distributed methodology, which prefixes to renew and which to release when their valid lifetime expires. Without seeing that, I can't agree that you've proposed anything that solves the problem I keep yammering about, much less offered a better solution than the one I proposed earlier in the thread.

Please don't put words in my mouth.

I did explain how to do that: before the network partitions, divide the ULA into 64k /64 prefixes, and distribute these evenly among attached routers.   Routers other than the ones that own a particular /64 are not allowed ever to use that /64 unless the router that owns it relinquishes it to them explicitly.   Prior to partition, an agreement is made that one of the routers gets to keep the ULA in the event of a long-term partition.   When a partition happens, the routers that aren't able to reach that router anymore need to start a process of deprecating the ULA and adding a new ULA.   Presumably after something like half the total partition/abandon timeout period, they generate a new ULA and deprecate the old ULA.   If the network is reconnected after that, the new ULA is deprecated, the old ULA is advertised as preferred, and things heal.

> p2. I also remain confused about the reasoning behind calling for a persistent locally-generated ULA prefix. In a previous message you said that it's okay for locally-generated ULA prefixes to expire, because there is no need for hosts on home networks to have any guarantee that at least one of its interface addresses is invariant over time, just that at least one of their addresses is never flash renumbered when a delegated prefix changes. As Lorenzo has demonstrated earlier today, this quality of never being flash-renumbered is easily met by delegated ULA and ordinary GUA prefixes.

No, I actually said that it's worth making some effort to avoid having ULAs expire.   But it's impossible to eliminate situations in which they must.   My goal is simply to avoid having things like simple reconfigurations of the network topology result in the generation of new ULAs.

> Returning to my question: why do we always need a locally-generated ULA prefix?  If it's to provide a time-invariant locally routable address to hosts, then locally generated ULA prefixes cannot ever be permitted to expire for any reason.  If they are ever allowed to expire, then they don't provide the time-invariant property.  However, if we don't actually need the time-invariant property, then what does a locally-generated ULA prefix do for us whenever one or more delegated prefixes is also present? It's not clear to me they are anything but absolutely redundant and unnecessary in that situation.

This is a bit of a straw man (see previous comment).   I think trying to keep a permanent ULA is a good thing.   We can't always succeed, but we can make the set of circumstances under which we fail as small as possible.   This is in contrast to what you are proposing, which is that we essentially set out to fail, and see deprecation events whenever the upstream network goes down.