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

Michael Richardson <> Wed, 22 October 2014 18:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 263051ACEF4 for <>; Wed, 22 Oct 2014 11:05:03 -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 sCJyHZ8t9qnZ for <>; Wed, 22 Oct 2014 11:05:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DAD11ACDEE for <>; Wed, 22 Oct 2014 11:05:01 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 1057C200A7; Wed, 22 Oct 2014 14:05:50 -0400 (EDT)
Received: by (Postfix, from userid 179) id 467DF63A84; Wed, 22 Oct 2014 14:04:55 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 3088E63A21; Wed, 22 Oct 2014 14:04:55 -0400 (EDT)
From: Michael Richardson <>
To: James Woodyatt <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <CADhXe50Cg> <> <> <> <>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 22 Oct 2014 14:04:55 -0400
Message-ID: <>
Cc: HOMENET Working Group <>, Markus Stenberg <>
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: Wed, 22 Oct 2014 18:05:04 -0000

James Woodyatt <> wrote:
    >> My assertion:
    >> Given HNCP generated one spans whole administrative domain, _and_
    >> should not have routing anywhere outside it, it’s uniqueness does not
    >> _matter_.

    > Wait. Where did this "and should not be routable anywhere outside"
    > recommendation come from? And if it's only a recommendation and not a
    > requirement, then it still matters, right? I don't see that we can
    > meaningfully make it a requirement, and I would advise against
    > attempting to make it a recommendation. I don't believe such a
    > recommendation will be followed.

I won't mince words, "recommendation"/"requirement"/"potato"/etc..  I think
it's a very strong SHOULD, the only reason for someone to do otherwise would
by explicit geek-administator action.  Manually configuring a VPN for example.

It's not saying that ULA can never be routed by consenting adults, it's
saying that the Homenet ULA SHOULD never be routed outside that homenet.

Where it comes from; from the architecture document, I hope.
I'm pretty sure we said that somewhere, but I'll have to go search for the
specific statement.

I'm comfortable with a Homenet ULA existing in two places when equipment gets
seperated for a period of non-trivial time.   For instance, I fully
anticipate having 1-2 routers in my VM camper van, and I fully expect them to
travel.  {I might even bring up an explicit VPN to link stuff back together.}
I imagine that most people will expect their various conveyances, including
their (smart) backpacks to do this kind of thing.
Or taking stuff to the cottage for the summer, and bringing it back later on.
If we split up the 64K available /64s sensibly, it shouldn't be a big deal.

I think that it's entirely reasonable that giving up the ULA when you move
equipment requires an explicit administrator action, like holding down the
FACTORY RESET button.  Sure, people might not do that; sure there might be
some people confusion when 5 friends get together for a "LAN" party ("hey,
why are there three servers called 'quake'? Which one is "quake-1"?"), but I
don't think that will be any systems confused by such activity.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-