>> The minimum MTU in IPv6 is 1280 bytes, and the minimum maximum packet size >> (before fragmentation) is 1500 bytes.
> I assume you refer to Long Network Status (on multicast); Yes, sorry. > post MTU, or in secure mode, it should just use the Short one (which is > of fixed length). Ok. So I send multicast SNS. I receive NSR. I'm supposed to send LSR, right? But it doesn't fit in maximum packet size, even with fragmentation. RFC 2460, Section 5: A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size. > Current assumption is that sane set of node data fits inside one > (potentially fragmented) IPv6 packet (non-jumbogram), essentially > limiting the maximum size to <64kb. You cannot count on that. See above. >> What should I do if I receive an unknown TLV? I assume I should silently >> ignore it if it's inside a Data TLV, and include it in my database and >> flood it if it’s within a Data TLV, right? > Right. Please make that very clear. Implementors will get it wrong, and we'll find ourselves unable to extend the protocol. >> Which messages are allowed to contain extra TLVs? For example, what >> should I do if I receive a Long Network State Update with a bunch of >> unknown TLVs interleaved with the Node State TLVs? > > Any of them. The messages are defined just by the MUST be present TLVs. Again, please make this very clear. In particular, make it clear that upon encountering an unknown TLV, the rest of the packet must be processed as usual. (The other possible choice is that the whole rest of the packet is ignored.) >> There's a single connection for all neighbours on a given interface, >> right? Why not call that an Interface, then? > In case of HNCP, this is true, as it has connection=(link-local IPv6 > UDP-using) interface. In DNCP, a connection may be just e.g. one unicast > endpoint you want to talk with over the internet. I see. I still dislike the term of "connection", which seems to imply a point-to-point thing. Ideas? >> 7. Neighbor graph >> >> The notion of "neighbor graph" suddenly appears in Section 5.4. It's >> pretty obvious what you mean, but this should be precisely defined >> somewhere. > The later traversing definition more or less describes what it ‘is’; any > idea of what a good definition would look like? Actually, looking at it again, I'm not sure I know what is the neighbour graph. It's the directed graph defined by all neighbour TLVs, or the undirected graph that you get after removing unidirectional neighbours? I assume the latter. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
