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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
