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

Pierre Pfister <> Tue, 21 October 2014 08:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E042E1A01BA for <>; Tue, 21 Oct 2014 01:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.207
X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qYUsTjR9yuJT for <>; Tue, 21 Oct 2014 01:28:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2D011AD3DF for <>; Tue, 21 Oct 2014 01:26:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 80D761408EEE4; Tue, 21 Oct 2014 10:26:05 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ED8B5977-52D5-4B5D-9D9F-A08135563F9B"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister <>
In-Reply-To: <>
Date: Tue, 21 Oct 2014 10:26:07 +0200
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <CADhXe53EiyUKM9DBwqVrVQv=ofgw8no4fpz83Dy0rC9UY-4SJQ @mail.g> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at (Tue Oct 21 10:26:06 2014 +0200 (CEST))
Cc: HOMENET Working Group <>, James Woodyatt <>
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: Tue, 21 Oct 2014 08:40:24 -0000


I tried to make a proposal which would deal with these network splits.
Even though I must say that the PA draft in the first place did not cause any problem when network splits and joins later (collisions are dealt with). This adds quite a bunch of complexity, and provides the conceptually pleasant idea that splited home networks will end-up using different ULAs (even thought it’s not a problem if they do).

So here it is:

9.1.  ULA Prefix Generation

   ULA prefixes can be randomly generated as specified in [RFC4193],
   enabling stable in-home IPv6 connectivity.

   In this section, we say a ULA delegated prefix is 'stable' if it has
   been the only advertised ULA delegated prefix for at least
   2*FLOODING_DELAY seconds.  The behaviour specified in the following
   sections tend to reuse a stable ULA prefix as long as its preferred
   lifetime is not null.

   Additionaly, we say a router is the owner of a spontaneously
   generated ULA prefix if it randomly created the prefix in the first
   place.  A router SHOULD NOT create more than one prefix this way, and
   MUST remember all the prefixes they own.  As stated in the following
   sections, only the owner of a prefix can extend its lifetimes.

9.1.1.  Choosing the ULA prefix

   When a stable ULA prefix is advertised, all routers SHOULD remember
   that prefix alongwith its associated valid and preferred lifetime.
   If this prefix stops being advertised (e.g. due to a network split)
   while its preferred lifetime is not null, the same ULA prefix SHOULD
   be selected using the same valid and preferred lifetimes.

   If there was no stable ULA prefix advertised, or if the preferred
   lifetime of the prefix was null, a prefix generated as specified in
   [RFC4193] SHOULD be used.  In case the stable storage can't be used
   or the current date cannot be determined, the prefix MAY be pseudo-
   randomly generated based on hardware specific values.

9.1.2.  Advertising a ULA prefix

   A router MAY start advertising a ULA prefix whenever the two
   following conditions are met:

   o  It is the network leader.

   o  There is no other advertised ULA prefix.

   If no IPv6 prefix is available at all, the network leader SHOULD
   start advertising a ULA delegated prefix.

   Additionaly, a router SHOULD start advertising its own ULA prefix
   whenever the three following conditions are met:

   o  A stable ULA prefix is advertised by another router.

   o  The router owns the advertised stable ULA prefix.

   o  The preferred lifetime of the advertised ULA prefix is below 10

   This allows a router to restart advertising a owned prefix whenever
   the preferred lifetime is approaching zero.  Which later allows him
   to extend the lifetime of the prefix.

   A router MUST stop advertising a spontaenously generated ULA prefix
   whenever one of the two following condition is met:

   o  A different ULA prefix is being advertised.

   o  The same prefix is advertised by another router, and the router
      doesn't own that prefix.

9.1.3.  Extending prefix lifetime

   Routers MUST regularly extend the valid and preferred lifetimes of
   the ULA delegated prefix they advertise and own, so that they never
   drop to zero.

   When a router advertises a prefix it doesn't own, lifetimes are never
   extended.  When the preferred lifetime of the prefix approaches zero,
   either the owner of the prefix will start advertising the prefix with
   a non-zero preferred lifetime, or a new prefix will be generated.

9.1.4.  Authoritative ULAs

   This section doesn't prevent multiple ULA prefixes from existing
   simultaneously.  ULA prefixes may be provided by different means, as
   specified in Section 4.3.  Delegated prefixes that are delegated by a
   service provider or provisioned by an authority differ from
   'spontaneously' generated prefixes.  They MUST NOT be withdrawn if
   another ULA delegated prefix is observed.

   When at least one of such ULA prefixes is used, spontaneously
   generated ULA prefixes are withdrawned.

Le 20 oct. 2014 à 23:00, Ted Lemon <> a écrit :

> On Oct 20, 2014, at 4:52 PM, James Woodyatt <> wrote:
>> I did read what you wrote, and I do not agree that you are taking into account my concerns.  Nevertheless, I shall stop arguing my case, and I will accept that I've lost it. 
> I persist in thinking that we are failing to communicate, but it would be a fair criticism to raise that this stuff is difficult to converge on in an email conversation, and a draft would be easier to discuss.  So I will try to write one up in my copious free time this week, and then we can probably converge.   I hesitate to write the draft because I am not convinced we will wind up actually doing what I am proposing, but it's probably worth it even if we don't actually proceed with it.
> _______________________________________________
> homenet mailing list