> On 18 Sep 2019, at 5:36 pm, Ray Hunter (v6ops) <v6...@globis.net> wrote: > > Hi, > > I've been experimenting with Homenet before looking at enhancing HNCP for > extended naming functionality (the current implementation only covers > resolver configuration and not name server configuration). > > During my testing I managed to break HNCP, so that it got stuck in a state > where it didn't converge. > > Looking at the specification in detail this shouldn't have been a surprise to > me or anyone else due to the design choices that were made. > > > > First observation: Running HNCP over L2TPv3 breaks HCNP because L2TPv3 breaks > UDP fragmentation (works as designed). > > The L2TPv3 tunnel has a lower MTU than the local LAN, and does not report > ICMP PTB, so HNCP packets in one direction get through, but replies get > dropped. > > Early drafts of HNCP stated that UDP fragmentation would not be broken in the > Homenet for the foreseeable future. Well I managed to break that ;) > > So this is a known situation. > > Changing the MTU on the LAN interfaces of my routers to 1280 brought > everything back to normal, as expected. > > Question: If Homenets are moving to flat L2 meshes over foo, as some have > said, will this impact HNCP? > > The Linux kernel (in Openwrt) can/could easily support PMTUD. > > But since the L2 tunnels don't report drops, it makes PMTUD potentially > challenging for a simple protocol like HNCP. > > Question: As a simple mitigation, is there any way of manually signalling to > the kernel that ALL UDP packets on port 8231 should assume an PMTU of 1280 > octets?
setsockopt(IPV6_USE_MIN_MTU=1); from RFC 3542 works provided the OS has implemented it. It’s a really pity that POSIX hasn’t picked up RFC 3542 in the 16 years since it was published like they picked up RFC 3493. This is a epic fail of SDOs. > That wouldn't require any specification change and would allow HNCP to work > reliably in the presence of tunnels and varying MTU's that don't match the > local interface MTU. > > > > > Second Observation: HNCP packets grow quickly in size, which may become a > concern for scaling. > > Again, by design, DNCP is limited to TLV content of 64K (RFC7787 intro). > > AFAICS that is 64K per DNCP system, not per node. > > Question: Is that correct? > > For my 4 node Homenet, HNCP reached 3140 octets, without any modifications or > additions or long names. > > Question: Does the amount of state scale linearly with the number of routers? > > Question: Is this starting to become a concern? > > The limitation for 64K seems to come from the following: > > RFC7788 > Request Network State TLV (Section 7.1.1): The receiver MUST reply > with a Network State TLV (Section 7.2.2) and a Node State TLV > (Section 7.2.3) for each node data used to calculate the network > state hash. > > > In the Openwrt implementation, I observe that the requester is requesting the > node state for all 4 devices in one packet. > > I also observe that the reply from the peer contains the entire state of the > entire Homenet in a single UDP packet (network TLV and node state TLV for all > 4 routers + optional payload data). > > Question: Is that as designed/intended? Is this where the 64K data limit > comes from in RFC7787? > > If this was a design goal to reduce chatiness, and improve convergence time, > is it possible to implement this differently to reduce packet size and/or > increase overall TLV data capacity? > > Could the requester in step1 request the network status TLV, and the peer > reply with just the network status TLV and the node TLV's, but without the > underlying optional HNCP payload data TLV's. > > Maybe include a new "more-HNCP-data-to-come" TLV to distinguish this from > blank node data? > > That would give enough information for both nodes to know exactly which > payload data needed synchronising. > > Then as step 2, the requester could individually request the Node TLV for > each node one per packet, and the peer would reply with the Node TLV but this > time including the optional data TLV's. > > The receiver and peer would both know that HNCP hadn't converged whilst > waiting for the additional data, and could mark it internally as being stale > whilst waiting for the additional detailed update. > > Question: What would break? > > Question: What would need to be amended in the standard RFC? The > more-HNCP-data-to-come TLV in RFC7788? > > Question: Would this tweak increase the ±64K limit of TLV data from being per > network to being 64K per node? [max UDP packet size for a single node TLV + > associated payload data] > > Question: Is this raw fragmentation by separating DNCP essentials from HNCP > payload something that the WG would support? > > regards, > > -- > regards, > RayH > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
