Subject: [homenet] My comment about Ted's naming draft

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 18 Jul 2016 16:14:26 +0200

This is to repeat the comment that I made at the mike about
draft-lemon-homenet-naming-architecture-01.

Among other things, this draft suggests:

   1. having a new ND option (Section 3.5);
   2. defining a RESTful management API (Section 3.6);
   3. the use of a local resolver (Section 4.5);
   4. the use of a ULA (Section 5.5).

These are some fairly ambitious requirements, and I believe that they
deserve discussion separately from the naming issue.  More precisely:

(1) Are wo to go to the effort of specifying and deploying a new ND option?

(2) Defining a management API goes against the Homenet tradition, which
    is to negotiate things over HNCP rather than defining new APIs.

(3) HNCP does not currently mandate using a local resolver, and neither
    does it define a means to advertise the address of a local resolver to
    HNCP routers.  Are we requiring a full DNS server with DNSsec support
    on each HNCP node, including an HNCP speaker that is not a router?
    (Note that I'd be strongly opposed to requiring that every HNCP
    speaker must be a router, and I think my opinion on putting a DNS
    forwarder on every HNCP node is similar.)

(4) Is there WG consensus on requiring a ULA?

I don't have a definite opinion yet, but these requirements certainly make
me nervous.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 16:49:14 +0200

I wrote the ULA text because I thought there was already consensus, but
obviously whether or not there is consensus will come out if the document
is adopted by the WG, since if people object to the ULA, we can take it
out.   Personally I think that would be a mistake, and probably ideally the
ULA shouldn't be in the naming architecture since it's got little to do
with naming.

I would like to caution people against the idea that being less ambitious
will be a shortcut to success.   Andrew made this point at the mic, and it
is a really important point: a partial solution will become an obstacle to
a complete solution.   There are ways of diving this problem into chunks
that make sense, but we should have in mind the complete solution, even if
we approach it in a stepwise manner.   Otherwise we may wind up creating
problems that will be difficult to clean up later.

Of course, if we really don't care about all the things that the
architecture describes, that's another question entirely.   From my
perspective, though, there is nothing technically hard about what we're
talking about here; the main issue is that it's a substantial amount of
work.

On Mon, Jul 18, 2016 at 4:14 PM, Juliusz Chroboczek <
[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 16:51:01 +0200

On Mon, Jul 18, 2016 at 4:49 PM, Ted Lemon <[email-masked]> wrote:

> From my perspective, though, there is nothing technically hard about what
> we're talking about here; the main issue is that it's a substantial amount
> of work.
>

And, furthermore, we've built a lot of fairly complex and wonderful
technology at the IETF, and figuring out ways to automate deploying it is a
really useful exploration.   And something that your grad students might be
able to get some valuable experience with!   :)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 18 Jul 2016 17:01:10 +0200

>> From my perspective, though, there is nothing technically hard about
>> what we're talking about here; the main issue is that it's a
>> substantial amount of work.

You're possibly right, I don't know, but I'm worried about implementability.
I'm very worried that you're apparently proscribing speaking HNCP without
speaking DNS.

> And something that your grad students might be able to get some valuable
> experience with! :)

All of the students working on HNCP are undergrads.  Some of them first years.
So ease of implementation is essential ;-)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 17:04:29 +0200

I don't think the document is proscribing speaking HNCP without speaking
DNS.   A homenet router that doesn't support cross-link naming at all is
not useless.   It's just not as useful as one that does.

I think you are overestimating the complexity of implementing this, but
your undergrads can help us to test that theory.   :)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 18 Jul 2016 17:24:46 +0200

> DNS.

Then I've misunderstood something, my bad.

Suppose you have routers A and B on a link, and A implements DNS while
B doesn't.  How does B find out that it should advertise A's DNS server in
RA, DHCPv4 and DHCPv6?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 19:55:57 +0200

Right now HNCP doesn't actually seem to have a TLV for advertising
resolvers.   How does this work now?

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 18 Jul 2016 20:33:25 +0200

> On 18.7.2016, at 19.55, Ted Lemon <[email-masked]> wrote:
> Right now HNCP doesn't actually seem to have a TLV for advertising resolvers.   How does this work now?

DHCP options have also DNS server options (for v4 and v6).

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 20:45:40 +0200

Ah, thanks.  So, this could be used, but would give limited functionality
to links served only by router b.

The right solution will involve using hncp, I hope, to elect the primary
server for the network, and all updates would be sent to that server. Other
router could act as secondaries, or just forward DNS messages to the
nearest (or any) primary or secondary.

I think the election process is probably the hardest thing in this
solution, and I am hoping someone already knows how to do it...  :)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 17:00:38 -0400

> (4) Is there WG consensus on requiring a ULA?

I believe that this is.
a) it's in rfc7084 (so they are there even before homenet existed)
b) it's in rfc7368 (it's in our architecture)

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 18 Jul 2016 23:33:56 +0200

> resolvers.

That's exactly what I was trying to get at.

> How does this work now?

Not very well.

HNCP announces *external* resolvers in the DHCPv4- and DHCPv6-DATA
sub-TLVs of the EXTERNAL-CONNECTION TLV.  Hnetd uses this data to set up
a recursive DNS server which has all the usual smarts for selecting the
server to forward to, and also acts as an authoritative server for some
local zones (I'm shaky on the exact details).  Shncpd is much dumber, it
just merges all the EXTERNAL-CONNECTIONs' data and pushes the result to
the client using RA and DHCPv4 (shcnpd has no support for DHCPv6 yet).

There is no provision for advertising a DNS server that's not associated
with an external connection, i.e. that's within the Homenet.

> solution, and I am hoping someone already knows how to do it... :)

HNCP does perform a number of link-local elections, and uses two different
mechanisms:

  - for advertising assigned prefixes, it uses an OSPF-like election
    mechanism, but with no pre-elected backup;
  - for choosing e.g. DHCPv4 servers, it uses an ISIS-like election
    mechanism, which I happen to believe is a bad choice.

It should be possible to add a Homenet-local election mechanism to HNCP in
order to pick a recursive DNS server, but this would constitute a non-trivial
change to the protocol.  (Elections are fun, except in the UK, so I'd be
quite willing to help.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 18 Jul 2016 23:57:56 +0200

> b) it's in rfc7368 (it's in our architecture)

RFC 7084 Section 4.3 says:

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

RFC 7368 Section 2.4 says:

    A home network running IPv6 should deploy ULAs

RFC 7788 Section 6.5 says:

    An HNCP router SHOULD create a ULA prefix if there is no other
    IPv6 prefix with a preferred time greater than 0 in the network.
    It MAY also do so if there are other delegated IPv6 prefixes

I do not believe that there is WG consensus that ULA generation should be
a MUST.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 23:58:51 +0200

Why wouldn't you allocate one?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 19 Jul 2016 00:28:04 +0200

> Why wouldn't you allocate one?

I would.  ULAs are a goodness.  Probably.  I'm planning to add ULA
generation to shncpd at some future date, and perhaps even enable it by
default.

The question is about the level of MUSTiness.  I only see two reasonable
possibilities:

  1. ULA is SHOULD, and we cannot rely on their existence;
  2. ULA is MUST, which puts an additional requirement on implementations,
     but allows us to rely on their existence except during reconvergence.

No compromise between these two positions is possible.  It is not reasonable
to say that ULA is SHOULD while simultaneously relying on their existence,
which is what we're apparently trying to do.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jul 2016 00:51:11 +0200

I think it's should in the sense that there may be done reason not to do it
on some case and we don't want to preclude that because there is no
protocol reason to do so, but we expect that it will be allocated unless
there is some good reason. We talked about this at length a couple of years
ago and captured the intent in the architecture doc, but maybe not in
enough detail?

-- Juliusz

---

From: Tim Chown <[email-masked]>
Date: Tue, 19 Jul 2016 08:14:09 +0000

Hi,

On 18 Jul 2016, at 23:51, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

I think it's should in the sense that there may be done reason not to do it on some case and we don't want to preclude that because there is no protocol reason to do so, but we expect that it will be allocated unless there is some good reason. We talked about this at length a couple of years ago and captured the intent in the architecture doc, but maybe not in enough detail?

The problem with making statements in RFC7368 was doing so while keeping consensus; the more detail you add, the harder it is to keep consensus. There was consensus on “should”, and some rationale was given.

Of course since then we’ve found that omitting detail (like more specifics on the routing protocol, in particular) did come back to bite us later in that we really only deferred the decision.

Also, RFC7368 does not use RFC2119 language.

Tim

-- Juliusz

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 05:38:08 -0400

>> I believe that this is.  a) it's in rfc7084 (so they are there even
    >> before homenet existed) b) it's in rfc7368 (it's in our architecture)

    >     An HNCP router SHOULD create a ULA prefix if there is no other IPv6
    > prefix with a preferred time greater than 0 in the network.  It MAY
    > also do so if there are other delegated IPv6 prefixes

    > I do not believe that there is WG consensus that ULA generation should
    > be a MUST.

I don't think that Ted's document demands that there be a ULA.
Rather, I think that it demands that there is a prefix that can be used for
internal services.  That's a ULA on 99.9% of networks, the 0.1% being the 19
people on this list with their own RIR allocation.

If you have a situation where you have some other stable prefix that you can
use for your homenet, and you configure your routers to announce that rather
than a ULA, then you are in the edge case between a MUST and SHOULD.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 05:39:39 -0400

> but allows us to rely on their existence except during reconvergence.

I think that you are parsing "SHOULD" in a way closer to "MAY".
SHOULD is really quite a strong statement.  Someone violating a SHOULD does
so with the knowledge that they may break something else.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jul 2016 11:43:36 +0200

Yes, this is a really good clarification. Thanks!

On Jul 19, 2016 11:38, "Michael Richardson" <[email-masked]> wrote:

> IPv6

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 20 Jul 2016 00:12:55 +0200

I have now also read the naming draft. I think it does a good job of
summarising the desirable feature set, but it does strike me as being
slightly on the complex side in certain respects, and trying to simplify
things a bit might be worthwhile.

(I've been following homenet for a while but haven't commented much. I
think having naming work right is an important piece of the puzzle, so
hoping to add some momentum to the effort by weighing in).

I'll start with Juliusz' comments below and maybe add one or two of my
own.

> (1) Are wo to go to the effort of specifying and deploying a new ND option?

As I read this, it is mostly an optimisation and could be left out in
favour of simply timing out. Presumably the case it is solving (homenet
configuration lost) is so uncommon that having a simple timeout is
better than a new option that is probably not going to be very well
tested in any case.

>     is to negotiate things over HNCP rather than defining new APIs.

I agree that the "Restful API" sticks out a bit in the document.
Probably in part because it is a placeholder for something that is not
defined yet. But I'm not sure that it is actually needed. Could the
document not just specify that there must be some way to configure it
appropriately, and leave the details to the implementations?

>     forwarder on every HNCP node is similar.)

As I read this, a resolver on each link is required to filter out
spurious DNS updates (last sentence in section 4.1). If some other
mechanism to prevent this is substituted, presumably the requirement to
have a resolver on every link could be dropped?

Another thing that stuck out to me was the suggestion (in section 6.1)
to stick a captive portal in the user's face if there's a configuration
problem (or does "triggering captive portal detection" instead refer to
hijacking just the DNS names that, say, Android uses to detect the
presence of a captive portal?). Not sure I agree that's a good idea -
apart from captive portals being annoying as hell, this is again
specifying a UI element in detail; should the spec really do that?

Finally, the mechanism outlined in section 4.8 to use the homenet
services outside the homenet seems somewhat brittle to me. It involves
both caching logic and key management. I'm not sure to what extent this
is considered a killer feature. Would it be unreasonable to tell users
to simply add services they want to access from off-network to the
public zone?

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Jul 2016 10:53:15 +0200

> > (1) Are wo to go to the effort of specifying and deploying a new ND
option?

Why is this hard?

> better than a new option that is probably not going to be very well

Maybe so. We should think about this. In any case, remember that the
architecture document is the list of what are trying to accomplish. Seeing
high goals is okay. If we realized that this is an optimization with little
value, we don't have to do it.

> I agree that the "Restful API" sticks out a bit in the document.

Restful is probably overspecifying.

> Could the

This would represent failure. Leaving it to the implementation means no
interop, which means vendor lock in.

> have a resolver on every link could be dropped?

Send text proposing this new alternative. However, it doesn't need to be a
full blown resolver. It could just proxy. But there does need to be at
least one resolver in the homenet.

> specifying a UI element in detail; should the spec really do that?

We need a way to contact the user. This is an easy way. I am open to other
ideas.

> to simply add services they want to access from off-network to the

No. However, this is certainly a nice to have, not a must.