Subject: [homenet] shncpd and Router Advertisements, comments on hncp-06

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Jul 2015 13:28:36 +0200

Last night, shncpd learned to send RAs.  It was a lot of fun.

Having RAs in the same process as HNCP makes it easy to announce/retract
routes in a timely manner.  RAs cost some 400 lines of code (including the
silly RDNSS bits), which brings shncpd to slightly over 3000 lines.  For
pure IPv6 operation, the only external requirement is babeld; for double-
stack, you'll need an external DHCPv4 server [1].

The implementation is different from what is mandated by -06, for a few
reasons.  As usual, I'd like people to comment whether I'm being silly or
whether some of the MUSTs in the draft can become SHOULDs or even MAYs.
Note that I haven't checked RFC 7084 yet [2].

 - Since I don't implement DHCPv6, I'm not setting the "O" flag; for some
   reason, Section 7.2 says that this flag MUST be set.

 - I always set a non-zero default router lifetime, which is clearly
   wrong.  Section 7.2 says that this flag MUST be set when a default
   route is "known in the HNCP network".  This requirement, or at least
   its formulation, has multiple issues to my eyes:

     (1) Does that mean a default route advertised in the Homenet routing
         protocol, or do non-Homenet default routes count?

     (2) How do you define a default route in the presence of source-
         specific routing?

     (3) This requires either monitoring the kernel's routing tables or
         snooping the routing protocol, and this is the only place in HNCP
         that imposes such a requirement; it is a pity to add that sort of
         incestuous interaction between protocols just for this single
         feature.

     (4) A routing protocol can have hiccups at a faster rate than what
         RFC 4861 is designed to handle.  For example, babeld in its
         default configuration will react to a newly discovered wired link
         within 2s, and to a lost link within 6s.  You don't want to flap
         your RAs every 4s on average.

    I think a better solution is needed.  I'm planning to declare myself
    a default router whenever I know of an IPv6 delegated prefix that's
    not a ULA, and hope for redirects to fix any resulting issues.

  - I'm setting the A flag even for prefix lengths different from /64,
    which is a reasonable thing to do according to my reading of RFC 7421.
    HNCP says that it should be done "whenever the prefix is suitable for
    stateless configuration", whatever that means.

  - Section 7.2 says that the RDNSS option must have "appropriate
    contents".  What's appropriate?  Should I merge all of the DHCP6-DATA
    TLVs that I've seen, should I merge just the ones from external
    connections that have delegated prefixes that I'm using for IPv6
    assignments, or should I pick just one DHCPv6-DATA section?  I'm
    currently merging everything, not even checking for duplicates.

  - I'm not sending a DNS Search List, although the spec tells me I SHOULD,
    since (1) I hate DNS search lists (shortcuts should be done in the
    application, not in the resolver), and (2) the spec doesn't tell me how
    to build a suitable DNS search list.

  - I'm not doing the router preference (RFC 4191) dance, since I don't
    understand how it interacts with multihomed hosts.  (For single-homed
    hosts it's irrelevant, since redirects will make things right.)
    I also generally prefer the hosts, not the routers, to be smart (think
    MP-TCP, think MP-Mosh, think MP-Kademlia [3]).

Thanks for your attention.

[1] It is not yet clear to me how to integrate DHCPv4 in the highly
    dynamic environment that we're building.  What should happen to
    existing leases when a prefix disappears or when we lose an election?
    It is also not clear whether it's better to have DHCPv4 in the shncpd
    process, or to use an external daemon and communicate with it using
    ASN.1 encoded in Baudot code over Unix domain sockets, OpenWRT-style.

[2] The number of distinct RFCs and drafts that you need to read in order
    to implement HNCP is frightening.

[3] http://bittorrent.org/beps/bep_0045.html
    This is implemented in Vuze, and I spent some time telling the author
    about source-specific routing.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Jul 2015 14:48:25 +0200

>    its formulation, has multiple issues to my eyes:

I've changed my mind.  This is a reasonable hing to do.  I suggest some
minor tweaks:

  - replace "a default route" by "a (possibly source-specific) default route";

  - add a note saying that hysteresis SHOULD be applied, i.e. that
    a router SHOULD continue announcing itself as a default router for
    a short time after the last default route has been retrated by the
    routing protocol, in case it comes back.

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 13 Jul 2015 15:37:02 +0200

> Note that I haven't checked RFC 7084 yet [2].
Didn't we have a thread on 7.2 a few days ago, already?
At least I feel like having a slight deja-vu replying. Anyway.

Please read into 7084, Section 7.2 will hopefully go away entirely.
We already refer to 7084 and that section just duplicates some
parts of it thus it is mainly redundant.

In the end I think v6ops is the more appropriate address for most
of these discussions anyway. I will reply with what the change
would be, if we default back to 7084 behavior.

>    reason, Section 7.2 says that this flag MUST be set.
O flag will be up to the implementor, if the router supports stateful
dhcpv6 both M and O flags are SHOULD.

Personal note: AFAIK statelss DHCPv6 is the only way for Windows
to receive DNS servers for IPv6.

>          protocol, or do non-Homenet default routes count?
All do, imagine you are the only (edge) router and your default route
comes from your ISP via RAs.

>      (2) How do you define a default route in the presence of source-
Maybe this should be discussed in v6ops?

>          incestuous interaction between protocols just for this single
Snooping the IGP is not an option. You may not even run an IGP,
e.g. if you are an isolated node with only ISP and client connectivity.
>     not a ULA, and hope for redirects to fix any resulting issues.
As noted, the requirement came from 7084.

>     stateless configuration", whatever that means.
7084 says A and L MUST be set by default, though I think
that RFC only deals with /64 assignments in its pure version.

>     to build a suitable DNS search list.
7084 says the router MUST support providing the option,
nothing about the contents.

Btw. HNCP mentions search domains in 8.1 but this is only a special case.

>     MP-TCP, think MP-Mosh, think MP-Kademlia [3]).
Yes, with the default to 7084 this would be gone anyway.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Jul 2015 16:02:59 +0200

> At least I feel like having a slight deja-vu replying.

That was before I started implementing, while these are my conclusions
after implementing.  Obviously, there's a lot of overlap.

Sorry if I'm spamming, but I've been criticised before for having private
discussions without CC-ing half the universe.  TINC.

> Please read into 7084, Section 7.2 will hopefully go away entirely.

Not a good idea, 7.2 is fairly easy to read and comprehend, 7084 is a mess
of mostly irrelevant recommendations with no rationale.  I recommend
keeping it, but making it clear that these are informative recommendations
and that The Truth is in 7084.

> comes from your ISP via RAs.

Then you should be advertising this route over the routing protocol, no?

> e.g. if you are an isolated node with only ISP and client connectivity.

In Section 11 you say

    o It MUST implement and run a routing protocol appropriate for the
      given link type on all of the interfaces it sends and receives
      HNCP traffic on.

Obviously, you could be speaking HNCP on an empty set of interfaces, but
that's not a case I'm going to loose much sleep on.

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Jul 2015 23:26:01 +0100

>     which is a reasonable thing to do according to my reading of RFC 7421.

What's the point of sending A=1 with a prefix length that's not 64?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Jul 2015 11:52:52 +1200

> What's the point of sending A=1 with a prefix length that's not 64?

Heh heh. That's part of why we wrote RFC7421.

Architecturally, A=1 and prefix length =N is perfectly fine, if and only
if all SLAAC-capable nodes on the link know how to generate an IID
of length 128-N.

In the real world this only works for N=64 today. afaik, there is no way
to negotiate a different value. IMHO it would have to be pre-configured
in every node on the link, but architecturally Juliusz is correct.

     Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 14 Jul 2015 03:16:03 +0200

> What's the point of sending A=1 with a prefix length that's not 64?

It's a matter of principle.

It's none of the router's business to guess which prefix lengths the hosts
know how to use for autoconfiguration.  The router is saying "I've
allocated this prefix for you, kind hosts, and I really don't mind if you
use it for autoconfiguration", and it's the hosts' business to decide what
to do with the available prefixes.

Think of it as pushing as many policy decisions to the hosts as possible,
as a matter of principle.

-- Juliusz

---

From: james woodyatt <[email-masked]>
Date: Tue, 14 Jul 2015 10:37:28 -0700

> Last night, shncpd learned to send RAs.  It was a lot of fun.

Bravissimo!

—james