Subject: [homenet] In-network connectivity and HNCP: IPv6 ULA

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 02:43:07 +0200

During his talk, Ted claimed that he lost all connectivity when his uplink
went down.  This should not happen -- HNCP normally maintains an IPv6 ULA
that remains stable no matter what happens to DHCPv6 prefix delegations or
DHCPv4 leases.  This is described in Section 6.5 of RFC 7788, and it is
the default behaviour of hnetd.

Either Ted had tweaked the configuration of hnetd (which one should not
do -- hnetd does the right thing out of the box), or he was using software
that doesn't speak IPv6 or ignores ULAs.  At any rate, HNCP does not have
the issue that Ted described.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 21:36:14 -0400

In order for IPv6 to be useful, you need naming to work. We had this
discussion when I brought this up last year. It should be possible for an
IPv6-only homenet to work. But if we want homenet to be widely adopted, I
do not think this is the correct default behavior: it violates the
principle of least surprise. Further, unless you prevent services from
advertising IPv4 addresses, dropping the IPv4 uplink definitely will cause
connections to hang.

On Wed, Jul 18, 2018 at 8:43 PM Juliusz Chroboczek <[email-masked]> wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jul 2018 13:52:28 +1200

Ted,
On 19/07/2018 13:36, Ted Lemon wrote:
> do not think this is the correct default behavior: 

What "this" do you mean? Switching to ULAs to maintain local
connectivity? What's the surprise? There's no reason there
wouldn't be corresponding AAAA records, is there?

> it violates the
> advertising IPv4 addresses, 

We have a plan for that: draft-ietf-6man-ipv6only-flag-01

    Brian

> dropping the IPv4 uplink definitely will cause
> connections to hang.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 22:08:37 -0400

Sure.   If no services are advertised over IPv4, then we needn't offer IPv4
on the network at all.   But if we do offer IPv4 on the network, it should
be stable, and not vanish at the whim of the ISP.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 04:17:27 +0200

> In order for IPv6 to be useful, you need naming to work.

No argument here.

> But if we want homenet to be widely adopted, I do not think this is the
> correct default behavior: it violates the principle of least surprise.

There's no surprise, it just works.  RFC 6724, Section 6, Rule 8.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 04:29:24 +0200

> There's no surprise, it just works.  RFC 6724, Section 6, Rule 8.

Er, no.  ULAs have global scope.  My bad.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 22:31:26 -0400

Juliusz, with all due respect, if you have a connection over IPv4 and
suddenly your IPv4 network is deconfigured, your connection will hang.   I
know this because that's what happened.   This is not good behavior, and
should not be the default behavior of homenets.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 11:57:09 +0200

I've re-read Section 6.5 of 7788, and it looks like I was wrong.  Sorry,
I should not be writing technical mails in the middle of the night.

As far as I can tell from the wording of 6.5:

  - creating ULA is SHOULD if there's no global IPv6, MUST NOT otherwise;
  - creating private IPv4 is MAY if there's no global IPv4, MUST NOT otherwise.

If my reading is correct, that sucks.  I don't see how the MAY can be
implemented, since there's no obvious way to distinguish global from local
IPv4, and if you don't implement the MAY, then you'll lose local IPv4
whenever your IPv4 provider has a glitch, as you described.

> if you have a connection over IPv4 and suddenly your IPv4 network is
> deconfigured, your connection will hang.

The point Brian and I are trying to make is that you should have no
intra-Homenet IPv4 traffic -- your applications should prefer IPv6 to
IPv4, and and there should always be IPv6 in your Homenet.

Unfortunately, our point is made moot by the first MUST NOT above, since
the ULA becomes deprecated whenever there's global IPv6.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jul 2018 23:09:05 +1200

> the ULA becomes deprecated whenever there's global IPv6.

Yes, that should perhaps be revisited. But deprecated means: not to be used
for *new* connections, which shouldn't kill existing connections.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 07:47:37 -0400

I think the local ULA should be used for all intra-ULA connections. We had
a debate about this about four years ago, and apparently the text in the
HNCP spec reflects the outcome of that discussion, but I think we
understand  the problem better now and we should fix this. The current SHNA
doc requires the dnssd naming implementation to filter out GUAs when
answering requests on the local networks. THis was intended to ensure that
internal connections would survive the loss of the GUA.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 13:51:10 +0200

> I think the local ULA should be used for all intra-ULA connections. We had a
> debate about this about four years ago, and apparently the text in the HNCP
> spec reflects the outcome of that discussion, but I think we understand the
> problem better now and we should fix this.

Agreed.