Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
On Jul 13, 2015, at 04:28, Juliusz Chroboczek wrote: > > Last night, shncpd learned to send RAs. It was a lot of fun. Bravissimo! —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
On 14/07/2015 10:26, Lorenzo Colitti wrote: > On Jul 13, 2015 12:28, "Juliusz Chroboczek" > wrote: > >> - 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. > > 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
On Jul 13, 2015 12:28, "Juliusz Chroboczek" wrote: > - 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. What's the point of sending A=1 with a prefix length that's not 64? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
> 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. 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. >> (1) Does that mean a default route advertised in the Homenet routing >> 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. Then you should be advertising this route over the routing protocol, no? > 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
> 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]. 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. > > - 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. 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. > - 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? 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- > specific routing? Maybe this should be discussed in v6ops? > (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. 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. > (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. As noted, the requirement came from 7084. > - 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. 7084 says A and L MUST be set by default, though I think that RFC only deals with /64 assignments in its pure version. > > - 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. 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. > > - 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]). Yes, with the default to 7084 this would be gone anyway. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
> - 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: 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] shncpd and Router Advertisements, comments on hncp-06
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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
