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

From: Pierre Pfister <[email-masked]>
Date: Tue, 14 Oct 2014 09:43:59 +0200

Hello group,

The architecture document states the following:
- A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices [...]

This translates into section 9.1 in the Prefix Assignment draft:
- A router MAY spontaneously generate a ULA delegated prefix [...]

So, that MAY should probably be a SHOULD. But the reason for this mail is one level higher:

Question: Should the generation of a stable ULA prefix be a MUST in any case ?

Advantages would be:
- In the protocol design process, we could assume in-home IPv6 connectivity. No need for special case for IPv4-only connectivity, no need for special TLVs, flags, or whatever.
- In the implementation process, it is way easier to handle one single IP version for all in-home traffic. Let it be IPv6 !
- This connectivity would be more stable than IPv4 (which only exists when there is an IPv4 uplink). IPv6 enabled apps would therefore behave *better* than IPv4-only. Which would in the end help for transitioning.

Disadvantages are:
- The best (and probably only correct) way of advertising in-home ULA connectivity is using RIOs. Which some (e.g. apple's) devices don't support (yet?).
- Some currently existing implementation may fail when facing ULA vs IPv4 choice.

It looks to me that disadvantages will be overcome in the coming years if IETF requires implementation to handle ULAs and RIOs better.

So the question is, should I change the Prefix Assignment draft and make ULA existence a MUST so that we/developers can rely on that in our protocol design and implementation process ?

Cheers,

Pierre

---

From: Erik Kline <[email-masked]>
Date: Tue, 14 Oct 2014 17:12:36 +0900

I vote no, please don't make it MUST.

Among other things, if my home edge router losing it's upstream it (in
theory) doesn't have to deprecate the global prefix in the home, just
the default route.  Since I can't get to the Internet anyway, all I
need is (almost) any prefix, and the one I have is as good as a ULA
(if not better, since the upstream loss may just be a flap).

On Tue, Oct 14, 2014 at 4:43 PM, Pierre Pfister <[email-masked]> wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Oct 2014 10:21:11 +0200 (CEST)

> I vote no, please don't make it MUST.

I agree, ULA should be optional, not MUST.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 14 Oct 2014 11:24:57 +0300

> I agree, ULA should be optional, not MUST.

If we live in the land where we ignore existing broken implementations..

From my point of view, it should be SHOULD _always_ generate ULA (so that privacy oriented things in a home have a sane default without need for trusting firewalling), and MUST generate if no GUA around.

Keeping GUA around as long as it has valid lease lifetime is fine too, of course.

Cheers,

-Markus

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Oct 2014 19:25:39 +1100

> (if not better, since the upstream loss may just be a flap).

Deprecating the prefix doesn't make it unusable.   However by not
having a ULA prefix already you have the problem about when to
instantiate a ULA prefix.  You shouldn't be using a prefix beyond
the time it is delegated to you.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 14 Oct 2014 08:52:51 +0000

+1. Looking to what customers asks these days from CPE devices in IPv6 env, we should not start pushing ULA as MUST req.  It can be an option of course.

Regs
Carl

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: dinsdag 14 oktober 2014 10:13
To: Pierre Pfister
Cc: HOMENET Working Group
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

Among other things, if my home edge router losing it's upstream it (in
theory) doesn't have to deprecate the global prefix in the home, just the default route.  Since I can't get to the Internet anyway, all I need is (almost) any prefix, and the one I have is as good as a ULA (if not better, since the upstream loss may just be a flap).

On Tue, Oct 14, 2014 at 4:43 PM, Pierre Pfister <[email-masked]> wrote:
> - A home network running IPv6 should deploy ULAs alongside its 
> globally unique prefix(es) to allow stable communication between 
> devices [...]
>

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 14 Oct 2014 11:33:20 +0200

Looks like a good default policy to me.
So there always is at least one IPv6 prefix (if not a GUA, generate a ULA).

It still provides always-on IPv6 connectivity. And would therefore simplify protocol design and implementation.

Does it seems like a better compromise to you (Mikael, Erik, Wuyts) ?

- Pierre

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Oct 2014 12:14:35 +0200 (CEST)

> Does it seems like a better compromise to you (Mikael, Erik, Wuyts) ?

I would like to see the following (configurable):

If you have GUA, don't use ULA.
When last GUA lease expires, just keep this GUA until something else shows 
up, then deprecate and move away from it.

I would really prefer to have RIO so host doesn't see default route using 
this GUA with no connectivity.

My rationale for this is to avoid to have GUA expire and popping up ULA, 
and then deprecating ULA again when GUA shows up.

Advantage of deprecating GUA as soon as outside connectivity goes away is 
that using 0 lifetime RAs for this prefix when there is no outside 
connectivity and popping up ULA, means RFC6724 hosts will do the right 
thing.

I'm conflicted as to what the correct behaviour is. RFC3484 hosts probably 
doesn't support RIO either, so we're screwed either way.

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 14 Oct 2014 10:16:30 +0000

Hi,

Our operational mode is "managed CPE".  We can recommend our customer to use a certain approach, i.e. e.g. use ULA/do not use ULA.  So in that sense, creating a ULA if no GUA is present is not an option, as it will be present or not, no matter GUA delivered or not.  Of course, if it is enabled, this would be ok for the below.  But not every customer wants ULA.  It increases complexity for them, they can do as such nearly all without it, so go for an option without it.

So, either the customer has chosen to use ULA or not.  So, let's assume we would adapt this, and all of a sudden bring on ULA's on the customer's CPEs, he would for sure not be too happy about it, as he might start getting Q's on his helpdesk.
It is of course always open to discussion with a customer, but putting some rules in place like "enable ULA on an intf is no other prefix is there" is typically not an option.

Moreover, keep in mind that the operator can, at any time, switch of IPv6 on/off (upto  interface level) breaking this possibility for whatever reason (through TR-069).  Of course, this would "break" homenet stuff :-(.  Also the opposite is in place, i.e enable ULA remotely, but same principle applies here: either the ISP goes got ULA or not.

Regs
Carl

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Pierre Pfister
Sent: dinsdag 14 oktober 2014 11:33
To: Markus Stenberg
Cc: Erik Kline; HOMENET Working Group; Mikael Abrahamsson
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

- Pierre

---

From: Jouni <[email-masked]>
Date: Tue, 14 Oct 2014 13:48:37 +0300

+1 as well. 

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 08:44:03 -0500

> (if not better, since the upstream loss may just be a flap).

This is something we discussed at length back when we were doing the architecture document.   The problem with this approach is that it exposes you to flash renumbering when you get back online, or if you can't do flash renumbering, you could easily find yourself without connectivity because you are using the wrong source address.   Deprecating the global address when upstream connectivity goes away, and preferring the ULA for local communication, addresses this problem.   So I think that we need to have a really clear argument _against_ using ULAs to solve this problem in order for what you are saying to be true, and I don't remember that being an outcome of the previous discussion.

So while I am not sure I agree with Pierre's conclusion, I think his reasoning is pretty sound.

---

From: Gert Doering <[email-masked]>
Date: Tue, 14 Oct 2014 16:27:46 +0200

Hi,

On Tue, Oct 14, 2014 at 08:44:03AM -0500, Ted Lemon wrote:
> This is something we discussed at length back when we were doing
> the architecture document.   The problem with this approach is that
> it exposes you to flash renumbering when you get back online, or
> if you can't do flash renumbering, you could easily find yourself
> without connectivity because you are using the wrong source address.

"flash renumber is a problem" is pretty much a non-argument, as flash 
renumbering *will* happen, and devices in the home *will* have to handle it.

Carriers do it today - "here's a new /56, have fun", without even having
to reconnect.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 09:41:55 -0500

> renumbering *will* happen, and devices in the home *will* have to handle it.

Indeed.   The question is, should we increase the number of instances in which they are forced to handle it, or no?

> Carriers do it today - "here's a new /56, have fun", without even having

If this generates phone calls, they may change their minds.   It's early days yet.

---

From: Gert Doering <[email-masked]>
Date: Tue, 14 Oct 2014 16:59:30 +0200

Hi,

> Indeed.   The question is, should we increase the number of instances in which they are forced to handle it, or no?

Yes.

Because this is the only way that application developers will learn to
handle it.

(When I first learned that T-Online was forcing this on their customers,
I was quite upset.  After thinking about it for a few weeks, I came to the
conclusion that it's the inevitable and correct approach.  If you make
the homenet renumber only "every few months", like "when the router is
offline for longer than <x> hours", people and application developers
will start assuming that IPv6 addresses are something static - and then,
when that renumbering happens, you'll get uproar and support calls.  
Force a prefix change on homenets once a week, and developers will learn 
how to cope with it, without breaking every time, requiring application / 
appliance restarts, etc)

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 10:13:34 -0500

> Because this is the only way that application developers will learn to

Application developers _can't_ handle it.   Applications have no control over routing, and making applications do source address selection is a really bad idea.

I haven't encountered any ISPs that do flash renumbering, and I'm surprised to hear you saying that T-Online is doing it: that's not my understanding.   In general, providers that renumber their customers use graceful renumbering, not flash renumbering.   There's no reason to do flash renumbering.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 14 Oct 2014 17:20:50 +0200

>Because this is the only way that application developers will learn to

I'm happy my ISP doesn't do that. I would probably just use a tunnel instead.

One of the advantages of IPv6 is that it is way easier to run publicly
accessible services at home. You still need to put an address in DNS, but
that's a one time action.

(It would have been nice if there was a way to signal that this prefix is
sort of stable and that home routers would remember that. But I'm not holding
my breath)

Hmm, if changing prefixes is such a great idea, then maybe RIRs should do
the same :-)

---

From: JF Tremblay <[email-masked]>
Date: Tue, 14 Oct 2014 11:21:13 -0400

> Because this is the only way that application developers will learn to

+1, renumbering will happen and should be properly handled. 

A good example here is IPv6 renumbering from docsis domain splits in the cable world. In a typical case, a client would see a loss of upstream for 5-10 minutes followed with restoration with a new /56 GUA. Although techniques are available to limit renumbering during these events, they aren’t always deployed, for practical, technical or political reasons. From various discussions between cable operators, the rule of thumb is that this would typically happen roughly every 12 months for any single residential user. Cable users in areas seeing rapid growth or new technology deployments could expect shorter timeframes between renumbering events (every 4-6 months for example, or even shorter).     

I like the approach Mikael described earlier. Keep the GUA until it expires, then generate a ULA if required, if nothing else exists. Keeping the GUA beyond expiration should be avoided IMHO. I’ve seen broken implementations do this and causing a lot of headaches. The removal of the old GUA prefix before it’s expiration is also a problem in many implementations, but that’s probably a battle for another day.  

JF

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Oct 2014 11:29:22 -0400

Pierre Pfister <[email-masked]> wrote:
    > The architecture document states the following: - A home network
    > running IPv6 should deploy ULAs alongside its globally unique
    > prefix(es) to allow stable communication between devices [...]

Doesn't RFC7084 (6204) already say this?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 14 Oct 2014 15:34:46 +0000

I can confirm that.  We have a customer handing out a new prefix every 4 days.

Regs
Carl

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: dinsdag 14 oktober 2014 16:28
To: Ted Lemon
Cc: Erik Kline; HOMENET Working Group; Pierre Pfister
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

Hi,

On Tue, Oct 14, 2014 at 08:44:03AM -0500, Ted Lemon wrote:
> it exposes you to flash renumbering when you get back online, or if 
> you can't do flash renumbering, you could easily find yourself without 
> connectivity because you are using the wrong source address.

"flash renumber is a problem" is pretty much a non-argument, as flash renumbering *will* happen, and devices in the home *will* have to handle it.

Carriers do it today - "here's a new /56, have fun", without even having to reconnect.

Gert Doering
        -- NetMaster

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 14 Oct 2014 15:36:56 +0000

Initially, the requested "old" prefix did not get nack'd after the expiry date, resulting in an "outage" of around 10 seconds, so approx. 10 secs without v6 connectivity.  These days, the old requested / hinted prefix gets nacked by the dhcpv6 server, enforcing new state machine cycle.  This works very well.

Regs
Carl

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 14 Oct 2014 15:39:29 +0000

No:
The IPv6 CE router SHOULD be capable of generating a ULA
           prefix [RFC4193].

SHOULD, not MUST

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: dinsdag 14 oktober 2014 17:29
To: Pierre Pfister
Cc: HOMENET Working Group
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Gert Doering <[email-masked]>
Date: Tue, 14 Oct 2014 17:41:11 +0200

Hi,

> Hmm, if changing prefixes is such a great idea, then maybe RIRs should do

That reply doesn't surprise me the least, it's the standard answer from
every geek who has not spent a few weeks thinking about this :-)

My mom and dad do not put stuff in DNS.  If at all, their router does, and
*that* one perfectly well knows how to handle changing prefixes, and update
DNS if needed.  It has a menu listing currently active hosts, you pick a
host ID from it, give it a name, and it's published.  (It's not as good
as it could be, as you end up in the vendor's DNS tree and not in a 
DNS domain of your choice, but it's "running code")

Now, please tell me who is more relevant for *homenet*?  A geek who is 
stuck in "I want to do this the old way!  I have always done it that way!"
or "a standard mom and dad household"?

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 14 Oct 2014 17:46:06 +0200

Hi,

> Application developers _can't_ handle it.   Applications have no control over routing, and making applications do source address selection is a really bad idea.

Application developers MUST handle changing addresses, for example by not
doing silly things like "at startup, do some DNS resolving and socket
binding to a fixed address, and assume that the addresses you receive
are not changing".

I haven't even mentioned source address selection, as that doesn't come
into play for a singlehomed homenet - but as soon as the homenet gets
multihomed, applications would benefit a LOT from doing intelligent
source address selection.  Like in presenting users a selection menu
"use ISP? -> SpaceNet, HE.NET, don't care" and picking the appropriate
source address.

Yes, there's quite a bit of specifications missing to be able to do that
(like, how do I find a label to stick onto an address I find on my 
interface), but for a *homenet*, this is the way it needs to be - nobody
will fiddle with the router to do "http goes to SpaceNet, bittorrent goes
to HE.NET", but if the application can do it, it greatly empowers users.

> I haven't encountered any ISPs that do flash renumbering, and I'm
> surprised to hear you saying that T-Online is doing it: that's not
> my understanding.   In general, providers that renumber their
> customers use graceful renumbering, not flash renumbering.   There's
> no reason to do flash renumbering.

In the end, at some point in time, the old prefix goes away, however
you phase it.  So if the application stubbornly clings to it, it will stop
working.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 14 Oct 2014 18:17:28 +0200

>or "a standard mom and dad household"?

Just every business does it 'the old way'. Everybody relies on stable prefixes.
Runs services like DNS not routers, etc, etc.

I can replicate that at home. 

But then when I tell other people, they can't do it. Because on a consumer lines
it is just too complicated.

Current state is that many home routers have all kinds of bugs. So just putting
more features on a home router that often gets selected by the ISP to be as cheap
as possible is just not the way to go.

So in the end, consumers can only be dumb clients who have to rely on services
provided by 'the cloud'.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 11:20:10 -0500

> I can confirm that.  We have a customer handing out a new prefix every 4 days.

But let's be clear: is your customer doing flash renumbering, or gracefully renumbering?   If they are flash renumbering, are they doing it because they had a choice, knew they had a choice, and chose flash renumbering over graceful renumbering, or are they doing it because it's the solution you offered them?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 11:21:12 -0500

> every geek who has not spent a few weeks thinking about this :-)

This isn't a helpful response, Gert.   If you are right, you can explain the reason that you are right.   You don't have to accuse the people you are talking to of not thinking this through.

---

From: Dave Taht <[email-masked]>
Date: Tue, 14 Oct 2014 09:21:48 -0700

a data point: openwrt barrier breaker just shipped with ula generation enabled.

Another data point - I just deployed ipv6 source specific routing in
production. A box with an ipv6 address 5 hops deep in the network was
able to get out (through 4 routers without any ipv6 addresses, just
the fe80) Woot!

While the traceroute is weird, it's weirder with ulas. Each hop with
a ula generates a dns request which the local dns responder has no
idea what to do with,
and forwards upstream.

To me unless naming is solved thoroughly I'm really reluctant to
sprinkle ipv6 everywhere.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 14 Oct 2014 18:22:32 +0200

> to HE.NET", but if the application can do it, it greatly empowers users.

Indeed. And some devices like mobile phones already allow the user to say "only sync my photo album when on Wifi".

One thing that does worry me is every application developer having to re-invent the code for all of this (find labels, actually implement the networking code correctly etc). I think a standard API should be available for all of this. Otherwise all operating system vendors and distributions will come up with something completely different which will make it even harder for the application developers to do the right thing.

Cheers,
Sander

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 11:23:06 -0500

> you phase it.  So if the application stubbornly clings to it, it will stop

This is correct, but if you have a preferred and a deprecated prefix, the stack will automatically choose the preferred prefix.   And if your ISP deprecates the prefix rather than withdrawing it, chances are that by the time it expires, there won't be any applications using it.

So please don't gloss over the distinction between graceful renumbering and flash renumbering.  IPv6 was designed to do graceful renumbering, and the claim that flash renumbering is no different is a major step backward from the functionality that was designed into IPv6.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 11:25:48 -0500

> binding to a fixed address, and assume that the addresses you receive

This has little to do with renumbering on the network to which the application is connected.   I agree that applications should do this, and that applications that don't will break if the provider renumbers, but we are talking about renumbering in the homenet, not renumbering of network services outside the home.

If you are referring specifically to naming in the home, while it's true that applications should support service address renumbering in the home, that is orthogonal to the question of whether services in the home should be numbered using ULAs or GUAs.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 11:27:29 -0500

> One thing that does worry me is every application developer having to re-invent the code for all of this (find labels, actually implement the networking code correctly etc). I think a standard API…

It would be helpful if you could participate in the MIF working group, which is working on solving this problem.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 14 Oct 2014 18:37:59 +0200

Hi,

> Op 14 okt. 2014, om 18:27 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> 

Will do :)
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Oct 2014 20:44:31 +0200 (CEST)

On Tue, 14 Oct 2014, Ted Lemon wrote:

> surprised to hear you saying that T-Online is doing it: that's not my 
> understanding.  In general, providers that renumber their customers use 
> graceful renumbering, not flash renumbering.  There's no reason to do 
> flash renumbering.

I know providers that cycle their PPPoE sessions once per day to give 
customers new IPv4 GUA once per day.

I have heard of some countries where customers expect to get new address 
all the time, otherwise they scream about lack of privacy.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 14:15:47 -0500

On Oct 14, 2014, at 1:44 PM, Mikael Abrahamsson <[email-masked]> wrote:
> I know providers that cycle their PPPoE sessions once per day to give customers new IPv4 GUA once per day.

Right.  This is IPv4.  In IPv4 we typically use a NAT on the local wire, so we get the effect we are trying to achieve either by retaining stale GUAs or using ULAs on the local wire in homenets.   IPv4 also does not provide graceful renumbering, so if the ISP wants to force an IPv4 address change, they have no choice but to do flash renumbering.   The UX is not good.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 14 Oct 2014 12:19:56 -0700

On Tue, Oct 14, 2014 at 1:24 AM, Markus Stenberg <[email-masked]>
wrote:

>
> From my point of view, it should be SHOULD _always_ generate ULA (so that
> privacy oriented things in a home have a sane default without need for
> trusting firewalling), and MUST generate if no GUA around.
>

I don't understand [and I'm not sure I like seeing it] this clause about
"privacy oriented things" and "trusting firewalling" in the context of RFC
4193 unique local addressing. I suspect there is some conflation with RFC
1918 privacy addressing happening there [which is why I am frowning].

On the topic of the original question, if I were to editorialize here, then
I would want to see something like this:

A) An autonomously generated ULA prefix SHOULD be advertised when no other
delegated prefix is valid.

B) Whenever there is any valid delegated prefix, advertisements for an
existing autonomously generated ULA prefix MUST be deprecated, i.e. updated
with preferred lifetime of zero.

C) A deprecated autonomously generated ULA prefix MUST be withdrawn when it
expires, i.e. its valid time reaches zero.

D) Whenever there is no longer any valid delegated prefix, advertisements
for a previously deprecated autonomously generated ULA prefix MUST be
updated with non-zero preferred lifetime.

The idea here is to make sure IPv6 applications can generally rely on home
network interior routers to forward traffic among the multiple links in the
home, regardless of whether any first-mile Internet services are
provisioned, configured and operational, i.e. there shall always be at
least one preferred global scope network prefix, and there shall be an
autonomously generated local prefix available as a last resort whenever
there are no valid delegated prefixes.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 14:31:26 -0500

On Oct 14, 2014, at 2:19 PM, James Woodyatt <[email-masked]> wrote:
> On the topic of the original question, if I were to editorialize here, then I would want to see something like this:

I get that you have an opinion on this, but you haven't actually stated any argument to support what you think we should do.   And there are some implications in what you are saying that I don't think are necessary.

> A) An autonomously generated ULA prefix SHOULD be advertised when no other delegated prefix is valid.

OK, although underspecified.

> B) Whenever there is any valid delegated prefix, advertisements for an existing autonomously generated ULA prefix MUST be deprecated, i.e. updated with preferred lifetime of zero.

Why?   What problem does this solve?   Given that it's going to mean additional work, there should be some benefit to doing it.

> C) A deprecated autonomously generated ULA prefix MUST be withdrawn when it expires, i.e. its valid time reaches zero.

Okay, given that a prefix expires, it should be withdrawn, whether it's a ULA or a GUA.

> D) Whenever there is no longer any valid delegated prefix, advertisements for a previously deprecated autonomously generated ULA prefix MUST be updated with non-zero preferred lifetime.

OK, but seems like unnecessary work.   You're essentially recapitulating the brokenness of IPv4 zeroconf.

> The idea here is to make sure IPv6 applications can generally rely on home network interior routers to forward traffic among the multiple links in the home, regardless of whether any first-mile Internet services are provisioned, configured and operational, i.e. there shall always be at least one preferred global scope network prefix, and there shall be an autonomously generated local prefix available as a last resort whenever there are no valid delegated prefixes.

This is where I am just completely puzzled.   We talked about this previously.   I thought the idea was that the homenet ULA should converge: that there should only be one, ultimately, and that when there are two, routing should still work.  You are stating this as if the ULAs are per-subnet of a homenet, and that routing across homenet routers using ULAs isn't supported.

If you really think that's how this should work, I can see why you want to deprecate them.   But that's not how they should work.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Oct 2014 08:44:21 +1300

> Why?   What problem does this solve?   Given that it's going to mean additional work, there should be some benefit to doing it.

At a stroke this would destroy the main advantage of ULAs - namely,
invariant addresses for internal traffic. IPv6 assumes multiple
simultaneous addresses; there is no reason whatever to artificially
prevent use of ULAs alongside GUAs.

   Brian

---

From: James Woodyatt <[email-masked]>
Date: Tue, 14 Oct 2014 14:31:08 -0700

On Tue, Oct 14, 2014 at 12:31 PM, Ted Lemon <[email-masked]> wrote:

> [...]
> This is where I am just completely puzzled.   We talked about this
> previously.   I thought the idea was that the homenet ULA should converge:
> that there should only be one, ultimately [...]

This is exactly what I'm trying to surface in my earlier comments about
I-D.ietf-homenet-prefix-delegation. That idea needs clarification if we're
going to interoperate with network layers like Thread which have their ULA
prefix that it would be good to advertise in HOMENET domains as a delegated
prefix.

If the idea is to minimize the need for a HOMENET autonomously generated
ULA prefix, then it should only be advertised when not other ULA prefix is
available and it should be deprecated and allowed to expire when it isn't
needed.  If on the other hand, we do not see a need to limit the number of
ULA prefixes advertised into the HOMENET domain, then a persistent one
should be generated when the network is commissioned by its first leader,
and it should always be advertised thereafter whether a first-mile service
is operational or not, and regardless whether the initiating leader leaves
the network.  (There is a problem with the latter case, which is that some
legacy host operating systems are still broken in an environment like that,
and it would be helpful to mitigate such brokenness. The former case
doesn't have that problem.  There is also the exception that arises when
two networks with different ULA prefixes are joined— now you have one
network, with two ULA prefixes, neither of which can ever be allowed to
expire.)

On Tue, Oct 14, 2014 at 12:44 PM, Brian E Carpenter <
[email-masked]> wrote:

>
> At a stroke this would destroy the main advantage of ULAs -
> namely, invariant addresses for internal traffic. IPv6 assumes
> multiple simultaneous addresses; there is no reason whatever to
> artificially prevent use of ULAs alongside GUAs.
>

p1. I don't want to prevent the use of ULAs alongside GUAs. Indeed, I need
for this to be preserved, and I'm very concerned about requirement language
that would seem to interfere with that.

p2. While I'm in agreement there is a benefit in a guarantee for hosts on
home networks that they will always have valid addresses in the interior
routing domain, I'm not sure I can agree that the main reason to use a ULA
prefix is to encourage the supposition that a HOMENET generated ULA is more
stable and persistent than any GUA assigned by a first-mile service. I
suppose if the working group has already argued that to death, and
concluded that stable persistent addressing solves a problem that real
people are actually facing, then it's not worth rehashing that discussion.

If we're going to go with HOMENET always generating a ULA prefix at network
commissioning time and persisting for the life of the network, then I'm
going to need to understand better how we're handling network joins and
splits.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 16:35:26 -0500

On Oct 14, 2014, at 4:31 PM, James Woodyatt <[email-masked]> wrote:
> There is also the exception that arises when two networks with different ULA prefixes are joined— now you have one network, with two ULA prefixes, neither of which can ever be allowed to expire.)

When we talked about this previously, I think the idea was that when two networks with two sets of ULA prefixes merge, you deprecate one of them.   And then, as you alluded to later in your message, the question is what "you" is.   Presumably this is something HNCP would have to take care of.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 14 Oct 2014 14:40:36 -0700

On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon <[email-masked]> wrote:

>
> When we talked about this previously, I think the idea was that when two
> networks with two sets of ULA prefixes merge, you deprecate one of them.
> [...]
>

Naturally, you deprecate one of them, but my concern is that they never
expire if the objective is for a ULA prefix to be invariant. So how many
times can a network join with others before it runs out of space for
deprecated and redundant but unexpired and invariant ULA prefixes?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 16:49:35 -0500

On Oct 14, 2014, at 4:40 PM, James Woodyatt <[email-masked]> wrote:
> Naturally, you deprecate one of them, but my concern is that they never expire if the objective is for a ULA prefix to be invariant. So how many times can a network join with others before it runs out of space for deprecated and redundant but unexpired and invariant ULA prefixes?

I don't think the objective is for the ULA prefix to be invariant.   It's for the availability of a ULA prefix to be dependable, and for flash renumbering to be avoided whenever possible.   So there's no problem with deprecating a ULA when you have two, and no need for the ULA to remain stable over long periods of time.

The reason to want there to always be a ULA is that if you use a GUA as a ULA, the life cycle of your home network numbering is out of your control, and in the hands of whoever gave you the GUA.   That's the only thing I think the ULA prefix has to do on a homenet: provide you with dependable, graceful homenet-local numbering.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 14 Oct 2014 15:14:37 -0700

On Tue, Oct 14, 2014 at 2:49 PM, Ted Lemon <[email-masked]> wrote:

>
> I don't think the objective is for the ULA prefix to be invariant.   It's
> for the availability of a ULA prefix to be dependable, and for flash
> renumbering to be avoided whenever possible.   So there's no problem with
> deprecating a ULA when you have two, and no need for the ULA to remain
> stable over long periods of time.
>

But there is a problem with only deprecating prefixes without expiring
them. If they never expire, then they accumulate without limit within
existing networks as they join with newly commissioned networks over the
course of their lifetimes.

The reason to want there to always be a ULA is that if you use a GUA as a
> ULA, the life cycle of your home network numbering is out of your control,
> and in the hands of whoever gave you the GUA. That's the only thing I think
> the ULA prefix has to do on a homenet: provide you with dependable,
> graceful homenet-local numbering.
>

So what's the problem? My language above ensures that home network hosts
always have at least one gracefully renumbered IPv6 address routable
throughout the entire network. If we need a further guarantee that hosts
always have an *invariant* address— which is an objective you've said above
that you think we don't actually have— only then are we faced with the
problem of prefix accumulation through network joins, which is a problem
I'm not sure we know how to solve effectively. My proposal avoids that
trouble.

--

To answer a previous question: I would say the reason I thought it worth
expressly zeroing the preferred lifetime on the locally generate ULA prefix
when another prefix is advertised is to expedite the transition to
preferring any delegated ULA prefix over the locally generated one.
Admittedly this is perhaps not worth the effort, and I won't argue further
for it.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 17:32:01 -0500

On Oct 14, 2014, at 5:14 PM, James Woodyatt <[email-masked]> wrote:
> But there is a problem with only deprecating prefixes without expiring them. If they never expire, then they accumulate without limit within existing networks as they join with newly commissioned networks over the course of their lifetimes.

Ah, sorry, I didn't mean to say that we deprecate them but don't ever get rid of them.   I think once a deprecated ULA has expired, it should be gc'd.   If the homenet is partitioned, the two options are for the partitions to continue using one ULA and try to keep prefixes stable, in anticipation of the partition being healed later, or for both partitions to switch to new ULAs, or for one homenet router to "own" the ULA and get to keep it for use in whichever partition it winds up in, while the other partition has to choose a new ULA.

Personally I think keeping the ULA stable across partitions is preferable, but I'm not sure it's possible to do it without the risk of flash renumbering.

> So what's the problem? My language above ensures that home network hosts always have at least one gracefully renumbered IPv6 address routable throughout the entire network. If we need a further guarantee that hosts always have an *invariant* address— which is an objective you've said above that you think we don't actually have— only then are we faced with the problem of prefix accumulation through network joins, which is a problem I'm not sure we know how to solve effectively. My proposal avoids that trouble.

I understood your language to be trying to get rid of all ULAs if any GUAs are present.   Did I misunderstand?

---

From: Dave Taht <[email-masked]>
Date: Tue, 14 Oct 2014 16:40:50 -0700

> deprecated and redundant but unexpired and invariant ULA prefixes?

2^56 times I think...

... but the network itself would expire long before then. :)

What's a more reasonable bound? What's the bound before a given
network would collapse from multicast joins alone?

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Oct 2014 20:00:09 -0400

> other delegated prefix is valid.

I think most people agree about this.

    > existing autonomously generated ULA prefix MUST be deprecated,
    > i.e. updated with preferred lifetime of zero.

I'm not sure why this is a good thing.

    > D) Whenever there is no longer any valid delegated prefix,
    > advertisements for a previously deprecated autonomously generated ULA
    > prefix MUST be updated with non-zero preferred lifetime.

Does it have to be the same ULA?

Consider the case where there are multiple gateways, which can not see
whether the other gateways have GUA or not.
Given that, how can anyone know when to withdraw the ULA?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 19:09:26 -0500

On Oct 14, 2014, at 6:05 PM, James Woodyatt <[email-masked]> wrote:
> p2. I do think a locally generated ULA prefix should not be renewed, i.e. it should be allowed to expire, when there is *any* prefix delegated [GUA or ULA].  Also when additional locally generated ULA prefixes are present after a network join. I recognize this view may be in a vocal minority, and I can live with a more persistent locally-generated ULA prefix so long as there is a standard scheme for dealing with prefix accumulation after network joins.

Minority versus majority isn't the issue.

The reason I object to this is that you have control over the lifetime of your ULA, but not over the lifetime of your GUA.   Do we really want a forced flash renumbering from the ISP to break connections on the local network?

---

From: James Woodyatt <[email-masked]>
Date: Tue, 14 Oct 2014 17:09:36 -0700

Consider a hypothetical router that has the regular automatic default
behavior of commissioning a new standalone network while discovering any
existing networks that it already possesses the credentials to join. Now
consider what happens when devices of this category are continually losing
and regaining their connectivity with the rest of the wireless network in
the home. Let's imagine this happens many times per hour. How many days
does it take before all your constrained-resource hosts have no space left
in their route tables for all the deprecated but still valid ULA prefixes?

I suggest it will not take very long at all. Any reasonably implemented
host will be dropping them before they expire anyway, but hosts will be
forced to use a crude heuristic to decide which prefix to expire first,
e.g. lowest valid lifetime then first-in first-out?  Routers are more
knowledgeable about which prefixes are the locally generated ones and which
ones are delegated.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 20:17:53 -0500

On Oct 14, 2014, at 7:09 PM, James Woodyatt <[email-masked]> wrote:
> Consider a hypothetical router that has the regular automatic default behavior of commissioning a new standalone network while discovering any existing networks that it already possesses the credentials to join. Now consider what happens when devices of this category are continually losing and regaining their connectivity with the rest of the wireless network in the home. Let's imagine this happens many times per hour. How many days does it take before all your constrained-resource hosts have no space left in their route tables for all the deprecated but still valid ULA prefixes?

I think you are arguing that the solution needs to prevent this happening.   I agree.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Oct 2014 06:58:11 +0200 (CEST)

On Tue, 14 Oct 2014, Ted Lemon wrote:

> Right.  This is IPv4.  In IPv4 we typically use a NAT on the local wire, 
> so we get the effect we are trying to achieve either by retaining stale 
> GUAs or using ULAs on the local wire in homenets.  IPv4 also does not 
> provide graceful renumbering, so if the ISP wants to force an IPv4 
> address change, they have no choice but to do flash renumbering.  The UX 
> is not good.

Just to be clear, I am against flash renumbering, I want to see 
renumbering done with 30-60 minute overlap at least. I however do see that 
we really really need to support renumbering. One way of making sure that 
support works is to expose applications to frequent renumbering.

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 15 Oct 2014 11:02:26 +0300

On 15.10.2014, at 7.58, Mikael Abrahamsson <[email-masked]> wrote:
> Just to be clear, I am against flash renumbering, I want to see renumbering done with 30-60 minute overlap at least. I however do see that we really really need to support renumbering. One way of making sure that support works is to expose applications to frequent renumbering.

So essentially IPv6 home network would be ultimately worse platform than IPv4 one?

Because no matter what ISP does, my IPv4 prefixes in my home _are_ stable. And IPv6 ones too (thanks to using statically configured tunnel, cough).

I would argue that flash renumbering is bad too, but I would also claim that overlap of less than session lifetime is not acceptable. .. some of my session lifetimes are in days (single TCP session). Or are we planning to ultimately deprecate TCP and advocate something else? MPTCP? Yes, I know typical home user has just HTTP requests, but I am not fond of idea of turning the network to short-lived-connections only model just because it seems currently the most popular way to do things.

Every time I hear about ISP-forced customer renumberings, the more I start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.

Cheers,

-Markus

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Oct 2014 11:48:49 +0200 (CEST)

On Wed, 15 Oct 2014, Markus Stenberg wrote:

> Every time I hear about ISP-forced customer renumberings, the more I 
> start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.

For me this isn't just about ISP-forced customer renumberings, but to also 
handle power outages, equipment malfunction (so you lose your lease), 
equipment change, ISP change, and all other things that today will make 
you change the IPv4 address a few times a year or something.

I believe we should use SHIM6, MP-TCP, "mosh" and other similar techniques 
to make sure that we can move sessions around when doing renumbering.

IPv6 has the infrastructure on L3 to handle renumbering gracefully, now we 
just need L4 and applications to get with the program as well. I would 
really like to see us go in the way of IP addresses not being the single 
anchorpoint of all communication, we need to make sure that we have other 
mechanisms such as L4 protocols being "agile" when it comes to IP address 
change over time, and also having DNS or other mechanism being able to be 
updated with information over time to enable this mobility.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 15 Oct 2014 13:14:24 +0200

Hi James,

> Consider a hypothetical router that has the regular automatic default behavior of commissioning a new standalone network while discovering any existing networks that it already possesses the creden…

Does it have to be a *new* standalone network (ULA prefix)? The router could just generate a ULA prefix once and reuse it whenever it needs to, right? Generating a new prefix on every connect/disconnect would indeed cause a mess...

Cheers,
Sander

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 09:48:53 -0500

>> Just to be clear, I am against flash renumbering, I want to see renumbering done with 30-60 minute overlap at least. I however do see that we really really need to support renumbering. One way of…

We do need to support renumbering.   For graceful renumbering, most common applications already support it with no problem, although 30-60 minutes is too short, because that will break for example a movie stream.   But a 30-60 minute overlap will work fine for web browsing and nearly all applications a typical end-user uses other than long movies.

There are applications that will fail because they bind to an address and have no error recovery mechanism for when the address goes away, but AFAIK these are quite uncommon.   So really you are proposing a very expensive cure for an insignificant problem.

> Every time I hear about ISP-forced customer renumberings, the more I start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.

I'm not sure I'd go that far, but it's definitely a really strong SHOULD.

---

From: Gert Doering <[email-masked]>
Date: Wed, 15 Oct 2014 16:52:34 +0200

Hi,

> updated with information over time to enable this mobility.

This.

(And yes, stable IPv6 addresses are so much more convenient, you can put
them into /etc/hosts and all that.  Wait, /etc/hosts got deprecated?  When
did that happen?  Right :-) ).

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 15 Oct 2014 16:58:43 +0200

Hi,

> it is just too complicated.

Isn't the main thing that "other people are just plain not interested in 
doing so in the first place"...?

Please understand that there are way more non-geeks out there that have
no interest in computers except "use them" than there are geeks who care
about IP addressing.  *Our* job is to make it work for *them*, without
forcing our world view on them ("they need to be able to put a static
IP address in DNS!" - no, my mom doesn't need to do that)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 15 Oct 2014 17:04:22 +0200

Hi,

On Tue, Oct 14, 2014 at 11:21:12AM -0500, Ted Lemon wrote:
> This isn't a helpful response, Gert.   If you are right, you can
> explain the reason that you are right.   You don't have to accuse
> the people you are talking to of not thinking this through.

I explained my reasoning.  Multiple times.  Here and on other lists.  Again
and again.  And I spend a lot of time testing things, running against walls,
and telling people what needs to be improved to make it work.  Since years.

But I still run headlong into the typical geek response "I do things in
my network that are not compatible to this" - and, well, so do I, but
that is a completely irrelevant point of view when talking about homenets
that are used by millions of non-geeks plus a few IETF geeks.

*This* is the widening of horizon that is needed for meaningful contribution
to this discussion.  "I'll just get me a tunnel" is not.

Gert Doering
        -- NetMaster

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Oct 2014 18:21:11 +0300

Markus Stenberg writes:
> Because no matter what ISP does, my IPv4 prefixes in my home _are_
> stable. And IPv6 ones too (thanks to using statically configured
> tunnel, cough).

When we defined a recommendation for ISPs in Finland for IPv6, we
suggested that ISPs should always give same prefix to same customer,
and when giving out the addresses, they should set the preferred
lifetime to 7 days, and valid lifetime to be 30 days, i.e. even if the
network connection is down for several weeks, the IPv6 addresses
inside the house are still usable. Of course if there is power outage
and every device in the network looses power, and there is no network
connectivity when they come back up, that usually means there is no
valid IPv6 addresses anymore, unless they are statically configured
somewhere (or stored to the stable storage by the routers). 

> I would argue that flash renumbering is bad too, but I would also
> claim that overlap of less than session lifetime is not acceptable.
> .. some of my session lifetimes are in days (single TCP session). Or
> are we planning to ultimately deprecate TCP and advocate something
> else? MPTCP? Yes, I know typical home user has just HTTP requests,
> but I am not fond of idea of turning the network to
> short-lived-connections only model just because it seems currently
> the most popular way to do things. 

My ssh connections are usually up and running for ever. They only go
down when I update my firewall, there is network problems, or our
company firewall is reset for some reason. Usually that means the ssh
connection is up for few months... I would be very unhappy I would
need to restart my TCP connections every month, so any ISP giving me
such notwork, would not be consider as proper ISP, and I would
immediately switch to another ISP if my ISP starts doing things that
break my connections. 

> start to think that 1+ ULA prefixes per home is a MUST, not a

Most of my long lived connections are from my office to my home, or
from my home to my summer house. I.e there are some connections inside
my home which are longlived, but also the global IP-addresses need to
be stable enough for my use cases, i.e. ULA would not help me that
much. 
-- 
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 10:34:17 -0500

On Oct 15, 2014, at 10:04 AM, Gert Doering <[email-masked]> wrote:
> and again.

When you repeat yourself again and again, people stop listening to you.   There was a consensus call done on this, and the architecture document contains the results of that consensus.   If you have some additional objection to raise, you should raise it, but I'm very sorry, you do have to show your work.   You can't just make assertions about what you think is true, and expect your opinion to count in the consensus call.   We don't vote in the IETF, so opinions just don't make sense in that context.

In particular, you appear to be arguing as if ULAs and GUAs are treated identically by IPv6 stacks, but they are not.   So while I agree that there is a real problem making this work for multi-homed homenets (a problem, by the way, which homenet has decided to try to solve), this is completely orthogonal to the question of whether we should use ULAs in the homenet.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 15 Oct 2014 17:47:02 +0200

>IP address in DNS!" - no, my mom doesn't need to do that)

Our current 'world view' is that companies get stable addresses. Consumers get
crap.

We invent complicated stuff like dynamically turning ULA on and off that nobody
else uses. We force renumbering in the name of privacy, etc.

We start by giving consumers a swamp and then try to build something on top of
it.

We make choices, like the DNS server has to be in the router, because only the
router knows about the current prefix, etc.

---

From: Gert Doering <[email-masked]>
Date: Wed, 15 Oct 2014 17:48:41 +0200

Hi,

On Wed, Oct 15, 2014 at 10:34:17AM -0500, Ted Lemon wrote:
> When you repeat yourself again and again, people stop listening to you.   

Well, there are some people in the IETF that really don't know how to
listen, but that's not particular to *me*...

Some other people seem to understand what I say, and agree with it, or
sometimes disagree with the particulars, based on practical experience,
or on understanding my points.

> There was a consensus call done on this, and the architecture document 
> contains the results of that consensus.   If you have some additional 
> objection to raise, you should raise it, but I'm very sorry, you do 
> have to show your work.   You can't just make assertions about what you 
> think is true, and expect your opinion to count in the consensus call.   
> We don't vote in the IETF, so opinions just don't make sense in that context.

Huh, what?  Maybe I have problems listening as well.  I fully fail to
see how this paragraph relates to anything I have stated in the thread
- which strayed from the subject of "ULA or not" quite a bit to "what
happens out there in the real world".

> In particular, you appear to be arguing as if ULAs and GUAs are
> treated identically by IPv6 stacks, but they are not.   

This was not my point, and isn't, as it is not relevant.

My point in this discussion is that applications need to handle changing
addresses under their feet, while the application is running, and in
quite a number of cases, while a session is established (to pick
up the "I ssh to my summer house and leave that session running for
months" example - well, add homenet multihoming to the mix, and you 
really want MPTCP, shim6 or something like mosh to handle "oh, and 
I really want my SSH session to stay up even if one of my ISPs goes 
down for a few days").

This is fully independent of the question "do we add ULA to the mix or 
not", as ULAs are irrelevant for communication to partners outside the 
home (as long as nobody puts ULAs into global DNS).

As far as "SHOULD or MUST", I don't have a strong opinion either way,
as local communication is just a special case of global communication - and
if global comms can handle changing addresses, getting that right for
local comms is *so* much easier.  My homenet test setup works nicely
with two ISPs, four partially-meshed HNCP routers, and no ULAs at all, 
but having another address won't make much difference...

> So while I
> agree that there is a real problem making this work for multi-homed
> homenets (a problem, by the way, which homenet has decided to try
> to solve), this is completely orthogonal to the question of whether
> we should use ULAs in the homenet.

Indeed.

Could you remind me what your point was?

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 15 Oct 2014 17:58:26 +0200

Hi,

> Our current 'world view' is that companies get stable addresses. Consumers get

Well, "we" are not calling it "crap", we call it "make it work and scale",
but otherwise, I agree that there is a difference between "large companies"
and "SOHO companies and end users" (the homenet approach works perfectly
well for a typical SOHO network - a few PCs, a printer, some file storage,
mail server hosted "as a service with filtering" elsewhere, etc.) - and
that's the numbers of each.

> else uses. We force renumbering in the name of privacy, etc.

Thing is, we invented DNS, so people do not have to rely on fixed addresses
in their /etc/hosts.  Then people invented mDNS so inside the home, nobody
would have to understand how to handle a DNS zone.

So you think DNS and mDNS should have never done either, because it paves 
the way down the hill?

Unless you can come up with a routing architecture that can handle stable
end users addresses (as in "whatever the customer does, wherever he moves
his ISP connection to, and how many ISPs he's going to have") for all
the end users out there, your world view is not actually very helpful.

DNS, mDNS, SIP register, and such stuff exist that nobody has to rely on 
IP addresses never changing, and that people can focus on useful labels
instead (like, "hostnames" or "telephone numbers", which in itself are
only useful because phone books exist to map a name to a number and
traditional phones could not call names).

Gert Doering
        -- NetMaster

---

From: Ralph Droms <[email-masked]>
Date: Wed, 15 Oct 2014 12:00:52 -0400

Ted - you wrote something that surprised me (in line)...

On Oct 15, 2014, at 11:34 AM 10/15/14, Ted Lemon <[email-masked]> wrote:

> In particular, you appear to be arguing as if ULAs and GUAs are treated identically by IPv6 stacks, but they are not.

Really?  In what way are they not treated identically by IPv6 stacks?

- Ralph

>    So while I agree that there is a real problem making this work for multi-homed homenets (a problem, by the way, which homenet has decided to try to solve), this is completely orthogonal to the question of whether we should use ULAs in the homenet.
>

---

From: Sander Steffann <[email-masked]>
Date: Wed, 15 Oct 2014 18:27:45 +0200

Hi Ralph,

> Really?  In what way are they not treated identically by IPv6 stacks?

ULA space does have a separate entry in the policy table of RFC 6724 (https://tools.ietf.org/html/rfc6724#section-2.1)

Chees,
Sander

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 11:28:01 -0500

> Could you remind me what your point was?

My point was that homenets should have ULAs, and should not use GUAs for local communication, because GUAs can be flash renumbered, and the use of them on the local wire has the potential to cause disruptions on the local wire that could be prevented by using ULAs.   And that there is no real downside to having ULAs on the local network.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Oct 2014 09:35:20 -0700

> My point was that homenets should have ULAs, and should not use GUAs for local communication, because GUAs can be flash renumbered, and the use of them on the local wire has the potential to cause…

What about when my device is wandering back and forth between my ap and 
my neighbor's?

Mike

---

From: Sander Steffann <[email-masked]>
Date: Wed, 15 Oct 2014 18:44:59 +0200

Hi Ted,

> My point was that homenets should have ULAs, and should not use GUAs for local communication, because GUAs can be flash renumbered, and the use of them on the local wire has the potential to cause…

I am starting to agree.

I think we should see if we can come up with a good way to manage the ULAs when splitting/merging/etc networks though. If we can't find something good for that then the solution might be worse than the original problem.

Cheers,
Sander

---

From: James Woodyatt <[email-masked]>
Date: Wed, 15 Oct 2014 10:29:50 -0700

On Wed, Oct 15, 2014 at 4:14 AM, Sander Steffann <[email-masked]> wrote:

> [I wrote:]

> Does it have to be a *new* standalone network (ULA prefix)? The router
> could just generate a ULA prefix once and reuse it whenever it needs to,
> right? Generating a new prefix on every connect/disconnect would indeed
> cause a mess...
>

No, the router can't do that. Consider that ULA prefixes may be advertised
through tunnels to one or more exterior private routing domains that
communicate with multiple home networks simultaneously. Because the locally
generated ULA prefix is copied from the commissioning router to all the
other routers in the home network, a router must therefore generate a new
ULA prefix at every network commissioning to preserve the property that ULA
prefixes are statistically unlikely to collide. Otherwise, every time a
single device is used to commission a new network with the same ULA prefix,
that prefix will collide with existing previously commissioned networks at
the exterior domain gateway.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 12:50:43 -0500

On Oct 15, 2014, at 11:35 AM, Michael Thomas <[email-masked]> wrote:
> What about when my device is wandering back and forth between my ap and my neighbor's?

I don't think that's a problem that we're scoped to solve, unless your and your neighbors' homenets are a single homenet, in which case life is good.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Oct 2014 11:34:40 -0700

> I don't think that's a problem that we're scoped to solve, unless your and your neighbors' homenets are a single homenet, in which case life is good.

I'm just pushing back that ULA's aren't necessarily without problems. 
It's easy to see how they
can cause weird connectivity breaks across administrative domains. 
Though it's obviously not
just homenets, wandering back and forth between neighboring networks is 
probably more likely
with homenets, IMO.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 13:57:21 -0500

On Oct 15, 2014, at 1:34 PM, Michael Thomas <[email-masked]> wrote:
> I'm just pushing back that ULA's aren't necessarily without problems. It's easy to see how they
> can cause weird connectivity breaks across administrative domains. Though it's obviously not
> just homenets, wandering back and forth between neighboring networks is probably more likely
> with homenets, IMO.

Fair enough, but this is like answering a question about whether butter is good with bread by suggesting that people with Celiac's should avoid it.   True, but not germane to the discussion.   Ideally your device should not be hopping back and forth between networks.   If it does, there is no work for homenet to do to address the problems that arise.

There has been talk about working on some formal presentation layer that could be used to address these problems, but that is not something that Homenet is chartered to work on, nor is this really where the right people congregate.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Oct 2014 08:14:03 +1300

On 15/10/2014 22:48, Mikael Abrahamsson wrote:
> For me this isn't just about ISP-forced customer renumberings, but to
> also handle power outages, equipment malfunction (so you lose your
> lease), equipment change, ISP change, and all other things that today
> will make you change the IPv4 address a few times a year or something.
> 
> I believe we should use SHIM6, MP-TCP, "mosh" and other similar
> techniques to make sure that we can move sessions around when doing
> renumbering.

Shim6 is unfortunately broken, until the day when all middleboxes
allow the extension headers to pass, which is far from true today.
MPTCP only works for TCP. Mosh aparently only works for SSH. Happy
eyeballs only works for browsers. This is far from a closed topic.

> IPv6 has the infrastructure on L3 to handle renumbering gracefully, 

That's unclear to me. Anyway, it might be worth reviewing the
gap analysis at http://tools.ietf.org/html/rfc7010
(which was mainly aimed at enterprises) to see how it looks
for homenets.

> now
> we just need L4 and applications to get with the program as well. I
> would really like to see us go in the way of IP addresses not being the
> single anchorpoint of all communication, we need to make sure that we
> have other mechanisms such as L4 protocols being "agile" when it comes
> to IP address change over time, and also having DNS or other mechanism
> being able to be updated with information over time to enable this
> mobility.

"Just"?? Anyway, see my rant in CCR:
http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Oct 2014 13:01:43 -0700

On 10/15/14, 11:57 AM, Ted Lemon wrote:
>
> Ideally your device should not be hopping back and forth between networks.   If it does, there is no work for homenet to do to address the problems that arise.
>

See, I don't find that ideal at all. If I'm swinging around on my 
backyard trapeze watching
the flying wallendas instructional video from my home jukebox, I really 
don't want to have
my network break connectivity because I happened to switch to my 
neighbor's wifi and I
was using a ULA when I could have kept connectivity with a GUA.

As far as homenet goes, i'd rather it not bake in any assumptions about 
ULA's beyond what
is already there.

Mike, ::splat::

---

From: James Woodyatt <[email-masked]>
Date: Wed, 15 Oct 2014 13:28:26 -0700

On Wed, Oct 15, 2014 at 1:01 PM, Michael Thomas <[email-masked]> wrote:

> [...] I really don't want to have my network break connectivity because I
> happened to switch to my neighbor's wifi and I was using a ULA when I could
> have kept connectivity with a GUA.
>

Except REC-49 in RFC 6092 does not recommend transparency as the default
operating mode of residential gateway firewalls. And very few in actual
deployments are transparent by default. So this can't be expected to work
even with GUA instead of ULA.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Oct 2014 14:15:22 -0700

On 10/15/14, 1:28 PM, James Woodyatt wrote:
> On Wed, Oct 15, 2014 at 1:01 PM, Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [...] I really don't want to have my network break connectivity
>     because I happened to switch to my neighbor's wifi and I was using
>     a ULA when I could have kept connectivity with a GUA.
>
>
> Except REC-49 in RFC 6092 does not recommend transparency as the 
> default operating mode of residential gateway firewalls. And very few 
> in actual deployments are transparent by default. So this can't be 
> expected to work even with GUA instead of ULA.
>

If I want to have internet available servers/services available from my 
home network, that's
my business, not rfc 6092's. This is a feature, not a bug and frankly 
the horse has long departed
the barn with things like, oh say, wifi cams, security systems, and dare 
I say internet enabled
thermostats.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 17:49:36 -0500

On Oct 15, 2014, at 3:01 PM, Michael Thomas <[email-masked]> wrote:
> See, I don't find that ideal at all. If I'm swinging around on my backyard trapeze watching
> the flying wallendas instructional video from my home jukebox, I really don't want to have
> my network break connectivity because I happened to switch to my neighbor's wifi and I

This is simply a non-sequitur.   It has nothing to do with homenet.   It has to do with how the stack works on your home, and what the propagation of radio waves looks like in your back yard.   The assumption that you will be able to access your jukebox over your neighbor's wifi contains packed in it so much new protocol work we could fork several working groups to handle it.

> As far as homenet goes, i'd rather it not bake in any assumptions about ULA's beyond what
> is already there.

I hear you.   But why should the working group care what you prefer?   I don't say that to be dismissive, but to encourage you to give a reason that isn't just an opinion.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Oct 2014 15:57:53 -0700

> This is simply a non-sequitur.   It has nothing to do with homenet.   It has to do with how the stack works on your home, and what the propagation of radio waves looks like in your back yard.   The…
If I use a GUA to my jukebox, the routing will just work regardless of which
AP I'm currently connected to. With ULA's, not so much. That's hardly a 
non-sequitur.

ULA's with mobility are very problematic IMO. I'm a lot more likely to 
wander onto my
neighbor's home network than to suffer a flash renumbering from one of 
my providers.
Mobility considerations aren't a distant future, they're now.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 18:06:27 -0500

On Oct 15, 2014, at 5:57 PM, Michael Thomas <[email-masked]> wrote:
> AP I'm currently connected to. With ULA's, not so much. That's hardly a non-sequitur.

You appear to have some misconceptions both about how IP routing works and how streaming works.

Suppose you are connected to your homenet.   You are streaming video from your jukebox using your ULA.   Now your device switches to your neighbor's Wifi, which is advertising a different GUA and a different ULA.   At this point your device does a flash renumber because it realizes it's no longer on the same network, and that the prefixes it had are no longer valid.

At this point, your application should get a notification from the stack that the connection has broken, at which point it should reconnect to your jukebox.  Supposing that your jukebox is reachable from the outside, the ULA that your neighbor's WiFi is advertising won't match the ULA your jukebox is advertising, so your device will attempt to reconnect using a GUA, not a ULA.

So whether you have a ULA on your homenet or not, two things will be true.  First, if your app isn't smart enough to re-connect, your stream will die.   Second, if it is smart enough, then it will succeed in reconnecting, whether you have a ULA configured on your homenet or not.

This is why I say that the concern you have raised is a non-sequitur.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Oct 2014 16:15:31 -0700

> Suppose you are connected to your homenet.   You are streaming video from your jukebox using your ULA.   Now your device switches to your neighbor's Wifi, which is advertising a different GUA and a…

I'm talking about the server, not the client. ULA == unreachable on my 
neighbor's wifi.
Don't want assumptions that servers on my home network will only be 
reachable by ULA's.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 18:21:17 -0500

On Oct 15, 2014, at 6:15 PM, Michael Thomas <[email-masked]> wrote:
> I'm talking about the server, not the client. ULA == unreachable on my neighbor's wifi.
> Don't want assumptions that servers on my home network will only be reachable by ULA's.

If a GUA is being advertised on your homenet, presumably your server will have both a GUA and a ULA.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Oct 2014 10:26:19 +1100

In message <[email-masked]>, Michael Thomas writes:
> > This is simply a non-sequitur.   It has nothing to do with homenet.   It ha
> s to do with how the stack works on your home, and what the propagation of ra
> dio waves looks like in your back yard.   The assumption that you will be abl
> e to access your jukebox over your neighbor's wifi contains packed in it so m
> uch new protocol work we could fork several working groups to handle it.

And when you move onto your neighbour's net you will be switching
ssid's and even if you open up your router to allow the traffic in
the BCP 38 filtering should be blocking your packets leaving your
neighbors router.

Now if you want to set up a tunnel between you and your neighbour
to make this work that's fine.  If you don't you will have a different
set of addresses on either network including ULA addresses.  Unless
you have really old stacks your device will pick the new GUA first
to talk to your jukebox when you are on your neighbor's network and
the ULA to talk to it when you are on your own.

Even if you have a old stack, if the application has taken the
lessons from Happy Eyeballs and made it more generic by decreasing
the time before starting the next connection attempt to 100's if
milliseconds when you have multiple server addresses, the resulting
HE algorithms would have fixed the issue for you when it fast failed
to the GUA of the jukebox after changing ssids.  Longest match would
result in the new GUA being used rather than the new ULA.

I tried hard to get the IETF to listen to this for HE.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Oct 2014 14:39:51 +1300

On 16/10/2014 11:57, Michael Thomas wrote:
>> This is simply a non-sequitur.   It has nothing to do with homenet.  
>> It has to do with how the stack works on your home, and what the
>> propagation of radio waves looks like in your back yard.   The
>> assumption that you will be able to access your jukebox over your
>> neighbor's wifi contains packed in it so much new protocol work we
>> could fork several working groups to handle it.

Sure, but that is *exactly* why you might want your personal
printer or your personal porn server or whatever to have an
address that can never be accessible from your neighbour's
yard. (Yes, I know that isn't "Security" with a big S but actually
it's part of a secure environment.)

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Oct 2014 09:14:40 +0200 (CEST)

On Wed, 15 Oct 2014, Ted Lemon wrote:

> minutes is too short, because that will break for example a movie 
> stream.  But a 30-60 minute overlap will work fine for web browsing and 
> nearly all applications a typical end-user uses other than long movies.

I'd say a lot of the "movie" applications will work fine as well because 
a lot of them isn't a single TCP session over long time anyway, but that's 
another story.

What I most worry about is for instance SSH. However, I would like all 
applications to behave like "mosh" does (from a user point of view, not 
necessarily from a protocol point of view), in that an existing session 
can be moved between IPs, regardless if the change is gracefully handed 
over, or "hard" handed over (as in IP goes away, you get different 
connectivity with different IP 2 minutes later, and you can continue). We 
need this for video conferencing, VoIP calls, terminal sessions, basically 
*everything* that lasts more than 10-20 seconds on average.

This is of course not something the average application developer should 
need to handle, they should only need to use an API that says "please keep 
me connected to this DNS name" and then everything should be handled for 
them.

> There are applications that will fail because they bind to an address 
> and have no error recovery mechanism for when the address goes away, but 
> AFAIK these are quite uncommon.  So really you are proposing a very 
> expensive cure for an insignificant problem.

I don't consider the problem insignificant.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Oct 2014 09:18:55 +0200 (CEST)

On Wed, 15 Oct 2014, Tero Kivinen wrote:

> connection is up for few months... I would be very unhappy I would need 
> to restart my TCP connections every month, so any ISP giving me such 
> notwork, would not be consider as proper ISP, and I would immediately 
> switch to another ISP if my ISP starts doing things that break my 
> connections.

I use MOSH. I never really notice when I change IPs because I move from 
wifi to wired to mobile and to a different wifi, it just seamlessly 
connects, usually before I am even able to type my password on my 
computer. I want all applications to behave like this.

Quasi stable addressing makes application developers take the "stable" 
part for granted. Networks go down and come back up again, TCP sessions 
hang due to stateful things in the network losing state etc. This is 
something an application developer needs to handle. If it only happens 2-4 
times per year, they'll blame the network and not their application.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Oct 2014 09:29:53 +0200 (CEST)

On Thu, 16 Oct 2014, Brian E Carpenter wrote:

> Shim6 is unfortunately broken, until the day when all middleboxes allow 
> the extension headers to pass, which is far from true today. MPTCP only 
> works for TCP. Mosh aparently only works for SSH. Happy eyeballs only 
> works for browsers. This is far from a closed topic.

Absolutely, there is a huge amount of work needed in this area. That's why 
I wrote "similar techniques".

> http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf

Yes, I have read it and it's an excellent document I think is very 
valuable.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Oct 2014 10:50:26 +0200

Le 16/10/2014 00:49, Ted Lemon a écrit :
>> backyard trapeze watching the flying wallendas instructional video
>> from my home jukebox, I really don't want to have my network break
>> connectivity because I happened to switch to my neighbor's wifi and
>> I was using a ULA when I could have kept connectivity with a GUA.
>

I agree it has nothing to do with homenet.

It is a problem at work, at airport, in public garden, in the street, at 
the restaurant - in general in every place where WiFi arrived.

It is an entirely WiFi connection management problem.  In Windows it can 
be avoided by unchecking the "Automatically Connect To" attached to that 
WiFi ESSID, or more brutally by removing that undesired profile completely.

Alex

>> As far as homenet goes, i'd rather it not bake in any assumptions
>> about ULA's beyond what is already there.
>
> I hear you.   But why should the working group care what you prefer?
> I don't say that to be dismissive, but to encourage you to give a
> reason that isn't just an opinion.
>
> _______________________________________________ homenet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Oct 2014 10:55:28 +0200

Le 16/10/2014 00:57, Michael Thomas a écrit :
>>> backyard trapeze watching the flying wallendas instructional
>>> video from my home jukebox, I really don't want to have my
>>> network break connectivity because I happened to switch to my
>>> neighbor's wifi and I was using a ULA when I could have kept
>>> connectivity with a GUA.
> If I use a GUA to my jukebox, the routing will just work regardless
> of which AP I'm currently connected to. With ULA's, not so much.
> That's hardly a non-sequitur.
>
> ULA's with mobility are very problematic IMO.

I think this is right, mobility and ULAs may have some issues.

If by mobility we understand Mobile IP then assigning a GUA to HA (or
some form of protocol forwarding from the Box to the HA) only may allow
to then use ULAs for the mobile devices.  The implications of NATv6 may
vary.

> I'm a lot more likely to wander onto my neighbor's home network than
> to suffer a flash renumbering from one of my providers.

Yes and no.  WiFi wandering is completely under the enduser's control.

> Mobility considerations aren't a distant future, they're now.

I agree.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 07:24:55 -0500

On Oct 16, 2014, at 2:14 AM, Mikael Abrahamsson <[email-masked]> wrote:
> What I most worry about is for instance SSH.

Mikael, I think we have strayed sufficiently far off the topic that it is harmful for us to continue discussing it on the homenet mailing list.   I agree with you that better presentation layer support would be a good thing, but it is a thing that is not in homenet's charter.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 21:58:00 +0900

On Wed, Oct 15, 2014 at 12:13 AM, Ted Lemon <[email-masked]> wrote:

> There's no reason to do flash renumbering.

I think you'll find that the reason is that [ hardware manufacturers
support | operators are willing to spend router resources for ] only one
forwarding entry per customer at a time.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 22:10:56 +0900

On Thu, Oct 16, 2014 at 1:28 AM, Ted Lemon <[email-masked]> wrote:

> My point was that homenets should have ULAs, and should not use GUAs for
> local communication, because GUAs can be flash renumbered,

Actually, they can't.

http://tools.ietf.org/html/rfc4862#section-5.5.3 paragraph e) 3.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 22:15:04 +0900

On Thu, Oct 16, 2014 at 8:06 AM, Ted Lemon <[email-masked]> wrote:

> Suppose you are connected to your homenet.   You are streaming video from
> your jukebox using your ULA.   Now your device switches to your neighbor's
> Wifi, which is advertising a different GUA and a different ULA.   At this
> point your device does a flash renumber because it realizes it's no longer
> on the same network, and that the prefixes it had are no longer valid.
>
> At this point, your application should get a notification from the stack
> that the connection has broken, at which point it should reconnect to your
> jukebox.

Ted, you're going in circles here. You've been arguing for many messages
that we should use ULAs because GUAs can be flash renumbered. And now you
provide an example of an event that *is* a flash renumbering, and then
proceed to say that everything will be fine because the application will
reconnect.

Pick one position or the other?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 22:22:03 +0900

On Thu, Oct 16, 2014 at 8:26 AM, Mark Andrews <[email-masked]> wrote:

> Unless you have really old stacks your device will pick the new GUA first to
> talk to your jukebox when you are on your neighbor's network and the ULA
> to talk to it when you are on your own.
>

No, it won't. It will pick GUA->GUA both times.

Per the table in http://tools.ietf.org/html/rfc6724#section-2.1 it will
pick the GUA as a destination address, and per Rule 6, it will choose the
GUA to connect to it.

Which means that if you *want* to force it to use ULA inside the network
and GUA outside, the only scalable option is to use split-tunnel DNS. You
could change the policy table too, but most users won't, unless the
standards change, and major OSes change the policy tables.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Oct 2014 00:33:12 +1100

In message <CAKD1Yr2aLTjEo=7yj+=[email-masked]>, Lorenzo Colitti write
s:
> --20cf303dd7088da2c005058a23d9
> Content-Type: text/plain; charset=UTF-8
> 

Actually it depends on which address has the longest match.  With
old stacks they are both treats as GUA.  ULA has at least 8 bits
in common but may have up to 47 bits in common.  The GUA is likely
to have 16+ bits in common.  There is no guarentee that the old
pair of addresses have been flushed to only leave the GUA.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 08:34:01 -0500

On Oct 16, 2014, at 8:15 AM, Lorenzo Colitti <[email-masked]> wrote:
> Ted, you're going in circles here. You've been arguing for many messages that we should use ULAs because GUAs can be flash renumbered. And now you provide an example of an event that *is* a flash renumbering, and then proceed to say that everything will be fine because the application will reconnect.

No, what I'm saying is that in this case you can't avoid the renumbering issue, so you just have to accept what the application does.   This in no way contradicts my point that flash renumbering is better avoided.

>> My point was that homenets should have ULAs, and should not use GUAs for local communication, because GUAs can be flash renumbered,
>> 
> Actually, they can't.

Yes they can, as you just agreed:

> I think you'll find that the reason is that [ hardware manufacturers support | operators are willing to spend router resources for ] only one forwarding entry per customer at a time.

That seems to me to be begging for trouble.   As a rule routers have too much memory, not too little, so I find this reasoning unconvincing.   Taking a little memory away from the buffer cache to make the forwarding table bigger seems like a really good idea.

> Which means that if you *want* to force it to use ULA inside the network and GUA outside, the only scalable option is to use split-tunnel DNS. You could change the policy table too, but most users won't, unless the standards change, and major OSes change the policy tables.

We have already talked about good reasons for doing split-horizon DNS: you don't really want to advertise all the hosts on the local wire, just the ones you want to be globally-reachable.   And changing the policy table isn't that hard: if we want to have a special policy for the local ULA, we already have a mechanism for doing it that does not require O.S. vendors to hard-code a different policy table nor users to select one manually: stateless DHCPv6.   And for those who consider the use of DHCPv6 déclassé, it will still work without: you just won't be protected from a provider doing flash renumbering.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 16 Oct 2014 13:34:15 +0000

>> Unless you have really old stacks your device will pick the new GUA first to talk to your jukebox when you are on your neighbor's network and the ULA to  talk to it when you are on your own.

> Per the table in http://tools.ietf.org/html/rfc6724#section-2.1 it will pick the GUA as a destination address, and per Rule 6, it will choose the GUA to connect to it.

> Which means that if you *want* to force it to use ULA inside the network and GUA outside, the only scalable option is to use split-tunnel DNS. You could change the policy table too, but most users…

No, the RFC 6724 rules are recommended *default* rules. The authors of that RFC did an excellent job at making that clear. IMO, users (who know how) should be free to change the default rules in their devices if they don't like those rules. Application developers are free to implement whatever rules make sense for their applications. I've been involved with applications where the default rules would have caused increased complexity in application design, so rules that made sense for that app were used instead.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 22:37:13 +0900

> pair of addresses have been flushed to only leave the GUA.

No, it doesn't. Please read RFC 6724 again, or at least read the links I
provided.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 22:43:31 +0900

On Thu, Oct 16, 2014 at 10:34 PM, Ted Lemon <[email-masked]> wrote:

> >> My point was that homenets should have ULAs, and should not use GUAs
> for local communication, because GUAs can be flash renumbered,
> >>
> > Actually, they can't.
>

No, I didn't.

You seem to define flash renumbering as "your ISP invalidates your prefix
and gives you a new one". But such an event does *not* mean that the host
can't use its previous addresses any more, because the RA sent to the hosts
cannot reduce the valid lifetime below 2 hours. So in effect that's still
graceful renumbering with a 2-hour window.

That seems to me to be begging for trouble.   As a rule routers have too
> much memory, not too little, so I find this reasoning unconvincing.
>  Taking a little memory away from the buffer cache to make the forwarding
> table bigger seems like a really good idea.
>

Routers have many different types of memories, at very different costs.
DRAM is cheap. The stuff they store forwarding tables in is not. It's
expensive and hot.

> And changing the policy table isn't that hard: if we want to have a
> special policy for the local ULA, we already have a mechanism for doing it
> that does not require O.S. vendors to hard-code a different policy table
> nor users to select one manually: stateless DHCPv6.   And for those who
> consider the use of DHCPv6 déclassé, it will still work without: you just
> won't be protected from a provider doing flash renumbering.
>

And when your ISP renumbers you, or a new ULA joins the network, you're
going to tell the hosts about the new prefix policy using what type of
packet? There's no reconfigure in stateless DHCPv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 22:46:38 +0900

On Thu, Oct 16, 2014 at 10:34 PM, STARK, BARBARA H <[email-masked]> wrote:

> No, the RFC 6724 rules are recommended *default* rules. The authors of
> that RFC did an excellent job at making that clear. IMO, users (who know
> how) should be free to change the default rules in their devices if they
> don't like those rules. Application developers are free to implement
> whatever rules make sense for their applications. I've been involved with
> applications where the default rules would have caused increased complexity
> in application design, so rules that made sense for that app were used
> instead.
>

It seems to me that if you were more of an application developer and less
of a network engineer you would not have such a high opinion of the degree
of knowledge about (and interest for) networking generally possessed by
application developers. :-)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 09:06:15 -0500

On Oct 16, 2014, at 8:43 AM, Lorenzo Colitti <[email-masked]> wrote:
> And when your ISP renumbers you, or a new ULA joins the network, you're going to tell the hosts about the new prefix policy using what type of packet? There's no reconfigure in stateless DHCPv6.

Wouldn't the host do a DHCP Information Request when it sees a new prefix?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 23:08:31 +0900

> Wouldn't the host do a DHCP Information Request when it sees a new prefix?

Um, no? Why would it?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 09:11:11 -0500

> Um, no? Why would it? 

Because that's an indication that there is new information to be had.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Oct 2014 23:18:49 +0900

> Because that's an indication that there is new information to be had.

So every time a new prefix comes in, hosts should restart DHCPv6? That
seems pretty dubious (and expensive). I don't think any DHCP implementation
works that way.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Oct 2014 10:27:28 -0400

On Oct 16, 2014, at 10:18 AM 10/16/14, Lorenzo Colitti <[email-masked]> wrote:

> So every time a new prefix comes in, hosts should restart DHCPv6? That seems pretty dubious (and expensive).

Dubious?  Perhaps.  I don't know of any specification that suggests sending an Information-request message upon receipt of information about a new prefix or prefixes.

Expensive?  Can you prove "expensive"?  In my opinion and experience, this claim is more FUD about how "expensive" DHCPv6 is.

Way off course for this discussion?  Almost certainly.

- Ralph

> I don't think any DHCP implementation works that way.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 09:51:04 -0500

On Oct 16, 2014, at 9:18 AM, Lorenzo Colitti <[email-masked]> wrote:
> So every time a new prefix comes in, hosts should restart DHCPv6? That seems pretty dubious (and expensive). I don't think any DHCP implementation works that way. 

How do they work, then?   And why would you describe this as expensive?   How often do new prefixes appear on your networks?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 16 Oct 2014 16:39:13 +0000

> seems pretty dubious (and expensive). I don't think any DHCP
> implementation works that way.
> 
> How do they work, then?   And why would you describe this as expensive?
> How often do new prefixes appear on your networks?

[responding on homenet, since I don't think my response is about what should or shouldn't be done to RFC 3315]

Many hosts don't even implement DHCPv6. It's totally optional (RFC 6434). Even when implemented, it may be disabled. So relying on host DHCPv6 behavior (of any sort) for proper homenet functioning, including proper address selection, would be a bad idea, IMO. If DHCPv6 is *required* in any way in order to implement address selection policy in a host, I think we're in trouble [no matter if something is or isn't done to RFC 3315 to make information request behavior more predictable]. 

I think support for receiving more specific routes in RA messages (RFC 4191) would be easier to get hosts to implement than DHCPv6.

In any case, I think there needs to be a solution that *always* works in homenet hosts.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 12:37:10 -0500

> I think support for receiving more specific routes in RA messages (RFC 4191) would be easier to get hosts to implement than DHCPv6.

This wouldn't help, because there's nothing to differentiate the GUA from the ULA.

> In any case, I think there needs to be a solution that *always* works in homenet hosts.

As I mentioned earlier, the downside to not doing this is that if a site gets flash-renumbered, connections on the local network that might not have broken if a ULA were used will break.   This is a fairly mild problem.   Additionally, we talked about advertising ULAs in DNS on the local network, and GUAs externally, so even devices that don't do DHCPv6 would benefit from this.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Oct 2014 15:35:59 +0900

On Fri, Oct 17, 2014 at 2:37 AM, Ted Lemon <[email-masked]> wrote:

> As I mentioned earlier, the downside to not doing this is that if a site
> gets flash-renumbered, connections on the local network that might not have
> broken if a ULA were used will break.

You keep mentioning this, but you're incorrect. Even if the ISP
flash-renumbers, hosts will not lower the lifetime of their IP addresses
below 2 hours, per RFC 4862.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 17 Oct 2014 08:45:23 +0200 (CEST)

> below 2 hours, per RFC 4862.

Where in RFC4862 is this described?

A lot of time was spent on RF7084 and its predecessor, making sure it was 
a requirement to send RAs with zero-lifetime for the on-link prefix if the 
delegated prefix went away, so hosts would stop using it very quickly.

So my expectation if the ISP flash-renumbered (ie reset the PPPoE session, 
the physical uplink went down or the DHCPv6-PD lease expired), an RFC7084 
compatible router would send out RAs with zero-lifetime and hosts would 
immediately stop using these IPs for new connections. Am I wrong, and 
where can I read up on the behaviour you're describing?

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 17 Oct 2014 08:52:25 +0200

Hello Mikael,

Le 17 oct. 2014 à 08:45, Mikael Abrahamsson <[email-masked]> a écrit :

>> You keep mentioning this, but you're incorrect. Even if the ISP flash-renumbers, hosts will not lower the lifetime of their IP addresses below 2 hours, per RFC 4862.
> 
> A lot of time was spent on RF7084 and its predecessor, making sure it was a requirement to send RAs with zero-lifetime for the on-link prefix if the delegated prefix went away, so hosts would stop using it very quickly.

There are two different things

If you loose WAN connectivity, you send RAs with router-lifetime set to zero. Meaning you are not a default route.  (RFC7084 - G-4)
If you loose a DP, you send RAs with PIO lifetimes set to ‘prefered’=0 and ‘valid’=min(DP lifetime, 2 hours).  (RFC7084 - L-13)

So the host can keep using the prefix during 2 hours. The preferred lifetime set to zero would of course suggest him to use a different one instead.

> 
> So my expectation if the ISP flash-renumbered (ie reset the PPPoE session, the physical uplink went down or the DHCPv6-PD lease expired), an RFC7084 compatible router would send out RAs with zero-lifetime and hosts would immediately stop using these IPs for new connections. Am I wrong, and where can I read up on the behaviour you're describing?
> 
> --

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Oct 2014 15:53:15 +0900

> Where in RFC4862 is this described?

http://tools.ietf.org/html/rfc4862#section-5.5.3 point e).

> immediately stop using these IPs for new connections. Am I wrong, and where
> can I read up on the behaviour you're describing?

Deprecated addresses can still be used until their valid lifetime expires.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 17 Oct 2014 09:08:50 +0200 (CEST)

> Deprecated addresses can still be used until their valid lifetime 

Ok, got it. It won't be used for new connections if there is something 
around with a non-zero preferred lifetime, but old ones within the home 
will still work. Check.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 17 Oct 2014 14:24:08 +0200

Hi,

> Op 16 okt. 2014, om 15:22 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:
> 

Do you know if anything implements http://tools.ietf.org/html/rfc6724#section-10.6 (a site-specific policy entry for the local ULA prefix)?

Cheers,
Sander

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 17 Oct 2014 12:26:51 +0000

Correct.

DHCPv6 has its own state machine, so I would say, taking into account the 2hr valid lifetime minimum, to just make sure to have a leasetime short enough to cope with these changes rather than start enforcing the glueing of RA and DHCPv6.
OK, shorter lease time will introduce some more traffic, but imho, not that big overhead and only local traffic

From: homenet [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: donderdag 16 oktober 2014 16:19
To: Ted Lemon
Cc: [email-masked]; Michael Thomas
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

On Thu, Oct 16, 2014 at 11:11 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 08:29:28 -0500

> You keep mentioning this, but you're incorrect. Even if the ISP flash-renumbers, hosts will not lower the lifetime of their IP addresses below 2 hours, per RFC 4862.

You are technically correct, and I will admit to having gone slightly into the weeds there, but let me remind you of how this conversation started: someone again proposed that we retain a stale GUA rather than having a ULA.   So if you go offline and then come back online, your stale GUA gets flash-renumbered even if your ISP doesn't have a policy of doing flash renumbering.   When I say it gets flash-renumbered, I mean that the ISP is no longer offering service on that GUA, regardless of whether hosts may still consider it valid.

Why do we care?   Because you are now advertising an invalid GUA on the homenet.   Hosts will think that they can use that GUA to communicate _off_ the homenet, and lossage will ensue.   Apps that do happy eyeballs will be less affected by this, but not all apps do happy eyeballs.   So when the upstream gets flash renumbered, you _really want_ to tell hosts on the local network that that prefix has a valid lifetime of zero, so that they don't mistakenly use it for communication off-homenet.

And then there's the long-lived connection _in_ the homenet.   If we insist on using non-stable GUAs, then my ssh connection to my home server, which I often do keep open overnight doing something, would be killed by the renumbering that has to happen when the upstream is renumbered and there is no stable ULA.   For those who still do X windows, any of their X window connections to hosts on the homenet would be dropped.

So this is why I am arguing that homenets SHOULD have ULAs, and why Markus is arguing that they MUST.   We really do want hosts to prefer the ULA if they can use it, and we really do want to always have a ULA.   Hosts that are communicating on intra-homenet should not be using GUAs to do so, and it is worth a little effort to try to ensure that that is the case.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Oct 2014 22:46:55 +0900

On Fri, Oct 17, 2014 at 10:29 PM, Ted Lemon <[email-masked]> wrote:

> You are technically correct, and I will admit to having gone slightly into
> the weeds there, but let me remind you of how this conversation started:
> someone again proposed that we retain a stale GUA rather than having a
> ULA.   So if you go offline and then come back online, your stale GUA gets
> flash-renumbered even if your ISP doesn't have a policy of doing flash
> renumbering.   When I say it gets flash-renumbered, I mean that the ISP is
> no longer offering service on that GUA, regardless of whether hosts may
> still consider it valid.
>
> Why do we care?   Because you are now advertising an invalid GUA on the
> homenet.   Hosts will think that they can use that GUA to communicate _off_
> the homenet, and lossage will ensue.

No, they won't. The old GUA will be deprecated, and the hosts will not use
it if they have another GUA. If they don't have another GUA, they will
either use the deprecated GUA or the ULA, but it doesn't matter which they
use, because none of them will work anyway. Note that they *will* attempt
to use the ULA to talk to the outside world if they don't have a GUA, so
please don't come back saying "the hosts will know not to use it". :-)

> So when the upstream gets flash renumbered, you _really want_ to tell
> hosts on the local network that that prefix has a valid lifetime of zero,
> so that they don't mistakenly use it for communication off-homenet.
>

No, you don't want to tell them it has a valid lifetime of zero, you want
to tell them it has a preferred lifetime of zero. Which I think everyone
agrees with.

> And then there's the long-lived connection _in_ the homenet.   If we
> insist on using non-stable GUAs, then my ssh connection to my home server,
> which I often do keep open overnight doing something, would be killed by
> the renumbering that has to happen when the upstream is renumbered and
> there is no stable ULA.

Yes (but again, it won't be killed by the renumbering; it will be killed
*when its source address expires*). But I really doubt that real users have
long-lived connections from apps that don't reconnect on failure. Geeks
like us might, but that's not really who we should be designing for,
because geeks like us will know enough to pick an ISP that doesn't renumber
all the time.

Not all ISPs do constant renumbering. My prefix has been static for over
two years and it even followed me across an apartment move. And I just have
a standard residential service. US ISPs tend to renumber their users very
rarely (once every few weeks, at most).

So this is why I am arguing that homenets SHOULD have ULAs, and why Markus
> is arguing that they MUST.   We really do want hosts to prefer the ULA if
> they can use it, and we really do want to always have a ULA.   Hosts that
> are communicating on intra-homenet should not be using GUAs to do so, and
> it is worth a little effort to try to ensure that that is the case.
>

Oh, ULAs and stable addressing sound good on paper, sure. But as soon as
you actually try to use them, then suddenly there are a boatload of
scenarios that you need to deal with like the ones presented by James many
messages ago. What happens on splits? What happens on joins? Do you need to
keep old ULAs around? How many? Will implementations age them out? (I can
tell you the answer to that one: "no"; they're more likely to stop
accepting new ones than to have new ones replace old ones). And so on and
so forth.

I really don't think that it's worth accepting this complexity (and
brittleness, because home gateways are not the most well-tested or
frequently-upgraded of products) just for the sake of what is most likely a
minority of ISPs renumbering and breaking a tiny minority of users.

To my mind, ULAs are good for one thing, and one thing only: connectivity
when the network is bootstrapping or isolated and has no GUA. But using
them in that situation may well be an easier problem to solve.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 09:17:59 -0500

On Oct 17, 2014, at 8:46 AM, Lorenzo Colitti <[email-masked]> wrote:
> Yes (but again, it won't be killed by the renumbering; it will be killed *when its source address expires*). But I really doubt that real users have long-lived connections from apps that don't reconnect on failure. Geeks like us might, but that's not really who we should be designing for, because geeks like us will know enough to pick an ISP that doesn't renumber all the time.

I think that we should design our protocols to work independent of what prognostications we are able to make about what users might do today, rather than making decisions that will ensure that certain perfectly valid uses of the network will fail tomorrow.

> Not all ISPs do constant renumbering. My prefix has been static for over two years and it even followed me across an apartment move. And I just have a standard residential service. US ISPs tend to renumber their users very rarely (once every few weeks, at most).

This is true, but I at least have been renumbered by Comcast several times over the past six months, and I am not okay with connections on my local network failing when these renumbering events occur.   And we need to design for all uses cases, not just for your use case.

> Oh, ULAs and stable addressing sound good on paper, sure. But as soon as you actually try to use them, then suddenly there are a boatload of scenarios that you need to deal with like the ones presented by James many messages ago. What happens on splits? What happens on joins? Do you need to keep old ULAs around? How many? Will implementations age them out? (I can tell you the answer to that one: "no"; they're more likely to stop accepting new ones than to have new ones replace old ones). And so on and so forth.

You may have missed the message where I responded to James with concrete proposals for how to solve these problems.   It is entirely possible that if we explore that solution space we will conclude, as you have, that no solution is reliable and not brittle, but I don't think we have explored it, so I think your conclusion that we will not come up with a good solution is premature.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Oct 2014 23:50:05 +0900

On Fri, Oct 17, 2014 at 11:17 PM, Ted Lemon <[email-masked]> wrote:

> I think that we should design our protocols to work independent of what
> prognostications we are able to make about what users might do today,
> rather than making decisions that will ensure that certain perfectly valid
> uses of the network will fail tomorrow.
>

But you're saying you want ULAs because you want to continue to do what you
were doing yesterday: persistent connections, like SSH and X-windows. I
think you're trying to fix the problem at the wrong layer. But I don't
expect we'll agree with me on that.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 10:30:20 -0500

On Oct 17, 2014, at 9:50 AM, Lorenzo Colitti <[email-masked]> wrote:
> But you're saying you want ULAs because you want to continue to do what you were doing yesterday: persistent connections, like SSH and X-windows. I think you're trying to fix the problem at the wrong layer. But I don't expect we'll agree with me on that.

The current IP architecture effectively assumes that this gets fixed on layer 3.   I agree that this is a problem, but since we don't have a real layer 4 solution, I think it's worth making sure that we make things as stable as we can at layer 3.   This does not preclude working on a solution at layer 4.   Indeed, there are several people here who think that's important; perhaps you should put your heads together.   Nothing gets done until someone does it.   But beware: several ships have foundered against these rocks already.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Oct 2014 11:45:43 -0400

Ted Lemon <[email-masked]> wrote:
    > So this is why I am arguing that homenets SHOULD have ULAs, and why
    > Markus is arguing that they MUST.  We really do want hosts to prefer
    > the ULA if they can use it, and we really do want to always have a ULA.
    > Hosts that are communicating on intra-homenet should not be using GUAs
    > to do so, and it is worth a little effort to try to ensure that that is
    > the case.

Again, 7084 says ULAs are a SHOULD (I remembered a MUST).

In my mind, the kind of reason for a CPE device *NOT* to offer a ULA is because
the administrator typed in their own (provider independant) GUA over the ULA.

I.e. one of the 8 people in this conversation (perhaps the world) who
*actually* has their own allocation that they use in their home.. (not via a tunnel)
{my swap /24 is no longer at my home, and despite LRSA'ing it, I can't get my
own /40 from ARIN unless I'm willing to cough up $1250/year}

Perhaps there are other scenarios where the CPE needs to support turning off
the ULA generation and advertisement, but other than that, I read that SHOULD
as being pretty much a "MUST"

This is why I think the discussion is moot.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 10:51:22 -0500

> the administrator typed in their own (provider independant) GUA over the ULA.

Good point.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Oct 2014 11:54:35 -0400

Lorenzo Colitti <[email-masked]> wrote:
    >> I think that we should design our protocols to work independent of
    >> what prognostications we are able to make about what users might do
    >> today, rather than making decisions that will ensure that certain
    >> perfectly valid uses of the network will fail tomorrow.

    > But you're saying you want ULAs because you want to continue to do what
    > you were doing yesterday: persistent connections, like SSH and
    > X-windows. I think you're trying to fix the problem at the wrong
    > layer. But I don't expect we'll agree with me on that.

It's not about whether or not SSH and X-windows can reconnect or not.

It's that, even if they try, the target host has been given a new address,
and there are long-lived credentials which have been tied to the name
and the address.  We did this in the days when we didn't have mDNS, and
we couldn't trust that well DNS, and putting the IPv6 address (the ULA),
of that ssh-enabled powered bar into my /etc/hosts (or .ssh/config or
registry, or shell script) seems like an entirely sensible thing to do.

I will go back and read James' message about joins and splits.
It seems that we have this problem with GUAs as well, and it seems that
the whole address selection issue exists without ULAs, as long as one has
multiple ISPs.

And LLNs will be installed with ULAs, and in some cases, we might really
want to route that into the homenet, so ULAs show up even if CPE devices
don't create them.

{BTW: I've never been a fan of ULA-Random, and I really really would like
to fine some way to make non-routable IPv6 globally unique addresses, that
include reverse DNS and whois, available for a low enough price that nobody
has to think twice about getting them.  But, in this case for the home of the
unsophisticated user, ULA-Random, seems correct}

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 11:03:16 -0500

> the whole address selection issue exists without ULAs, as long as one has

The issue with joins and splits is that you would like your numbering to survive a temporary network partition, but to not survive a permanent network partition.   I think this problem is solvable, and have some ideas about how to do it, which are half-baked and probably won't work without tweaking.

E.g., when a homenet chooses a ULA, it could divide the /64s evenly between all of the participating homenet routers.   If there's a partition, the homenet routers get to keep the /64s they got to begin with, but if after some period of time (TBD) the partition hasn't healed, one of them (chosen back when the network wasn't partitioned) begins a transition to a new randomly-chosen ULA.   If new routers are added to a homenet, HNCP should be able to balance out the pool of free /64s so that every router has some to keep during a partition.

If two homenets each with their own ULA are joined, one of the ULAs is deprecated with a long tail.   It would also be worth factoring power-cycling into this: if a homenet router that had a ULA is powered off, then powered back on, connected to a new homenet, its ULA is probably the one that should be deprecated.   This will still fail in the case that there are devices that are still using the prefix, but I think we're now down in the really unlikely scenarios that we don't have to solve.

---

From: Don Sturek <[email-masked]>
Date: Fri, 17 Oct 2014 09:10:51 -0700

Hi Ted and Michael,

What this home network join/split topic with respect to ULA's is a draft
that targets becoming at least Informational.

I think several of these e-mails have hit on the problem, I don't see any
existing I-D's or RFCs that solve the problem.

Don

On 10/17/14 9:03 AM, "Ted Lemon" <[email-masked]> wrote:

>The issue with joins and splits is that you would like your numbering to
>survive a temporary network partition, but to not survive a permanent
>network partition.   I think this problem is solvable, and have some
>ideas about how to do it, which are half-baked and probably won't work
>without tweaking.
>
>E.g., when a homenet chooses a ULA, it could divide the /64s evenly
>between all of the participating homenet routers.   If there's a
>partition, the homenet routers get to keep the /64s they got to begin
>with, but if after some period of time (TBD) the partition hasn't healed,
>one of them (chosen back when the network wasn't partitioned) begins a
>transition to a new randomly-chosen ULA.   If new routers are added to a
>homenet, HNCP should be able to balance out the pool of free /64s so that
>every router has some to keep during a partition.
>
>If two homenets each with their own ULA are joined, one of the ULAs is
>deprecated with a long tail.   It would also be worth factoring
>power-cycling into this: if a homenet router that had a ULA is powered
>off, then powered back on, connected to a new homenet, its ULA is
>probably the one that should be deprecated.   This will still fail in the
>case that there are devices that are still using the prefix, but I think
>we're now down in the really unlikely scenarios that we don't have to
>solve.
>

---

From: James Woodyatt <[email-masked]>
Date: Fri, 17 Oct 2014 12:49:12 -0700

On Fri, Oct 17, 2014 at 7:17 AM, Ted Lemon <[email-masked]> wrote:

> You may have missed the message where I responded to James with concrete
> proposals for how to solve these problems.   It is entirely possible that
> if we explore that solution space we will conclude, as you have, that no
> solution is reliable and not brittle, but I don't think we have explored
> it, so I think your conclusion that we will not come up with a good
> solution is premature.
>

As I recall, the proposals in your response were less than concrete and
didn't solve the problems. In particular, I remain curious about how to
expire the locally generated ULA prefixes that accumulate over repeated
network joins and splits.  I remember explaining how those events could be
rather more frequent than people might be assuming, and that's where the
discourse seemed to stop.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 14:54:56 -0500

On Oct 17, 2014, at 2:49 PM, James Woodyatt <[email-masked]> wrote:
> As I recall, the proposals in your response were less than concrete and didn't solve the problems. In particular, I remain curious about how to expire the locally generated ULA prefixes that accumulate over repeated network joins and splits.  I remember explaining how those events could be rather more frequent than people might be assuming, and that's where the discourse seemed to stop.

If you don't burn a ULA prefix every time you split and rejoin, then I don't see why there would be any kind of significant growth in prefixes.   That's why I suggested the algorithm that I suggested.

---

From: Don Sturek <[email-masked]>
Date: Fri, 17 Oct 2014 12:56:56 -0700

Hi James,

One more issue that maybe needs some consideration:    How would a router
know the boundary for dissemination of ULA prefixes?  Here I am thinking of
the case where there may be more than one ISP interface and particularly in
the case of network splits and joins in the home.

So really I think there are a couple of different topics ripe for I-Ds:
1)  How to handle splits/joins of networks in the home where different ULA
prefixes are in use
2)  Guidance on when (and when not) to propagate ULA prefixes.  I think I
have heard anecdotally that most ISP see traffic using ULAs on their ISP
interface (which they drop).  It would be nice to have a definitive draft
that clearly states when this traffic should not be routed (so at least
dilligent implementers can attempt to do the right thing).  Again, I think
this topic is fairly obvious in a home with a single ISP and all devices are
connected from day 1 but it is less than clear when merging two or more
networks in your home (or attempting to split the networks)

Don

From:  James Woodyatt <[email-masked]>
Date:  Friday, October 17, 2014 12:49 PM
To:  HOMENET Working Group <[email-masked]>
Subject:  Re: [homenet] Let's make in-home ULA presence a MUST !?

On Fri, Oct 17, 2014 at 7:17 AM, Ted Lemon <[email-masked]> wrote:
>> you actually try to use them, then suddenly there are a boatload of scenarios
>> that you need to deal with like the ones presented by James many messages
>> ago. What happens on splits? What happens on joins? Do you need to keep old
>> ULAs around? How many? Will implementations age them out? (I can tell you the
>> answer to that one: "no"; they're more likely to stop accepting new ones than
>> to have new ones replace old ones). And so on and so forth.
> 
> proposals for how to solve these problems.   It is entirely possible that if
> we explore that solution space we will conclude, as you have, that no solution
> is reliable and not brittle, but I don't think we have explored it, so I think
> your conclusion that we will not come up with a good solution is premature.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 14:59:41 -0500

On Oct 17, 2014, at 2:56 PM, Don Sturek <[email-masked]> wrote:
>  How would a router know the boundary for dissemination of ULA prefixes?

Isn't that the same boundary as the homenet boundary?   I think we already solve that problem.

---

From: Don Sturek <[email-masked]>
Date: Fri, 17 Oct 2014 13:08:17 -0700

Hi Ted,

Here is the scenario that I am thinking might not be covered:
1)  Router A (say your internet service provider) has an ISP interface
with prefix 2001:: then has a ULA prefix for devices it is currently
communicating with
2)  Router B (in the same home connected via cellular) has a different ISP
interface with prefix 2002:: and also has a different ULA prefix for a
colleciton of devices it communicates with
3)  Router A is now connected to Router B via an interface in the home
(the join case).  Obviously, one of them needs to be the owner of *the*
ULA prefix in the home and the other should stop providing its prefix.

Same scenario for the split:
1)   I have two networks that were joined with Router A and Router B
linked.  I decide to island one of my networks (for example, I have a
lighting system using Router B but discovered there has been a security
breach and I don't want it exposed to the internet through Router A).
2)   Is it clear in terms of ULA prefix generation/propagation what Router
A and Router B should be doing regarding forwarding prefix information on
their internal (and by reference external interfaces)?

Maybe this would be covered by the splits/joins topic but it does seem
like ULA propagation changes in addition to the renumbering of the devices
in the home using ULA prefixes.

Don

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 15:17:07 -0500

> in the home using ULA prefixes.

I already covered both of those scenarios in a previous message.

---

From: James Woodyatt <[email-masked]>
Date: Fri, 17 Oct 2014 14:41:28 -0700

On Fri, Oct 17, 2014 at 12:54 PM, Ted Lemon <[email-masked]> wrote:

> If you don't burn a ULA prefix every time you split and rejoin, then I
> don't see why there would be any kind of significant growth in prefixes.
>  That's why I suggested the algorithm that I suggested.
>

I explained why you must generate a new ULA prefix every time you
commission a new network.

It's true that not every split entails commissioning a new network,
especially when the AAA service for the previously commissioned network is
still available on both sides of the split, but that isn't always true, and
besides, human user behavior must still be accounted. Whenever you have AAA
service, you are attempting to automate what humans think about who is and
who isn't allowed to do what. Sometimes people change their plans.
Sometimes people don't plan at all. Sometimes people make plans and don't
tell anyone, much less the silicon beasties in their house. Sometimes they
make plans without even recognizing it. Routers have to operate mostly in
the dark when a split happens. They may not be able to determine whether
they are still expected to be members of the previously commissioned
network or if they have been repurposed into a new network until well after
they have been operating split for some time, and perhaps joined with other
networks in the meantime. After a split, they may need to operate in a mode
that allows them to commission a new standalone network at any time when
they are split from a previously commissioned network.

In any case, we have defined a way for locally generated ULA prefixes
distributed in persistent storage of HOMENET interior routers to accumulate
without limit when independently commissioned networks join. Offering the
view that sensible people don't commission new networks very frequently is
not a solution to the problem. It's a way of implying the problem isn't
relevant to your interests. The problem may not be relevant to your
interests, but it is to mine.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 16:46:36 -0500

On Oct 17, 2014, at 4:41 PM, James Woodyatt <[email-masked]> wrote:
> I explained why you must generate a new ULA prefix every time you commission a new network.

Yes, you did, and I believe the mechanism I proposed for handling network splits addressed the problem you described.   If you think it didn't, can you explain why not, not by expressing reasons to doubt, but by walking through specific scenarios where what I proposed wouldn't work?

---

From: James Woodyatt <[email-masked]>
Date: Fri, 17 Oct 2014 15:16:44 -0700

On Tue, Oct 14, 2014 at 3:28 PM, Ted Lemon <[email-masked]> wrote:

> Ah, sorry, I didn't mean to say that we deprecate them but don't ever get
> rid of them.   I think once a deprecated ULA has expired, it should be
> gc'd.   If the homenet is partitioned, the two options are for the
> partitions to continue using one ULA and try to keep prefixes stable, in
> anticipation of the partition being healed later, or for both partitions to
> switch to new ULAs, or for one homenet router to "own" the ULA and get to
> keep it for use in whichever partition it winds up in, while the other
> partition has to choose a new ULA.
>
> Personally I think keeping the ULA stable across partitions is preferable,
> but I'm not sure it's possible to do it without the risk of flash
> renumbering.
>

Mr. Lemon, this is the only message in this thread where I can find you
saying anything about the expiration of locally generate ULA prefixes.

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.

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.

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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 17:37:48 -0500

On Oct 17, 2014, at 5:16 PM, James Woodyatt <[email-masked]> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Oct 2014 17:25:38 +1300

Ted,

On 18/10/2014 11:37, Ted Lemon wrote:
> I did explain how to do that: before the network partitions, 

That seems to imply that you know in advance that the network
will partition. I assume that it will usually be a surprise.
Normally there is no human manager, although a human might
randomly disconnect cables or switch off a power socket.

So I think you mean: as soon as the network has generated its ULA...

> divide the ULA into 64k /64 prefixes, and distribute these evenly among attached routers.

...but that will break when another router attaches itself later,
unless the (re)distribution process is continuous.

>  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.

Sure, and this needs to be supported by HNCP (or something else).

>   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. 

Again: that has to happen as soon as the ULA is generated, since partition
is unpredictable.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Oct 2014 07:57:32 -0500

> So I think you mean: as soon as the network has generated its ULA...

That is indeed what I meant, sorry for not saying so explicitly.

> unless the (re)distribution process is continuous.

Which is the reason we have HNCP.

> Sure, and this needs to be supported by HNCP (or something else).

Yup.

> Again: that has to happen as soon as the ULA is generated, since partition

To clarify, yes, when the ULA is generated you have to do this, but you may revisit the decision subsequently, prior to partition.   You don't know when partition happens, but that doesn't preclude making new choices later.   E.g., if you only have one internet connection, you might want the device connected to that link to be the one that holds the token.   Or you may have a dedicated server on-link which would be ideal for stuff like this, although we really haven't talked about non-router servers participating in HNCP.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Oct 2014 08:11:47 -0500

> To clarify, yes, when the ULA is generated you have to do this, but you may revisit the decision subsequently, prior to partition.   You don't know when partition happens, but that doesn't preclude…

And by "you" here I am of course anthropomorphizing the homenet...

---

From: James Woodyatt <[email-masked]>
Date: Mon, 20 Oct 2014 11:00:39 -0700

On Fri, Oct 17, 2014 at 3:37 PM, Ted Lemon <[email-masked]> wrote:

> [...] 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.
>

My apologies, but this is the first I've seen this basic idea outlined
here.  If you explained it previously, then I missed it due to my
inattention, and I apologize.

I do think this idea should needs a more rigorous description before I can
give it more thoughtful consideration. Some questions: "an agreement is
made" how? "aren't able to reach that router anymore" why (and how is that
detected)? "the new ULA is deprecated, the old ULA is advertised as
preferred" which is which, and how is it recognized (e.g. by NTP time
stamp)?

> 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.

Okay... except it seems you're admitting that my scenario where a simple
reconfiguration of a network topology, e.g. one caused by an intermittent
RF interference on an unlicensed band of the radio spectrum, would result
in a fully regular and normalized generation of a ULA prefix that would
subsequently be deprecated on network rejoin and subsequently deprecated
again. This could happen several times per hour, right?

> 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.

I certainly would agree with your observation that I don't see keeping a
permanent ULA as a good thing in itself. I keep asking why that would be
beneficial, and the answers continue to leave me scratching my head. Please
count me as one of the people here who has read Brian Carpenter's rant in
SIGCOMM about IP Addresses Considered Harmful, and who generally agrees.
I'm uncomfortable trying too hard to achieve some partial and dubious
success at establishing a persistent ULA prefix in the home network. I
think we should put our efforts more into making persistent the local
namespace for service registration and discovery.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Oct 2014 15:34:32 -0400

On Oct 20, 2014, at 2:00 PM, James Woodyatt <[email-masked]> wrote:
> Okay... except it seems you're admitting that my scenario where a simple reconfiguration of a network topology, e.g. one caused by an intermittent RF interference on an unlicensed band of the radio spectrum, would result in a fully regular and normalized generation of a ULA prefix that would subsequently be deprecated on network rejoin and subsequently deprecated again. This could happen several times per hour, right?

No, if it's done right the network would have to be partitioned for on the order of a week or two before the new ULA would be generated.

> I certainly would agree with your observation that I don't see keeping a permanent ULA as a good thing in itself. I keep asking why that would be beneficial, and the answers continue to leave me scratching my head. Please count me as one of the people here who has read Brian Carpenter's rant in SIGCOMM about IP Addresses Considered Harmful, and who generally agrees. I'm uncomfortable trying too hard to achieve some partial and dubious success at establishing a persistent ULA prefix in the home network. I think we should put our efforts more into making persistent the local namespace for service registration and discovery.

The reason I think it's beneficial is that it reduces to the minimum the number of instances where a long-lived connection will have to be broken because of a renumbering event.   I don't think we can reduce that number to zero, but I think we can make it a lot less likely than it would be if we renumber every time the upstream link goes away.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 20 Oct 2014 13:24:10 -0700

On Mon, Oct 20, 2014 at 12:34 PM, Ted Lemon <[email-masked]> wrote:

> No, if it's done right the network would have to be partitioned for on the
> order of a week or two before the new ULA would be generated.

Did you respond to my previous criticism of this idea? If so, then I missed
it. It's not a good idea to commission a new standalone network with the
same ULA as a previously commissioned network, because it destroys the main
property of ULA prefixes that makes them useful: the statistical
unlikelihood of merge collisions in the global address realm.

> The reason I think it's beneficial is that it reduces to the minimum the
> number of instances where a long-lived connection will have to be broken
> because of a renumbering event.   I don't think we can reduce that number
> to zero, but I think we can make it a lot less likely than it would be if
> we renumber every time the upstream link goes away.
>

Sounds to me like a benefit of very dubious value at best.  It's a fact
that applications cannot depend on the network never encountering a
renumbering event. That's the whole reason addresses have valid and
preferred lifetimes in the first place.  Applications that use long-lived
IPv6 connections cannot escape the problem that interface addresses may
expire at any time.  If they're not coded to recover from such events, then
it's their logic error, not ours.

I see no reason to work very hard to provide applications with a class of
global scope interface addresses that IETF documents encourage developers
to assume will never reach vltime=0 except when that assumption is
mysteriously invalid anyway because reasons. If there is a good reason for
it, which I'm missing, then I'm happy to consider it.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Oct 2014 16:32:27 -0400

On Oct 20, 2014, at 4:24 PM, James Woodyatt <[email-masked]> wrote:
> Did you respond to my previous criticism of this idea? If so, then I missed it. It's not a good idea to commission a new standalone network with the same ULA as a previously commissioned network, because it destroys the main property of ULA prefixes that makes them useful: the statistical unlikelihood of merge collisions in the global address realm.

Yes, I read your explanation, and the solution I proposed takes it into account.   Please stop arguing to win and actually read what I wrote.

> Sounds to me like a benefit of very dubious value at best.

Look at it this way: if you have a network and it occasionally gets reconfigured in a way that an application connection _cannot_ survive, that's bad, but we do accept that such situations occur from time to time.   But what if you have a network that is mainly stable, but you have a provider that isn't entirely reliable.   Is this network equivalent to one where you have a monkey who comes in every thirty minutes and swaps all the cables around?

Yes, we have to ride out unusual configuration change events.   But is it really "of very dubious value" to try to minimize the impact these events have on the stable operation of the network?  I don't think it is.

BTW, your flaky radio scenario isn't actually better if you have a GUA; arguably it's worse, particularly since it's probably an LLN that expects flakiness and knows how to ride it out, but does _not_ expect to be renumbered on a regular basis.   Please diagram that scenario and make sure you understand all the state transitions before you use it as a justification for not bothering to try to have a stable ULA.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 20 Oct 2014 13:52:49 -0700

On Mon, Oct 20, 2014 at 1:32 PM, Ted Lemon <[email-masked]> wrote:

>
> Yes, I read your explanation, and the solution I proposed takes it into
> account.   Please stop arguing to win and actually read what I 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.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Oct 2014 17:00:06 -0400

On Oct 20, 2014, at 4:52 PM, James Woodyatt <[email-masked]> 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.

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 21 Oct 2014 10:26:07 +0200

Hello,

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
      minutes.

   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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Oct 2014 09:17:35 -0400

>    o There is no other advertised ULA prefix.

I am concerned about this part.

Consider a home automation LLN, installed at home construction time, and
therefore provisioned with a ULA by the installers.  There is gateway from
the LLN to the home network, which likely has a dangling cable until the
owner moves in.
It is useful for that cable to advertise a ULA that can be used by various
parties (installers, realtors, home owners camping on the living room floor
while wait for the moving van) to control the home.  We can argue about
whether or not this gateway will be an application layer gateway, or a
router into the Home LLN; I would claim that it will be both for a long time.

okay, so it seems that there is always an advertised ULA from the LLN.
Should the homenet use that one, or should it somehow know to ignore it for
addressing purposes (accepting routing for it, though), and create another
one?

Maybe the word "advertised" here is mis-understood.

Does it mean via Router Advertisements, or does it mean via HNCP? Probably
that's explained in some other part of the draft.   I think that the HNCP
would permit the network leader to *defend* it's ULA, not just advertise it.

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 22 Oct 2014 10:19:50 +0300

TL;DR: I do not understand the reason for new text, and would vote against it.

I am probably being thick, but I can see three cases of ULAs in home network:

[1] something not from HNCP (e.g. from ISP, from some IoT gateway device, configuration, ..) that are essentially static from HNCP point of view, and just routable to,

[2] something not from HNCP (e.g. from ISP, from some IoT gateway device, configuration, ..) that also (partially) delegated to HNCP (also obviously routable to),

and

[3] HNCP generated (spontaneous) ULA (relatively dynamic), exactly 1 of them (or 0 if you buy the SHOULD argument which I do not).

My assertion:

Given HNCP generated one spans whole administrative domain, _and_ should not have routing anywhere outside it, it’s uniqueness does not _matter_. 

Therefore, what is the case for having to deal with ULA changing in case of network split/merge?

Case 1: Let us imagine split; I give one of my homenet routers to my neighbor. My neighbor winds up using same ULA. It has different owner, it does not talk with my network devices, and nobody knows they have same ULA nor cares if they do.

Case 2: Eventually, my neighbor gives the router back to me. I give it either physical access (wire) or appropriate wireless credentials. Again, it does not matter it has the same ULA, as long as the /64s it has assigned on it’s interfaces do not conflict what is in the rest of the network, and given it is [3] prefix, HNCP should take care of it.
(Hell, even [2] type prefix would be fine too in this case).

Only case where having same ULA in multiple places would matter, if you plan to route traffic between those places. Due to that, [3] case MUST NOT conflict with whatever comes from [1]/[2], but within [3] type, it does not matter at all. Internal is internal.

However, the case 2 looks much different if the ULA prefixes in the merge are different. Then you have to renumber either devices connected to the added router, or to the rest of the homenet. Due to that, I would advocate clearing ULA state before doing the merge to prevent wrong side of the fence winning the ULA allocation arms race. And having 2 ULAs in a home network as result of that is just wrong, from my point of view. Still, renumbering devices connected to router being added to your homenet sounds perfectly acceptable in case the ULA is of type [3]. If it is [1]/[2], just more than one ULA is also fine so it would not be applicable here anyway.

I have not looked at the draft text, but expressing these ideas should not be hard. The new text I strongly disagree with.

Cheers,

-Markus

---

From: James Woodyatt <[email-masked]>
Date: Wed, 22 Oct 2014 10:51:05 -0700

On Wed, Oct 22, 2014 at 12:19 AM, Markus Stenberg <[email-masked]>
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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Oct 2014 14:04:55 -0400

James Woodyatt <[email-masked]> 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_.
    >>

    > 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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Oct 2014 14:35:17 -0400

On Oct 22, 2014, at 2:04 PM, Michael Richardson <[email-masked]> wrote:
> Sure, people might not do that; sure there might be

Gack.   No.   The existence of multiple ULAs on the wire should not mean that one machine with three addresses gets three names.

---

From: James Woodyatt <[email-masked]>
Date: Wed, 22 Oct 2014 11:46:36 -0700

On Wed, Oct 22, 2014 at 11:04 AM, Michael Richardson <[email-masked]>
wrote:

> specific statement. [...]

You won't find it.  It isn't actually there.  There is some text that maybe
you were thinking says it, but it doesn't, and the people who will be
implementing this stuff will never look in the architecture document
anyway, so it's moot.

p1. I won't mince words either: the HOMENET architecture document is full
of wrong on this topic. In particular, section 3.6.6
<https://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6>.
ULAs as a hint of connection origin makes the unwarranted assumption that
subscriber home gateways are the only routers bordering the home network.
They may often be the only *default* routers, but there can be— and
absolutely definitely will be in the vast majority of cases— overlay
networks that route ULA prefixes to, from and most likely *between* home
networks over tunnels. We can't tell people not to do that. If there is a
routing protocol in a HOMENET, then it will be done, and it ought to work
right.

p2. These overlay networks will not be "for geeks only" and they will not
require advanced manual network configuration skills. If this issue isn't
handled right in HOMENET, then we can expect each of those overlay networks
(there will almost certainly be more than one in many homes) to use
delegated ULA prefixes instead of the HNCP locally-generated prefixes if
necessary, but that just goes to show that the locally-generated prefixes
are likely to be crippled compared to the ones from overlay networks, which
will actually be generated and delegated properly to keep them from
colliding on network joins and splits.

What's the point of having a HNCP locally-generated ULA prefix if it
doesn't actually have the statistical properties of collision avoidance
that ULA prefixes were designed in the first place to have?

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 22 Oct 2014 22:25:22 +0300

On 22.10.2014, at 20.51, James Woodyatt <[email-masked]> wrote:
> On Wed, Oct 22, 2014 at 12:19 AM, Markus Stenberg <[email-masked]> wrote:
> 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 was not writing anything based on recommendations ; I just wrote taxonomy of different ULA cases that I currently see as realistic, and in the [3], there does not seem to be any (automated) reason for routing outside the administrative domain that is the HNCP router network-

RFC4193 abstract.

   This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications, usually inside of a
   site.  These addresses are not expected to be routable on the global
   Internet.

If you are doing ‘private routing’ or whatever, note the categories [1] and [2] I defined that _are_ routable and should work for that fine.

I am just interested in the case [3]. For it, specifying just some fixed /48 or something for HNCP administrative scope use would be fine too. If multiple HNCP-using networks want to communicate, they may share the prefix (or at least make sure the /64s allocated are unique so the communication works between all routed links). 

The idea that they share (partially?) routes but not HNCP state sounds strange to me, but even for that, the [1]/[2] sub-delegation options should work fine.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Oct 2014 15:51:01 -0400

On Oct 22, 2014, at 2:46 PM, James Woodyatt <[email-masked]> wrote:
> They may often be the only *default* routers, but there can be— and absolutely definitely will be in the vast majority of cases— overlay networks that route ULA prefixes to, from and most likely *between* home networks over tunnels. We can't tell people not to do that. If there is a routing protocol in a HOMENET, then it will be done, and it ought to work right.

In the case where ULAs are being routed like this, wouldn't that ULA be the responsibility of whatever homenet federation protocol is being used?   I don't disagree that this is a valid use case, but I don't think it would rely on the homenet ULA.

---

From: James Woodyatt <[email-masked]>
Date: Wed, 22 Oct 2014 14:00:35 -0700

On Wed, Oct 22, 2014 at 12:51 PM, Ted Lemon <[email-masked]> wrote:

> In the case where ULAs are being routed like this, wouldn't that ULA be
> the responsibility of whatever homenet federation protocol is being used?
>  I don't disagree that this is a valid use case, but I don't think it would
> rely on the homenet ULA.
>

My point is that it doesn't need to be done that way unless HOMENET forces
that design choice.

I see a way to work around the potential problem here— by eating the
expense of requiring the overlay routers between HOMENET site boundaries to
exchange the full raft of valid /64 routes in all the currently valid
locally-generated ULA prefixes instead of exchanging just the aggregated
/48 ULA prefixes. I suppose that can be made to mostly work in the majority
of cases at the cost of memory and efficiency for interior routers. Don't
grow your home networks too big, however, or the interior routers in your
house— or in your friend's house— might fall over when the overlay connects.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Oct 2014 17:08:56 -0400

On Oct 22, 2014, at 5:00 PM, James Woodyatt <[email-masked]> wrote:
> My point is that it doesn't need to be done that way unless HOMENET forces that design choice.

The scenario you are describing sounds like it's secondary.   Yes, it's a valid use case, but homenets working right is a use case that will see wider deployment.   Federating home networks is certainly an interesting idea, but it seems even more bleeding edge than homenets.   I can think of a lot of nice ways to approach the problem.   I agree that if homenets use ULAs the way we're discussing, that constrains your choices, but I am confident that the remaining choices are not only adequate, but good.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Oct 2014 10:42:35 +1300

Michael,

> I'm pretty sure we said that somewhere, but I'll have to go search for the

You may be thinking of http://tools.ietf.org/html/rfc4193#section-4,
if we equate "site" to "homenet". I just re-read it and it all still
seems right to me. It doesn't discuss network splits, however, and
that is not a theoretical issue in homenets.

   Brian

> ------------------------------------------------------------------------
>