Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On 30.11.2015 13:24, Mikael Abrahamsson wrote: > You still have to sync all information between all HNCP speakers anyway > in order to facilitate fast handover, both for /128 and /64 solution. That's not correct. If you read the draft, in the /128 case there is no need for this information to be published using HNCP. You would only publish which routers take part in the roaming. Now, while I mostly agree that the /64 would make certain things easier, it is not really a feasible solution unless we can ensure, that all ISPs delegate _at least_ a /56. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
Hello Barry, thanks for your review. On 19.11.2015 06:42, Barry Leiba wrote: > -- > DISCUSS: > -- > > I have two points that I'd like to discuss, both of which should be very > easy to resolve: > > -- Section 10.1 -- > For all the capability values you say something like this: > > It MUST be set to some value between 1 and 7 > included (4 is the default) if the router is capable of proxying > MDNS and 0 otherwise. > > First, the word you want is "inclusive", not "included". > > Second, "4 is the default" really means that you can set it to 0, and > that's the same as setting it to 4. But it seems that 0 means that the > router does not have the specified capability. Those seem to be in > conflict. I strongly suggest you do NOT have a default, and allow the > use of 0 *only* to designate lack of that capability. > > Please discuss this with me to make sure I'm not misunderstanding you > here. I have changed them all to: It MUST be set to 0 if the router is not capable of doing FOO, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use. I hope this clears it up. > -- Section 13 -- > I have two concerns with how the HNCP TLV Types registry is specified: > > 1. Because the DNCP TLV Types registry specifically allocates 32-511 for > profiles, it'd be better to simply limit the range of values in this > registry to those values, rather than making it broader and duplicating > the other values from the other registry. > > 2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range > in its registry. I would rather see this be text in the document (here > in the IANA Considerations is a fine place for it) that says that HNCP > uses the Private Use range for per-implementation experimentation, and > not have that be in the HNCP registry. > > In other words, I'd make it more like this (and add a reference to RFC > 5226): > > NEW >IANA should set up a registry for the (decimal values within range >32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under >"Distributed Node Consensus Protocol (DNCP)", with the following >initial contents: > > 32: HNCP-Version > 33: External-Connection > 34: Delegated-Prefix > 35: Assigned-Prefix > 36: Node-Address > 37: DHCPv4-Data > 38: DHCPv6-Data > 39: DNS-Delegated-Zone > 40: Domain-Name > 41: Node-Name > 42: Managed-PSK > 43: Prefix-Policy > 44-511: Unassigned > >The policy "RFC Required" [RFC5226] should be used for future >assignments. > >The range reserved by DNCP for Private Use (768-1023) is used by >HNCP for per-implementation experimentation. How collisions are >avoided is out of scope of this document. > END > > Does that make sense? Yes, I will talk to Markus about it, but from my point of view your suggestion looks good. > -- > COMMENT: > -- > > -- Section 1.1 -- > >As HNCP uses DNCP as the actual state synchronization protocol, the >applicability statement of DNCP can be used here as well; HNCP should >not be used for any data that changes rapidly and constantly, and >locators to find such services should be published using it instead. > > I don't follow the second half of that (after the semicolon): I don't get > the antecedents to "such services" (there are no services mentioned) and > "it" (maybe understanding "such" will help sort this part out). Can you > re-word this to make it clearer? Changed to: As HNCP uses DNCP as the actual state synchronization protocol, the applicability statement of DNCP applies here as well; HNCP should not be used for any data that changes rapidly and constantly. If such data needs to be published in an HNCP network, a more applicable protocol should be used for those portions and locators to a server of said protocol can be announced using HNCP instead. An example for this is naming and service discovery for which HNCP only transports DNS server addresses, and no actual per-name or per-service data of hosts. > > -- Section 3 -- > >3. DNCP Profile >The DNCP profile of HNCP is defined as follows: > > That seems backwards to me; I'd say this is "the HNCP profile of DNCP", > no? changed to "DNCP profile *for* HNCP" > >o HNCP operates on multicast-capable interfaces only. HNCP nodes > MUST assign a locally unique non-zero 32-bit endpoint identifier > to each interface for which HNCP is enabled. The value zero it is > not used in DNCP TLVs, but it has a special meaning in HNCP TLVs > (see Section
Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
> Two things on this. First, is a Leaf interface on the router facing > devices that don't support HNCP or on the hosts facing an HNCP router? I > would think you would want this to be a category on the router. Second, > I don't quite understand "DNCP endpoint". There is no definition of that > in either this spec or the DNCP spec. So, I am not sure what that would > entail for an implementer. The leaf category can be used for interfaces of HNCP devices on which it doesn't which to speak HNCP, e.g. where only non-HNCP devices are expected to be, e.g. a WiFi AP for clients. The point is to not speak HNCP if you don't have to which can increase security (see 12.2). "Endpoint" is used and defined in DNCP, I called it "DNCP Endpoint" to indicate it comes from that draft, however i can remove the "DNCP" if that would make it more clear. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
Hello Brian, thanks for the comments. On 19.11.2015 14:59, Brian Haberman wrote: > -- > DISCUSS: > -- > > * I see where HNCP describes how interfaces are classified as internal or > external, but how does an interface get classified as leaf, guest, or > ad-hoc? Is this some manual configuration step that needs to be > described somewhere? These can only be manually selected. I have added a sentence: Note that all fixed categories except internal and external cannot be auto-detected and can only be selected using manual configuration. to the second-last paragraph of the border discovery algorithm section. > * The definition of Leaf in 5.1 is unclear. It says "Such an interface > uses the Internal category with the exception that HNCP traffic MUST NOT > be sent on the interface, and all such traffic received on the interface > MUST be ignored." The "all such traffic" is ambiguous. Based on the > definition of the Guest category, I think "all such traffic" is really > "all HNCP traffic". I have changed it to Such an interface uses the Internal category with the exception that it MUST NOT operate as a DNCP endpoint. to be in line with the changed definitions for the internal and external categories (to address one of Ben's comments). > * The text in section 5.3 seems incomplete. It gives a 4-step algorithm > for border discovery, but says "if the node does not implement > auto-detection, only the first step is required." If auto detection is > not supported and a fixed category is not configured, what happens? Does > this mean that if auto detection is not supported manual configuration of > the border is required? I changed it to "first and last" so the default is in line with the default for the auto border discovery. > * Section 7 describes how to handle non-HNCP capable routers. However, I > don't see any operational issues described that could arise from having a > non-HNCP capable router connecting two clouds of HNCP within the same > home network. It seems like that could cause problems with a bunch of the > services provided by HNCP. I have added this as a paragraph to the applicability section: While HNCP routers can provide configuration to and receive configuration from non-HNCP routers, they are not able to traverse such devices based solely on the protocol as defined in this document, i.e., HNCP routers that are connected only by different interfaces of a non-HNCP router will not be part of the same HNCP network. > -- > COMMENT: > -- > > * Section 3 has several ambiguous/confusing statements: > > 1. Does "locally unique" mean unique to the node or unique to the > link/network? Clarified. > > 2. On a node ID collision, which node re-computes? The one detecting, I > assume. Correct. > > 3. "7 doublings" is an odd phrase. Why not say "Imin * 2^7"? > That phrase actually comes from the Trickle RFC "The maximum interval size, Imax, is described as a number of doublings of the minimum interval size (the base-2 log(max/min))." Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
Hello Benoit, thanks for the review. On 18.11.2015 15:20, Benoit Claise wrote: > One issue to be discussed: the link with the future BCP > draft-ietf-v6ops-reducing-ra-energy-consumption-03, on the same telechat. > > draft-ietf-v6ops-reducing-ra-energy-consumption-03 mentions: >"On links with a large number of battery-powered devices, sending >solicited Router Advertisements multicast can severely impact host >power consumption." > >>From this document: I see "HNCP operates on multicast-capable interfaces > only" > Do we expect battery-powered devices in homenet? I guess so: my phone for > example. > I discussed this topic with Mark Townsley, who is on it already. DNCP (and thus HNCP) uses multicast only for unsolicited messages, e.g. messages triggered by Trickle. Every solicited message (= reply to a multicast or unicast packet) MUST always be sent using unicast. This is mandated in the DNCP draft. So I think there should not be an inherent conflict with this draft here. > > > -- > COMMENT: > -- > >As HNCP uses DNCP as the actual state synchronization protocol, the >applicability statement of DNCP can be used here as well; HNCP should >not be used for any data that changes rapidly and constantly, and >locators to find such services should be published using it instead. >This is why the naming and service discovery (Section 8) TLVs contain >only DNS server addresses, and no actual per-name or per-service data >of hosts. > > What is it in in "using it"? If DNCP, then it contradicts > https://tools.ietf.org/html/draft-ietf-homenet-dncp-12#section-1.1: > > However, there are certain cases where the protocol as defined in > this document is a less suitable choice. ... frequently changing > data: DNCP with its use of Trickle is > optimized for the steady state and less efficient otherwise. > > Chatting with Mark Townsley, he proposed some clarifying text: > HNCP should not be used directly for data that changes rapidly and > constantly, though > stable locators to find such data by other means may be advertised > within HNCP. Okay we will discuss this one in the coming days and try to come up with something more clear. > - Each HNCP router MAY obtain external connection information such as >address prefixes, DNS server addresses and DNS search paths from one >or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or >static configuration. > > If you know pf the YANG model already, you should mention it. We don't yet, but it would probably be something defining network interface related. I will try to investigate if there is a relevant RFC already that we could reference. > Below is Sheng's OPS-DIR review. Sorry, that somehow slipped through my radar until today, I just sent a direct reply to that mail-thread. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
Hello Ben, thanks for the review. > -- > COMMENT: > -- > > Minor Issues: > === > > -4, 1st paragraph, last sentence: > I confused by the fact this sentence says nodes MUST include > HNCP-Version, then goes on to talk about nodes _not_ including it. I added a note that the presence of the TLV indicates the support for the currently defined HNCP version. The idea is that in case there are other DNCP nodes that speak a different HNCP version their information is still spread in the DNCP sense, but not interpreted. > -6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 address > and - if it supports IPv4 - MUST announce an IPv4 address," > I don't suppose there's any way we can make IPv6 a MUST? I guess we could unify both and make them both SHOULD or MUST. Right now I can't really remember the argument for or against either but I will discuss it with Markus. > -7.4, 2nd paragraph: > The MUST seems to conflict with the SHOULD in the third paragraph of > section 8. That conflict is ruled out by the MUST in 10.1 It MUST be set to some value between 1 and 7 included (4 is the default) if the router is capable of proxying MDNS and 0 otherwise. and the election mechanism. If it doesn't support an MDNS proxy (disobeying the SHOULD) it MUST announce its mdns-capability as 0 and thus will never be elected and never be subject to the MUST in 7.4. 2nd paragraph. > > -14.2: > It looks like some, maybe most, of the informative references need to be > normative. They are cited with 2119 language, cited in other protocol > definition, or are otherwise required to fully understand this draft: > 3004, 2131, 3315, 3633, 4291, 1321, 6762, 6763, 2132, 4193, 7084, 7217, > 4861, and 6092. Ok we will reevaluate the references in the coming days and see which of those should be promoted. > > > Editorial Comments: > = > > -4, 2nd paragraph: "Any node announcing the value 0 is considered to not > advertise the respective capability and thus does not take part in the > respective election." > > Am I correct to assume this means "any node announcing the value 0 for a > particular capability..."? Yes, clarified. > > - 5.1:"Internal category":"HNCP traffic MUST be sent and received." > What must send and receive it? (Similar comments for External Category). Changed to "The interface MUST (NOT) operate as a DNCP endpoint" > > -6.5: > Please expand "ULA" on first mention. Done. > > - 9, 1st paragraph: "The scheme SHOULD be used only in conjunction" > "SHOULD ... only" is a subtle way of saying SHOULD NOT. I suggest the > following: > OLD: > The scheme SHOULD be used only in conjunction... > NEW: > The scheme SHOULD NOT be used unless in conjunction... Staged for next revision. > > - 14.3: > Looks like neither URL will be cited once the RFC editor removes the > appendices marked for deletion. Okay, will try to see if we can convince xml2rfc to mark this section for removal somehow. Otherwise we probably need to manually modify the .txt Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Hello Kathleen, thanks for the review. > 1. I'm not clear on one of the bullets in section 3, > o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP > non-cryptographic hash function H(x). > > Is this meant to use a message digest (RFC1321) or a cryptographic hash > for authentication (RFC2104)? If it's the former, can you make this more > clear in the bullet? If it's the latter, can you update the reference > and the number of bits to use for truncation is 80 for the minimum. You > do explicitly mention HMACs later on for PSKs using SHA256, so maybe the > reference is correct and the wording should just be a bit more clear? I have staged this text now: HNCP nodes MUST use the leading 64 bits of the MD5 message digest as the DNCP hash function H(x) used in building the DNCP hash tree. I hope that makes it more clear, that the hash is only used for comparison and to detect changes, not as a form of signature or authentication. > 2. Can you explain why DTLS is a SHOULD and not a MUST? The bullet in > section 3 reads as if this is for use, not implementation. Is there a > MUST for implementation (I didn't see one, but maybe I missed that)? The basic idea behind the SHOULD is that there may be cases where either physical security of links (e.g. cables) can be ensured or link-layer security such as WPA for WiFi is present. In these cases (e.g. some sort homenet wifi repeater) the DTLS would be redundant. In the Security Considerations sections we currently have a requirement: On links where this is not practical and lower layers do not provide adequate protection from attackers, DNCP secure mode MUST be used to secure traffic. which should ensure that devices MUST use HNCP security over both physically and link-layer-wise unsecured links. I guess this could be reflected in the DNCP profile section as well if that makes it more clear. Would that work better or do you have something different in mind? > > Could you add a reference to RFC7525 to help with configuration and > cipher suite recommendations? This could be in section 12, security > considerations. Staged for next revision. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)
Hello Benoit, On 21.10.2015 16:12, Benoit Claise wrote: > Trying to answer the question "when not to use DNCP?", do I > understand > correctly that there is only one limitation: the 64kB > size Except that, DNCP is generically applicable. Really? No, that is not true. The applicability section also mentions e.g.: 1. "each node needs to be able to store the entirety of the data published by all nodes" 2. "As the [...] frequency of data changes per node increases [...] the benefit of using DNCP diminishes." 3. "If the TLV set published by a node is very large, and has frequent small changes, DNCP as currently specified in this specification may be unsuitable as it lacks a delta synchronization scheme to keep implementation simple." I'm not sure what other points could be added, however it intentionally is designed as a generic TLV-sharing protocol so its potential applicability is broad. Could you please provide some guidance on other factors we should evaluate in the Applicability section? We are currently feeling a bit lost on how we should address your concerns. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)
Hello Benoit, thanks for your feedback. I've staged the following additions for -12 in our Git: https://github.com/fingon/ietf-drafts/commit/859a37237 Would that address your DISCUSS? If not, please let us know what you would like us to add or change in addition. Thanks, Steven On 20.10.2015 22:41, Benoit Claise wrote: > -- > DISCUSS: > -- > > Other ADs focused on the protocol specific points. So let me focus on > something else. > The applicability section doesn't answer my questions: when to (re-)use > this protocol? > Note that the write-up mentioned ANIMA. > > I see the protocol description: > >DNCP is designed to provide a way for each participating node to >publish a set of TLV (Type-Length-Value) tuples, and to provide a >shared and common view about the data published by every currently or >recently bidirectionally reachable DNCP node in a network. > > However, this applicability section doesn't tell me when to re-use DNCP > (or define a profile for it). > I see an effort to address my discuss in the appendix B of draft version > 11. Thanks > > What would solve my DISCUSS is an applicability section that would > contain > a high level set of criteria that would briefly explain whether DNCP is > applicable for > the specifications I have in mind. The first 2 paragraphs of section 1.1 > is a good start, > then it goes considerations about Trickle, the interval A_NC_I, etc ... > and you lose the > readers. > > Something like: > >DNCP is designed to provide a way for each participating node to >publish a set of TLV (Type-Length-Value) tuples, and to provide a >shared and common view about the data published by every currently or >recently bidirectionally reachable DNCP node in a network. > >[As an example of what I'm expected, see below. > Btw, I have no idea if this text is correct or complete, but that's > besides the point] > >DNCP works with profiles in which you have the flexibility to > specify: >- the appropriate transport: the available options are TCP and UDP > (see >section appendix B for the tradeoffs) >- the transport security: TLS or DTLS, see appendix B). >- If service discovery is required, an optional multicast service can > be defined. >- TO BE COMPLETED > >DNCP is applicable to LAN, WAN, or even the Internet. >DNCP can exchange enterprise specific TLV or an IANA registry could be > specified >DNCP specific extensions are possible. >TO BE COMPLETED > >DNCP limitations: > - Data published limited to 64kB > - Doesn't work for SCTP, DCCP > - All devices in the network must be DNCP node? > - TO BE COMPLETED > > To summarize, I need the 2 min elevator pitch of when (not) to use DNCP. > > > -- > COMMENT: > -- > > - I would agree with Alvaro, when he wrote: "In general, I found the text > not straight forward or easy to understand." Potentially due to the > structure. > > - I hope that a document about manageability considerations (see > https://tools.ietf.org/html/rfc5706#appendix-A) will follow. > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)
Hi Alia, thanks a lot for your continuous reviews. I have staged a few changes in our Git to address your remaining issues. We will include it in a an upcoming version with fixes for other remaining blockers left in -11. See: https://github.com/fingon/ietf-drafts/commit/374a4a3 More replies inline below. Thanks, Steven > 1) End of Sec 4.4, can you clarify what the behavior is for > unrecognized TLV that is included in the Node Data field of a Node > State TLV? I assume that its meaning is not processed, but it is > included in the computation of the Node State Hash? Clarified. > > I've also read this draft too many times at this point to be certain that > I've picked up all the points of > unclarity. I've requested another Routing Directorate review, from a new > reviewer, so I may be modifying > my ballot again before the telechat on Thursday. Thanks. > > > -- > COMMENT: > -- > > I also have a few more minor comments that affect readability. > > 2) On p. 6, Definition of Peer means that the same DNCP node using a > different local and remote endpoint pair would be a different Peer?? > Is that intentional? Changed to "at least one". > 4) In Sec 4.5, it seems unfortunate to have old network and > connectivity state stored. It seems to me that it'd be fairly trivial > to describe a "polite neighbor" termination policy where a peer sends > an Node Data TLV for itself with no data in it - including Node > Endpoint TLVs. I am a bit nervous about bad side effects, but I do > not have a specific example to mind and obviously, a neighbor can fail > as well as gracefully shut down connections. Describing "polite > neighbor" > behavior may be too much of a technical change at this point, but I'd be > happy if you think about it seriously. I think there are legitimate cases where this graceful termination is redundant, i.e., because the derived protocol employs a transport or link-layer that provides such events already. Nevertheless I guess a derived protocol could probably with some care add such a mechanism where it makes sense. I'm a bit reluctant to add it as that stage really. > 5) In Sec 7.2.2, it says "This TLV contains the current locally > calculated network state hash, see Section 4.1 for how it is calculated." > This describes the value when sent. When received, it contains the > Peer's network state hash. Changed to "contains the current network state hash calculated by its sender" > 6) Please define H(...) in terminology, since Sec 7 uses it. Hmm, it is currently defined at the beginning of Section 7 just before the first sub-paragraph so I am not sure if it will add more clarity to also add it to the terminology. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
Hi everyone, here is some attempt to formalize a simple WiFi roaming approach using host routes and a stateless proxy for DAD NDP messages. It's a bit theoretical right now but may be useful as a start for a discussion. We could do a talk on it in Yokohama as well. Cheers, Steven On 16.10.2015 13:32, internet-dra...@ietf.org wrote: > A new version of I-D, draft-barth-homenet-wifi-roaming-00.txt > has been successfully submitted by Steven Barth and posted to the > IETF repository. > > Name: draft-barth-homenet-wifi-roaming > Revision: 00 > Title:Home Network WiFi Roaming > Document date:2015-10-16 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/internet-drafts/draft-barth-homenet-wifi-roaming-00.txt > Status: > https://datatracker.ietf.org/doc/draft-barth-homenet-wifi-roaming/ > Htmlized: > https://tools.ietf.org/html/draft-barth-homenet-wifi-roaming-00 > > > Abstract: >This document describes a mechanism to manage host routes and >statelessly proxy IPv6 Duplicate Address Detection messages between >multiple WiFi links to allow client roaming. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Hello Alia, thanks for your detailed replies and suggestions. We have just released a new version which should improve upon the issues you have raised. Please find some more detailed comments inline. Cheers, Steven > I understand that but there were still a number of gaps. For instance, I see > nothing > that describes how to compute the network state hash. I would expect a > section like: I refactored the hash-tree section and created two subsections "Calculating network state and node data hashes" and "Updating network state and node data hashes" to make it more obvious. I also added a reference to the profile section wrt. hash-function and truncation as you suggested. > The draft has "Topology graph the undirected graph of DNCP nodes produced by > retaining only bidirectional peer relationships between nodes." > > In Section 4.6, I think that you are describing how to create the topology > graph, > rather than "traversing it". Updated this section as well, changed "traversing" to "updating". Added some more clarifications and an xref to the hash tree section. > > "Sec 4.5.1 Initiating Neighbor Relationships > > A DNCP profile MAY specify a multicast address on which each DNCP node MUST > listen to learn about new neighbors. If multicast discovery is specified in > the DNCP > profile, then when a node starts, it SHOULD send a Node Endpoint TLV to the > multicast > address using ??UDP??. > > In addition to or instead of multicast discovery, a node MAY be configured > with a > set of DNCP neighbors and the associated interfaces to use. When a node > needs to initiate > a neighbor relationship, that node SHOULD send a Node Endpoint TLV to the > unicast address > of the desired neighbor. Note that security considerations may influence > whether the relationship > is established." > > "Sec 4.5.2 Destroying a Neighbor Relationship > > A node can destroy an established neighbor relationship, regardless of > whether that node initiated > or responded to create the neighbor relationship. A node MUST send a Node > State TLV that does > not include the Node Endpoint TLV with the neighbor's Node Identifier and the > associated link's Endpoint > Identifiers. A node MAY information> as part of > terminating DNCP. I updated the section on peers and renamed it to "Discovering, Adding and Removing Peers". It should now clarify the points that I think were not obvious based on your suggestions. > > > > >> c) It looks like the TLVs are sent one after another in a datagram or > >> stream across a socket. The closest I see to any detail > >> is "TLVs are sent across the transport as is". > > > > Section “4.2 Data Transport” says > >TLVs are sent across the transport as is, and they SHOULD be sent > >together where, e.g., MTU considerations do not recommend sending > >them in multiple batches. TLVs in general are handled individually > >and statelessly, with one exception … > > > > Could you please be more specific on what is unclear? > > > > The section states that TLV handling is stateless except for the one > exception > > which is explained, so otherwise it does not really matter in what > order > > they are sent or how you split them up onto datagrams (if that is your > > transport). > > > At a minimum, you should specify "in network order" for how the TLVs are sent. Do you mean that numbers are sent in network byte order? That is already defined in the section on TLVs. I created a cross-reference there. > It would be good to specify whether TLVs need to be sent in any particular > order. That was one of the intentions of the stateless parsing sentence, however I added an explanation inside brackets mentioning ordering. > It'd be nice for the receiver to know whether there's a way of seeing that > the last > TLV in the message has been received so it's easier to avoid doing work > multiple > times. There are no special resending requirements. Reliability is either provided by using a reliable transport or based on Trickle. Clarified that. > When does a node decide to use unicast transport? When does the node decide > to use multicast transport? There are some indications about what is sent, > but > not in a very normative way. It should be quite normative already. The only TLV that is regularly sent over multicast or that is actively sent (not as a reaction to another packet) is the trickle-driven Network State TLV (accompanied by an Endpoint TLV). The section on "Trickle-Driven Status Updates" has MUST-statements on which transport (mc or uc) to use. All other TLVs are sent reactively over unicast. I added another clarification. > > When and how does a node take into consideration MTU? I know this is tied to > the profile, but it needs to be discussed here. Can a TLV be broken across > multiple packets? Added that fragmentation and reassembly
Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Hello Alia, please find replies inline. Cheers, Steven & Markus > -- > DISCUSS: > -- > > First, I have a number of specific comments. Some of these are hazards > to technical interoperability; I've tried > to include those in my discuss - but the general point is that it is very > hard to tell a number of details because the > structure is assumed. Having read this document, I do not think that I > could properly implement DNCP from scratch. Please note that an independent DNCP (or more specifically an HNCP) implementation has been successfully developed based on an earlier version of this draft and has been shown to be interoperable with the reference implementation of the draft authors. We used the implementer’s feedback afterwards to further refine the draft to avoid possible ambiguities. > a) What is a topology graph? When is it created, modified, or destroyed? > Is it a conceptual artifact constructed > from the various TLVs? I think a quick paragraph describing it would > help. The term “topology graph” is defined in the Terminology Section and based on bidirectional peer reachability which is defined right afterwards. In the latter definition it is mentioned that the process is solely based on published TLVs so the topology graph is to my understanding already unambiguously defined. It is solely up to the implementer if this is implemented as an actual graph or not, as long as the outcome is consistent with what is described. If you still think it is ambiguous please provide some ideas on how this could be worded better. > b) How are peer relationships discovered and established and destroyed? > I really can't tell from the draft and even a quick scan of > RFC 6206 doesn't give any hints. This is explained in section “4.5 Adding and Removing Peers”. As for methods for discovery, this is actually mentioned multiple times across the document, e.g. in the second paragraph of the Overview or in the terminology. Could you please be more specific on what exactly is unclear here in your opinion? > c) It looks like the TLVs are sent one after another in a datagram or > stream across a socket. The closest I see to any detail > is "TLVs are sent across the transport as is". Section “4.2 Data Transport” says TLVs are sent across the transport as is, and they SHOULD be sent together where, e.g., MTU considerations do not recommend sending them in multiple batches. TLVs in general are handled individually and statelessly, with one exception … Could you please be more specific on what is unclear? The section states that TLV handling is stateless except for the one exception which is explained, so otherwise it does not really matter in what order they are sent or how you split them up onto datagrams (if that is your transport). > d) As far as I can tell, Trickle is used to decide basically how often to > send information - but the details of this and the interactions > aren't clear to me. This is explained in detail in section “4.3. Trickle-Driven Status Updates”. The Trickle state for all Trickle instances is considered inconsistent and reset if and only if the locally calculated network state hash changes. This occurs either due to a change in the local node's own node data, or due to receipt of more recent data from another node. A node MUST NOT reset its Trickle state merely based on receiving a Network State TLV (Section 7.2.2) with a network state hash which is different from its locally calculated one. Every time a particular Trickle instance indicates that an update should be sent, the node MUST send a Network State TLV… Could you please be more specific on what is missing here? > I suspect that there are dependencies on the HNCP draft that would make > this a lot easier to understand but since we want it to progress > separately, the document does need to stand alone. No, there are no dependencies. This was noted already in response to reviews from Thomas Claussen and Les Ginsberg. Please refer to section “9. DNCP Profile-Specific Definitions“ for the comprehensive list of things we have intentionally left out in DNCP. > 8) In Sec 4.6 " o The origination time (in milliseconds) of R's node > data is greater > than current time in - 2^32 + 2^15." Since origination time hasn't > yet been introduced, I'm going > on an assumption that it means when R's node data was originated from R. > So - this requirement is > saying that R's node data must have been generated in the future (but > already known by the local node)??? The term “origination time” is actually explained in Section “5. Data Model”, -10 will have a forward-reference here. About the time itself, the text says greater than “current time - 2^32+2^15”; that threshold is always in the past. > 9) In Sec 4.6 "They MAY be
Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)
Hello Stephen, thanks for your review. Please find some comments below. Cheers, Steven > -- > COMMENT: > -- > - 8.3 generally: I think this could be the basis for something > quite good but that'll only become clear really (to me) when I > go over it in a real protocol and not in the abstract. I'd > also speculate that you might end up changing this if it gets > more security review, but again that's hard to get in the > abstract. Basically: be prepared for changes as this is made > concrete Understood, the intention is to potentially have something better suited than PSKs or PKIs for cases like bootstrapping a (mostly) unmanaged home network. We are aware that this is probably a first slab at such an approach and might benefit from a few more eyes and practical experience. In any case, it is not substantial to the document and we would rather remove it if it would become a blocker. > - The write up notes various drafts were input to what became > this one. I assume that none of those had associated IPR that > hasn't trickled through to being noted as applying to this > one? If not, as I expect, that's fine, no response is needed, > I'm just noting this since I didn't see any "replaced by" > entries in the history and it's those that cause IPR to be > transitively visible. We are not aware of any IPR associated with those drafts, at least to my knowledge none was declared in the IETF IPR search. > - section 2 - it's not clear to me why all node identifiers > need to be the same length - some protocols using DNCP could I > guess have variable length identifiers. IPv4 and IPv6 and > Ethernet for example all have different lengths. Well, theoretically this is probably not a hard requirement, however the way we currently define our TLVs a variable length identifier here would require changing the TLVs to include a length field for it in some cases. I do not really see the big benefit of allowing this here so we will probably rather leave it as is. > - 4.2: seems to contradict itself. 1st para says that MC is > not used for anything sensitive, but 2nd-last para of section > says that network state TLVs can be sent "now and then." > (Reason to ask is that (D)TLS won't work if sensitive data is > sent via MC.) We do not consider the Network State TLV to be sensitive, since it is a merely a single hash-value over other hashes and a bit of metadata (see "Hash Tree"). The only reaction to the reception of a Network State TLV is triggering a unicast request to the originator (which whould then be authenticated and encrypted) using (D)TLS. We noted this in the Security Considerations already in the first paragraph and mandate rate-limitation of thereby triggered requests. > - 4.4, 2nd para: what is a "valid" address? A profile might e.g. restrict the transport to link-local scoped addresses or make other similar assumptions. I guess we will add a an example in -10. > - 8.1: do you mean one PSK per network or per pair of nodes? > Better to say. I assume it's the former. Well technically it could be either but in practice I'd think we'd assume it to be the former since latter is a bit impractical. > - 8.3: This is an example of (a fairly complex) use of > opportunistic security (RFC7435). Be good to note that. Staged for -10. > > - 8.3: Calling this "certificate based" is I think a misnomer. > I suspect all the same things could be done with raw public > keys (RFC 7250). Well most of it can, however there is one bit that somehow utilizes certificates: A node MUST be trusted for participating in the DNCP network if and only if the current effective trust verdict for its own certificate or any one in its certificate hierarchy is (Cached or Configured) Trust and none of the certificates in its hierarchy have an effective trust verdict of (Cached or Configured) Distrust In any case it could get a different name, do you have a fitting idea? > - 8.3: please do note that a concrete protocol might need > changes to this distributed algorithm and that this section is > guidance and not to be considered entirely fixed (when > coding). Staged for -10. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Barry Leiba's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)
Am 16.09.2015 um 15:32 schrieb Barry Leiba: > -- > COMMENT: > -- > > In the IANA Considerations, we would normally use a normative reference > to RFC 5226 to define the "Standards Action" and "Private Use" policies. > I suggest adding that. Thank you, we will address it in the next revision. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Hello Brian, thank you for your feedback. > -- > DISCUSS: > -- > > I have no objections to the publication of this document, but I do have a > couple of points that I want to discuss... > > * The spec says that all TLVs are transmitted every time any value in the > TLV set changes. Section 1 says that a delta synchronization scheme is > not defined. What is the justification for not using a delta > synchronization approach? The ordering of the TLVs needed to compute the > hash can be done at the receiver and a delta approach would minimize > bandwidth consumption. I think it would be useful to provide some > justification in the spec for the design decision made to not use a delta > synchronization approach. Delta synchronization was mainly omitted due to our intended goal of focusing on optimizing for simplicity and only infrequent and potentially larger (in relation to the whole dataset) state changes as noted in 1.1. Applicability. It is therefore not in the base draft, however it should not be too difficult for a DNCP-based protocol that is in need of such a feature (e.g. due to it being "on the edge" of DNCPs applicability) to add it as an extension. > * Section 4.4 says that all responses are sent unicast, even for requests > received via multicast over a multi-access medium. Was consideration > given to use multicast responses and supporting message suppression on > other nodes? Or, was the design decision made to ensure that all nodes > responded with their TLV set to the requester? Either approach may be > reasonable, but there is no justification given. There are multiple factors involved here. One important issue is that securing these multicast transactions is difficult and I don't even know if there is a standardized and deployed way to do this e.g. using (D)TLS that we use for unicast. This is slightly touched in 4.2. Data Transport and 10. Security Considerations. Another reason is that on some link types - such as Wifi - multicast transmissions can be disadvantageous and reducing their number can be beneficial in many cases. > * When responding to a multicast request over a multi-access medium, why > is the randomization of the transmit time only a SHOULD? I would think > that needs to be a MUST. I think this more or less depends on the type of link and its characteristics and the current state, so I'm not sure if a MUST is necessary in all cases. > -- > COMMENT: > -- > > 1. I think the mention of the trickle variable 'k' in section 1 is > gratuitous and causes confusion. Since the meaning does not really suffer we can simply remove the bracket "(ideally with k < 2)" if that makes it less confusing. > 2. Why does this document say (section 7) that the hash function is > non-cryptographic? Shouldn't that be determined by each profile? The intended meaning was really "not necessarily cryptographic", we might just remove the word "non-cryptographic" in that section if that makes it more apparent. 9. DNCP Profile-Specific Definitions provides some guidance on the choice of functions already and indicates that it can be either. Regards, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
> config interface 'vlan42' > option proto 'hnet' > option ifname 'eth0.42' > option mode 'auto' > option ip6assign '64' > option ip4assign '24' > > Note that this interface was created (using the LuCI web interface) > using the hnet protocol from the get-go; it's not a conversion of an > pre-existing interface using another protocol. I suppose the fact that > the ip6assign option is added should be considered a bug, then? Good to know, I will prepare a fix for the webinterface. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
Am 05.09.2015 um 12:24 schrieb Tore Anderson: > What I am starting to suspect is that OpenWrt's «IPv6 ULA-Prefix» > setting is orthogonal to the Homenet handling of the interfaces, and > that in order to get the full/correct «Homenet experience» I should > disable this setting on all my routers. It could perhaps be considered > a bug that the «IPv6 ULA-Prefix» is used to number interfaces set to > Homenet/HNCP mode in the first place? I'd appreciate it if you could > confirm whether or not this is the case. Do you by chance have "option ip6assign" still set in your hnet configuration sections? If that is the case, these should be removed then OpenWrt's ULA won't be assigned to those interfaces anymore. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
> Also, consider that the name collision issue ideally needs to be > resolved for the externally published names. We really don't want to > have topology dependent sub-domains appearing in the externally visible > zone. That said I personally don't believe there should be any unconditional publishing of internal names and service information to the outside / ISP. The external naming can of course leverage the internal one, but it shouldn't proxy any information outside that hasn't been explicitly acked by a human. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-09.txt
Hi everyone, this is HNCP revision 9. This version addresses the issues raised in the second WGLC. Changes include final adaptions to the latest DNCP version (updated TLV definitions, improved version handling), as well as clarifications to client configuration and naming. Cheers, Steven Am 31.08.2015 um 20:09 schrieb internet-dra...@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Home Networking Working Group of the IETF. > > Title : Home Networking Control Protocol > Authors : Markus Stenberg > Steven Barth > Pierre Pfister > Filename: draft-ietf-homenet-hncp-09.txt > Pages : 39 > Date: 2015-08-31 > > Abstract: >This document describes the Home Networking Control Protocol (HNCP), >an extensible configuration protocol and a set of requirements for >home network devices. HNCP is described as a profile of and >extension to the Distributed Node Consensus Protocol (DNCP). HNCP >enables discovery of network borders, automated configuration of >addresses, name resolution, service discovery, and the use of any >routing protocol which supports routing based on both source and >destination address. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-homenet-hncp-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
In general I think making unqualified names work is problematic. We'd need to add one search path entry per link which doesn't scale. Plus duplicates are not really handled deterministically. Cheers, Steven___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
Juliusz, Requires host changes. Out of scope. This is *complete* bs. While I would have expressed it in somewhat milder terms, I tend to agree with Michael. If HNCP gets massively deployed together with a naming protocol that is easy to implement, the host implementations will come in due time. The homenet architecture and / or charter say that for this WG host changes are to be minimized and in some areas completely out of scope. Furthermore, as Markus noted, the IETF has MDNS and stateful DHCPv6 (or rather RFC 4704) in standards track and these protocols are widely supported by all kinds of clients already. Bottom line: I'm not sure what problem you and Michael are claiming needs to be solved here or could be addressed by HNCP, us or the working group in some way. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On 08/28/2015 04:42 AM, Steven Barth wrote: Furthermore, as Markus noted, the IETF has MDNS and stateful DHCPv6 (or rather RFC 4704) in standards track and these protocols are widely supported by all kinds of clients already. So is plain old DNS. Then tell me how clients register their names using plain old DNS and how that is already widely deployed in client OSs. when there will manifestly be host changes to incorporate the brand new world of in-home naming. There is nothing brand new here, it worked on single links for years. In my non-HNCP network I can type: http://printer.lan or even just http://printer to reach my HP printer, because it told my router that its hostname is printer when it got the DHCP lease and my router populates the name into the DNS cache that all clients are using. Similarly I can use http://printer.local and my PC finds the printer purely using MDNS without any router intervention or I can even enumerate it on the local link using DNS-SD without knowing its hostname and without router intervention. If I were to hookup my printer to an HNCP network that implements all the SHOULDs from the naming and service discovery section, I can also enumerate it using DNS-SD when it is on a different link than I am (without knowing its name or location) and I could also call it directly by its name using plain old DNS if I know where it is, e.g. printer.lan.office.home (if the router is named office and the link lan). That is purely using existing technologies without any host changes and on top of that completely zero-conf for the DNS-SD part. If I want meaningful plain old DNS names of course I have to tell the router that it is called office and its ethernet ports are called lan and that the printer is just printer, but that issue you will probably always have with pure DNS. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
I agree. To me, no host changes must be required says that everything hosts can do today, they will still be able to do inside a homenet, without changing. But there is nothing that should prevent homenet from putting in capabilities that will provide a better experience for hosts that do change. Just so long as what's there doesn't break. It's a backward compatibility requirement. That's exactly the point. If my PC can discover my printer, media device etc. today if it is on the same link and we are introducing home networks with multiple links, I want this discovery to seamlessly work across links without needing to update my PC's operating system. Sure, nobody does hinder anyone from doing new cool and shiny stuff and inventing protocols which require host changes, but it doesn't absolve us from fixing the existing stuff. In the end it just means, we now have increased complexity because we have to both support the new and shiny and the old and boring and expected-to-still-work stuff. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
What does that mean for shncpd? I do nothing, and wait for the pixie dust to settle? If you feel motivated you could implement all the SHOULDs of HNCP naming and sd: 1. find (or implement) a DNS cache and populate it using the HNCP DNS and naming TLVs, and the recursive DNSs from the ISPs, then announce said cache to your clients using RAs and DHCPv4/v6 2. find or implement an MDNS hybrid proxy and hook it up to your HNCP implementation 3. implement stateful DHCPv6 and populate your DNS cache with the acquired hostnames Consider 2 and 3 bonuses :P ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP WGLC
Hi Douglas, it is a bit hard for me to decipher your mail or extract what is relevant wrt. to the HNCP I-D. Sorry for the delay. We were attempting to complete a security related draft on the topic. Are you preparing a generic draft on homenet security or is this specific to HNCP or DNS-SD? Do you have an ETA or can you share the relevant pieces for HNCP (can be in private to Markus, Pierre and me) upfront so we can address them in the next HNCP revision? We'd rather like to go ahead asap, that is probably release a new revision early next week, fixing all the things that came up during LC. Most of that is already staged in our git. A few issues may be a concern. The required support of UDP 4000 byte packets in Section 3 DNCP Profile suggests there may be a concern. Section 2.1.4. Amplification Issues of https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-00 describes considerations not covered in RFC6762, RFC6763 or RFC7368 when aggregate sizes of RRsets are overlooked, especially in such environments. I do not think amplification attacks wrt. HNCP are particularly relevant given you can mitigate them by using (DNCP) security. I also don't get the RRset thing? Are you referring to SD and Naming TLVs in HNCP or was this not intended to be relevant for HNCP? This section, as well as the Security Considerations section, does not ensure local resources are not externally exposed. Which section? RFC 6092 is supposed to be followed by edge routers as HNCP references 7084 and applies it to HNCP interfaces, however it might be a good idea to explicitly reference RFC 6092 in our own Security Considerations in 12.1. where we merely state A firewall perimeter is set up for the external interfaces without any further references. We might as well just do that. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
Hello Henning, Does HNCP somehow make sure that there is a route towards the prefix it distributes? While D/HNCP checks that there is a path of links, the routing protocol might decide that one of the links is too unstable/slow for traffic and does not use it for routing. What is the preferred way to deal with this situation? HNCP has the following requirement wrt. (applied) assigned prefixes: [...] each router connected to said [Common] link: MUST forward traffic destined to said prefix to the respective link. which should ensure that once traffic for a prefix reaches any router adjacent to a link where it is assigned, is delivered to the link. Everything else wrt. routing and interactions is more or less declared out of scope for HNCP. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
Hi Juliusz, How does a host announce its name and address to the Homenet? Just mDNS? Or are we planning a protocol to store the mapping within DNS? (I'm assuming no stateful DHCPv6, of course.) Since we mainly have to live with what is there today (and in the IETF), the obvious solutions are MDNS and stateful DHCPv6. Neither is 100% ubiquitous and implemented everywhere but combined they cover a variety of popular operating systems. Please correct me if I am wrong, but other alternatives would usually require host changes which is out of scope here. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
RFC 1001? Is that standards track? Nevertheless HNCP is hopefully soon :p To be more serious, I guess we might as well simply recommend MDNS since that is a standard and already deployed. DHCPv6 is probably more lightweight though (and even to me naming seems to be one of the few relevant usecases in a home scenario). Am 26. August 2015 14:37:35 MESZ, schrieb Juliusz Chroboczek j...@pps.univ-paris-diderot.fr: How does a host announce its name and address to the Homenet? Just mDNS? Or are we planning a protocol to store the mapping within DNS? Since we mainly have to live with what is there today (and in the IETF), the obvious solutions are MDNS Ok. and stateful DHCPv6. Over my dead body. Please correct me if I am wrong, but other alternatives would usually require host changes which is out of scope here. While we cannot mandate host changes, we can recommend host changes that improve functionality. Is there a suitable IETF Standards Track protocol that does that? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
Am 19.08.2015 um 13:31 schrieb Juliusz Chroboczek: What problem does the proxying business attempt to solve? And what does it use TCP for? And what about that? You need to tell the ISPs (via IGMP / MLD joins) which (global) MC groups someone in the net is interested in, so you need to replicate each (globally-scoped) join in the network on all your edge routers or at least the sum of all your joins. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [pim] New Open-Source PIM BIDIR (and more) implementation
If bidir-tree is required in home network, i think IGP based bidir-tree solution will be simpler than bidir-PIM, it uses unified protocol for both unicast and multicast. Also the home network scale is not so large, so the multicast group membership flooding through IGP protocol will not be an issue. The plug and play of IGP based multicast solution also will be better than the combo of unicast IGP + bidir-PIM. So i think the home network maybe the applicable scenario for IGP based multicast solution. What kind of protocols are you suggesting here and are they implemented anywhere? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
How do Homenet routers configure NTP? Just use the pool? Either use the pool or use one from an SNTP DHCP option an edge router received from an ISP and published in HNCP. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
Am 18.08.2015 um 19:45 schrieb Juliusz Chroboczek: That's too weak -- it also needs to take care to perform prefix assignment only once (although it will probably want to perform address assignment on both interfaces, especially if they're in ad-hoc mode), to run only one instance of RA and DHCPv4, etc. I'd really like to see it spelled out. How about adding In this case the respective interfaces MUST be treated as belonging to a single shared Common Link.? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP nits re DHCPv4
The problem is we can't rely on it since it is not widely supported by clients. Chicken and egg. If you put it in hnetd, the clients will come. Well, the thing is. Homenet is not really chartered for host changes and many believe that IPv4 support is sort of deprecated anyway. Yes there is, option 51; it's the time at which you unconditionally discard a lease even if you didn't manage to rebind it. I think there are some tradeoffs between decreasing T2 and decreasing the lease time, and I'm not sure I fully understand what they are. OK, Good to know. The requirement L-9 is modified, in that the M flag MUST be set if and only if a router connected to the respective Common Link is advertising a non-zero H-capability. The O flag SHOULD always be set. If I'm reading this correctly, you're saying that a Homenet router SHOULD implement stateless DHCPv6. That seems like a somewhat arbitrary requirement -- could you please explain the rationale? I think we discussed this already: https://mailarchive.ietf.org/arch/search/?email_list=homenetgbt=1index=4PT0dEjoh_rSVbxoqT8vHZho5_A ;) Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] What to do when we lose DHCPv4 election?
Am 17.08.2015 um 12:23 schrieb Juliusz Chroboczek: When a Homenet router was previously acting as DHCPv4 server for a link, and subsequently loses an election, should it: 1. remain silent; 2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or 3. NAK both DHCPDISCOVER and DHCPREQUEST? I think that #2 is probably correct Thanks. What after a renumbering event and the addresses that the client requests are no longer onlink? I'd like a precise reference, if that's okay. At first glance all 3 behaviors seem sensible, while 2 and 3 look more preferable. However I do not particularly remember all the implications. In any case I'm thinking of adding Routers which seize to be elected DHCP servers SHOULD - when applicable - invalidate remaining existing bindings in order to trigger client reconfiguration. as a generic recommendation. 1) do Homenet-aware DHCPv4 servers pick the same rfc1918 address spaces to give out? Not necessarily -- if there are multiple prefixes assigned to the link, the spec doesn't say which prefix is used by each server. (Shncpd uses them all, which I'm not sure is a good idea.) Electing a single DHCPv4 server for each link works around the issue. There is only one IPv4 delegated prefix at a time in an HNCP network. In case multiple IPv4 prefixes are announced, only the one published by the node with the highest node identifier is kept among those with a Prefix Policy of type 0 - if there is any. So as long as the Assigned Prefix for a link does not change the DHCPv4 pools stays the same. Individual DHCPv4 servers might use different algorithms to assign addresses from within the pool. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP -- almost no nits, yay!
Am 17.08.2015 um 13:37 schrieb Juliusz Chroboczek: I've just reread the current HNCP draft (version of 17 August, 10:51), and I have almost no nits. If anyone is interested, I've written up a few notes about shncpd's compliance on Thanks. Minor nits: Section 6.5: MUST NOT for ULA if global IPv6 available -- in the absence of explicit user configuration? I think you misunderstood the requirements text here. It only says, there may only be one locally generated ULA in the network (denoted by the absence of any prefix policy TLVs). It is not in any way coupled to having public addresses, it is even possible to have other delegated ULA-prefixes from e.g. VPN connections in parallel. Section 8: HNCP routers providing name resolving services MUST resolve these names to their respective IP addresses as if there were corresponding A/ records. This is not clear to me; what exactly should an HNCP node be doing? What naming services are being referred to? Does this apply to locally published names, or also to names discovered over HNCP? The sentence you quoted is referring to names announced using HNCP Node Name TLVs. Naming resolving services is described in the second paragraph of Section 8, I staged some small clarifications here. Section 11. If the CE sends a size-hint as indicated in WPD-2, the hint MUST NOT be determined by the number of LAN-interfaces of the CE, but SHOULD instead be large enough to at least accommodate prefix assignments announced for existing delegated or ULA- prefixes, if such prefixes exist and unless explicitly configured otherwise. I have serious doubts about this recommendation, it feels like there's a feedback loop somewhere, I wouldn't swear it doesn't diverge really badly. What about simply looking at the number of links in the Homenet? This is non-trivial in the presence of meshy (ad-hoc category) links. Though I agree that the current thing is a bit fishy, so more suggestions are welcome. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt
Hi Fred, a few comments: A host receives on-link prefixes in a Router Advertisement [...] to identify preference order among them Is there really a preference order? Also I think off-link prefixes are similarly usable for address assignment or DHCPv6, they are simply not on-link. apart from the fact that it is emitting Router Advertisements (RAs). - wasn't there also a router flag in ND at some point? anyway. One might expect that the routers may or may not receive each other's RAs and form an address in the other router's prefix. Funny enough in theory 4862 says The autoconfiguration process specified in this document applies only to hosts and not routers. Since the host derives fundamental default routing information from the RA, this implies that, on any network with multiple prefixes, each prefix SHOULD be advertised by one of the attached routers, even if addresses are being assigned using DHCPv6. Hmm, I don't really see the connection between prefixes and (default) routing information here, since for non source-dest-capable hosts the prefixes do not matter for routing. Or os this sort of a foreshadowing of 6724 Rule 5.5? A host SHOULD select a default gateway for each prefix it uses to obtain one of its own addresses. That router SHOULD be one of the routers advertising the prefix in its RA. As a result of doing so, when a host emits a datagram using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default gateway. The question is to which one (if there are multiple): this might be important for e.g. fail-over cases or if you want to dynamically optimize away that extra hop you mention. The direct implication of Section 2 is that routing protocols used in multihomed networks SHOULD be capable of source-prefix based egress routing, and that multihomed networks SHOULD deploy them. This confuses me a bit since Section 2 said Because there is no routing protocol among those routers and now suddenly there seems to be one? Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] What to do when we lose DHCPv4 election?
Steven Barth cy...@openwrt.org wrote: thinking of adding Routers which seize to be elected DHCP s/seize/cease/ ?? Of course. Looks like my English is still in vacation mode ;) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Am 10.08.2015 um 19:28 schrieb Fred Baker (fred): In any event, I would urge the HNCP design team to consider the cases, and either make an argument that making network routing more complex (BCP 84) has a benefit I'm missing and actually works without the rule, or change HNCP to not have each RA contain every possible prefix. After scanning the discussions here, is there anything in particular that people feel which we need to add or clarify in HNCP for that matter? It seems to me that the current behavior, i.e., potentially non-optimal router sending out the PIO and then relying on redirection / routing does not really break things. Optimizing the PIO sending might in theory be possible but - as pointed out - is probably very hard to accomplish in practice. In addition, as a personal note from my own reading, I'm not 100% convinced that hosts even following the next-hop tracking of 6724 would correctly react to potential handover of a PIO from one router to another since the definition is relatively vague. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RtgDir review: draft-ietf-homenet-hncp-07.txt
Hello Thomas, as you might have seen already, we pushed hncp-08 yesterday and dncp-09 the day before and for hncp the editorial changes have been quite big. Now please also find our detailed reply to the points you raised and, as usual, we tried to address them as best as possible. Thanks, Steven ( Markus) Comments: o This document is a profile for and specialization of draft-ietf-homenet-dncp, and has a normative dependency on that document. Note that I produced a RTG-DIR review of draft-ietf-homenet-dncp with several suggestions a short while ago, to which the authors recently responded with an updated document. I have not had a chance to review that update, and iterate with the authors, yet. I also note a RTG-DIR review by Les Ginsberg, as well as several points raised by Juliusz Chroboczek on the topic of draft-ietf-homenet-dncp, the resolution of which I believe may impact draft-ietf-homenet-hncp somewhat significantly. This is one reason for my summary (above) of Significant concerns... -- before this document can be processed, draft-ietf-homenet-dncp should be squared off. It is not, however, the only reason dncp is more mature now, so hopefully that has been covered. o As a general comment, the document would do well with a good editorial overhaul to bring consistency in language usage, consistency in 2119 terminology, coherence in defined terms and their definition, document structure, etc. Agreed. An effort has been made in -08 :) o Related to this, I found that the lack of a terminology section was unfortunate, and ended up -- for helping my own reading of the document -- making a napkin-terminology to refer to as I walked through the doc. (FWIW, I personally prefer the 2119-paragraph to be part of a terminology section, although that is a minor issue / personal preference). The words I'd suggest including, and defining, would be: o Node -- is that a router, a host, or both? Again, I was given to understand that HOMENET did not want to redefine host behavior, and so I believe that the right term would be router? Homenet is tasked not to cause _backwards-incompatible_ changes to hosts. While the design is such that it is enough for routers only to participate in it, and the e.g. routing and addressing experience should work, advanced hosts MAY also if they want to e.g. do their own routing and in that case they may also want to do automatic address assignment by themselves. The text now differentiates more clearly between nodes and routers and has appropriate terminology. o Privat Link - Common Link -- If you *insist* on having these concepts, then they definitely need a clear-cut definition here ; I would prefer, though, to not have those concepts. o External Interface o Internal Interface o Border o Border router Added terminology section. You import a lot of terminology from DNCP and from [I-D.ietf-homenet-prefix-assignment], and I found myself constantly hunting through to figure out which terminology was from where. Suggest adding a paragraph to the terminology section (assuming you make one) which recapitulates something like: Additionally, this document uses terminology from DNCP, specificially the terms XXX, YYY, ZZZ are to be interpreted as described therein. This document also uses terminology from [I-D.ietf-homenet-prefix-assignment], specifically the terms WWW, UUU, QQQ are to be interpreted as described therein. Reason being: when I came across a term (say Shared Link), I wanted to make sure that I understood what that was. So I went to the terminology section. Well, there was none. So I went to grep through this document. Didn't really find a definition. So I started looking through the references to see if there might be something that made sense. Fortunately, my guess of what I-D to
Re: [homenet] [ieee-ietf-coord] Despair
Am 7. August 2015 09:02:29 MESZ, schrieb Mikael Abrahamsson swm...@swm.pp.se: On Thu, 6 Aug 2015, Dorothy Stanley wrote: d) Additionally, most if not all AP vendors implement multicast - unicast conversion and use it as they see the need for it. Just for clarification, do you mean enterprise AP vendors or do you really mean most if not all AP vendors across the entire range? Can you give an example of a sub-100USD residential consumer wifi-router/AP that implements this? OpenWrt does and we have kernel patches in our repo and have that enabled by default but I am not sure if vendors who fork us chose to dis- or enable it. So can't say if any off the shelve ones do out of the box. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-ietf-homenet-hncp-08.txt
Hello everyone, this is the latest revision of HNCP addressing all the issue that have been raised during and after WGLC to the best of our knowledge. This is mainly an editorial overhaul to improve readability and clarity of the draft: https://tools.ietf.org/html/draft-ietf-homenet-hncp-08 Changelog: * Rewritten abstract / introduction * Added applicability statement * Added terminology section * Reorganized many sections to follow a more logical order * Centralized all TLV-definitions in one section and added general rules * Many more minor improvements We would like to thank all reviewers for the helpful comments that allowed us to have a very productive week of editing HNCP and DNCP (updated yesterday). Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
Am 05.08.2015 um 12:12 schrieb Mikael Abrahamsson: I was under the impression that HNCP/hnetd configured address+prefix on interfaces which is then picked up by the routing protocol when it looks at what addresses/prefixes are available on what interfaces. Am I wrong? No, you aren't. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
This is why I think it would be great if the deprecated prefix continued to be sent (in RA and HNCP) until its original valid lifetime expired. The problem is that the valid lifetime can be several years so I don't think that is very practical unless we want to also enforce an upper bound on announced lifetimes which is starting to feel a bit uncomfortable. That's why I think an upper limit like the 2h makes sense. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
If you're referring to RFC 7084's: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of either a) zero or b) the lower of the current Valid Lifetime and two hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. then this doesn't say to continue advertising for 2 hours. If the immediately-sent RA has valid = preferred = 0 (which is one of the permitted value combinations per the requirement), then I see no requirement for any subsequent RA to be sent that includes this prefix. Interesting, it was apparently changed in 7084. 6204 didn't have the 0 option for valid lifetime but enforced option b). Ok, learned something today. I guess I will add a sentence to HNCP to enforce the old behavior, so that is clear. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt
Recapitulating, I see basically two potential issues where we do not yet have resolution: oVersioning oAddress/Endpoint terminology We have changed the IANA section like this now: t11-31: Free - policy of 'standards action' should be used/t t32-511: Reserved for per-DNCP profile use/t t512-767: Free - policy of 'standards action' should be used/t t768-1023: Private use/t t1024-65535: Reserved for future protocol evolution (for example, DNCP version 2)/t This gives us 6-bits to play with later on (e.g. versioning, flags, etc.) and also a broader pre-defined range for DNCP and per-profile TLVs. We also did another rewrite of address and endpoint to make them less verbose. The following is what at least passed our internal review ;) cAddress/c can identifier used as source or destination of a DNCP message flow, e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport./c c /c / cEndpoint/c ca locally configured termination point for (potential or established) DNCP message flows. An endpoint is the source and destination for separate unicast message flows to individual nodes and optionally for multicast messages to all thereby reachable nodes (e.g., for node discovery). Endpoints are usually in one of the transport modes specified in xref target=dt /. Besides that all instances of broadcast should be gone now and have been, replaced by multicast or multicast enabled or similar since that seemed to be more accurate in most cases anyway. Please let us know what you think ;) Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] some IS-IS questions
If someone would like for some different concrete proposal to be considered, then I think they’d better propose it fast, so the Design Team can consider it. Since we went full-circle already at least once, there have been other efforts in the past to tame the beast for homenet. There was e.g. Christian Hopps' writeup in connection with the comparison draft back in March, e.g. https://tools.ietf.org/html/draft-mrw-homenet-rtg-comparison-02#page-5 https://www.mail-archive.com/homenet@ietf.org/msg04270.html I haven't compared those to David's in full detail yet, on fist glance David's variant looks a bit more detailed (references more extensions). I'm no expert here to evaluate what the actual differences are, at first glance, Christian's variant seemed to be a bit more traditional where as David's uses some more experimental extensions such as IPv6-transport and Point to Multipoint where as Christian also mentioned security extensions for authentication. While I'm glad about both writeups, I think there might be a need for consensus of the IS-IS experts about what should be in and what should be out to proceed in a sane manner (if there isn't already). Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt
a bit offtopic, it would be good to have IANA assign some port numbers soon, if they have not already. (?) DNCP is not the place for this since it is abstract and for that matter does not define any ports ever. We have to wait until HNCP is mature enough at least. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt
Hello Thomas, let me just quickly say, thanks again for your detailed reviews. Together with the others it helped us a great deal in advancing the draft to where it is today. We have put your HNCP-review and this follow up for DNCP on our todo, and will provide you with some detailed changes and replies once we are through. Though since this is post-IETF time we have to go through the piles on our desks and on top of that also holiday season, it will probably take some more time for the next revisions. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] some IS-IS questions
So when IS-IS talks about topology discovery, it's talking about router topology, with no knowledge of hosts or bridges or PHY technologies. I'm sorry, but in a home network, the router topology is really the least of my worries. Maybe to add some info from the HNCP front: HNCP also maintains a topology graph, so you will have a router topology independent of IS-IS in any case. Depending on how feature-rich your individual routers are (e.g. if at least one of your HNCP routers on a link runs an MDNS-proxy), you can enumerate all MDNS-capable devices on such links with the usual tools such as bonjour / avahi. Beyond that you would need to run special (custom) services on each link, to e.g. let you query DHCP leases and/or NDP/ARP information from a router on each link but that is probably even less specified. However as for really transparent and unmanged switches or bridges you usually found in homes and that therefore do not announce themselves in any way you are probably out of luck in detecting them. In short, I'm slowly coming to the following conclusions: 1. Whatever diagnostics / topology discovery mechanisms may exists in IS-IS are insufficient to be of any real use. So any argument for IS-IS based on the existence of such diagnostics is irrelevant. [But I can be swayed from this conclusion if someone can provide real info showing this conclusion is wrong -- in an IS-IS load suitable for homenet routers.] 2. Technologies that are not resilient against links that go up and down frequently and for no apparent reason are useless in a home network. These links are prevalent in the home network. And not just the wireless links. The powerline and even coax links are also subject to this problem. In my experience, these up-and-down links are The Number One Cause of home networking issues today. I agree here, the problem is usually, you would need stuff like ethernet carrier detection to actively detect issues but that is more often than not masked by some (internal) switch or NIC somewhere in the path. Beyond that its a timer / packet loss thing, eventually any routing protocol will detect a longer lasting link failure and reorganize. Mesh routing protocols should usually have an advantage here since intermittent failure or lossy links is stuff they are explicitly designed for and so most of them can explicitly or implicitly (e.g. through dynamic metrics / link costs) provide feedback about quality of certain links. Then again this is all between individual routers. If you have a funny link with transparent cross-medium bridges e.g. router ---ethernet--- switch ---powerline--- bridged-AP --wifi-- router and all is essentially one L2-domain and then some clients somewhere in the mix, it will be problematic in any case. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] On mif and classifying prefixes
(x-post mif / homenet) Hello everyone, little backstory: when I learned about the multiple interfaces problematic in homenet, I was introduced to it with the anecdote of smartphone apps with use over 3g, use only on wifi settings and at some point there was draft-bhandari-dhc-class-based-prefix-05 which sort of tried to define some generic properties (e.g. not for internet usage, usage is charged, ...) for prefixes as well as a (more or less?) opaque class identifier. Now that draft is expired for 1.5 years and mif seems to occupy that niche. So to my understanding (and what I got as feedback on the mic a few days ago), mif is (atm?) (exclusively?) about explicitly identified provisioning domains, and not about generic classification of prefixes and / or interfaces. That means: to actually use a provisioning domain I need to know the PVD-ID beforehand. There is no way for anyone not knowing the PVD-ID to guess what is inside, not even to the degree of this is (not) for internet connectivity. Ideally from what I would have expected is that my applications may actually want to cope with multiple unknown prefixes and select a suitable one based on some generic metric (e.g. high bandwidth or low latency or low cost etc.), or maybe even just the basic this is metered cellular connection vs this is unmetered broadband would seem to me as a good start. So is what I am asking for out of scope for mif? Am I supposed to collect a database with all PVD-IDs to know what's inside? Is there any other way to do this? At least to me this explicitly known PVD-ID case seems important but a rather small aspect of the whole classification of address prefixes matter, especially for what I think homenet is concerned. Cheers, Steven ___ 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] Questions about HNCP Section 7.2
In addition to the above -- shouldn't a prefix previously be announced with a lifetime of zero for a few minutes after it is destroyed? Yes, see RFC 7084 requirement L-13. In general you should follow RFC 7084, since HNCP says that these requirements apply (section 11). We only listed a few small adjustments to bridge the gap from single CE to a multi-router network. A few more such adjustments are staged for -08. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
It is my (possibly mistaken) understanding that the nature of an endpoint depends on the mode of operation. So why not use a more concrete definition? The definition just gets more verbose with every iteration, the underlying problematic is that it tries to unify different concepts that are usually not unified ;) Also, the reverse is true. The modes that may be used depend on the type of endpoint. I personally think the socket metaphor more or less fits: if you have a socket bound / connected to some global address, you just cannot do link-local multicast with it, though if you've bound your socket to a link-local address of an interface, you can probably use (link-local) mc as well as uc. What makes sense here of course depends on what you are trying to achieve, if your DNCP-based protocol is supposed to communicate to something a few (non-DNCP) hops away then using link-locals or allowing multicast mode is probably not sensible, for HNCP we don't need globally scoped unicast so for the sake of simplicity we define that endpoints must be mc-capable. In all modes, an endpoint identifier is an arbitrary non-zero integer that, at any given time, MUST uniquely identify a particular endpoint. Endpoint identifiers SHOULD NOT be reused too soon after a given endpoint ceases to exist, but if that happens, DNCP will reconverge after a short period of chaos. Yeah, I guess the reuse-clause makes sense. (I don't think that DNCP requires endpoint identifiers to be non-zero, but HNCP does, so you might as well make that a requirement of DNCP.) The terminology defines 0 to be reserved for internal purposes. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
Hello Ole, thanks again for your review and sorry for the delay. Please find replies inline. Cheers, Steven Markus Given that it is an Abstract protocol specification, that must be combined with a profile specification to be a fully implementable, it is somewhat difficult to predict if the specification is complete or not. Juliusz Chroboczek is writing an independent implementation, and I'd recommend incorporating the very informative replies the authors have made to his comments on the homenet list into the document. -07 already included some of them and we've staged a few more for -08. General comments: = = Replace no affiliation with Independent. If that's the case. Done. = It is unclear to me how multiple instances of DNCP is run on a link. Is that something that must be specified in the profile document, and each profile must support multiple instances? Given draft-stenberg-shsp, and the way it hijacks the HNCP profile, it appears that more formal multiple instance support would be needed. Hmm, I think this is up to the specific protocol. Reuse of profiles is in theory possible but for standardisation would require either one protocol updating the other OR distinct TLV-spaces. The latter sounds a bit awkward e.g. IANA-wise. In any case , when sharing transport details such as port numbers, then a shared registry would need to be done anyway. SHSP should probably not be seen as a good example here. Since DNCP does not define defaults here an extra identifier seems unncessary and could or should probably be specified by the derived protocol. = I can't help being left with the impression that fragmentation (section 6.3) is underspecified. Can fragmentation be left out of the protocol for now (and profiles requiring large TLVs can require a transport layer supporting segmentation and reassembly?) Agreed. = I do find the text on transport modes somewhat confusing, U, M+U and MulticastListen+U. I'd like to see more descriptive text Okay, we will prepare something for -08. Abstract: = OLD: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. NEW: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses Trickle and Merkle trees. DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol. Done. = Add a reference to Merkle trees? I'm not certain what would be a good source to quote here, maybe Merkle's paper from '87 or the ‘92 patent? At least there doesn't seem to be a really appropriate reference. Section 4.2: = This is confusing: o If using a stream transport, the TLV MUST be sent at least once, and it SHOULD be sent only once. I staged If using a stream transport, the TLV MUST be sent at least once per connection, but SHOULD NOT be sent more than once. for now. OLD: * If only unreliable unicast transport is employed, Trickle state is kept per each peer and it is used to send Network State TLVs every now and then, as specified in Section 4.3. NEW: * If only unreliable unicast transport is used, Trickle state is kept per peer and it is used to send Network State TLVs intermittently, as specified in Section 4.3. s/every now and then/now and then/ s/employed/used/ Section 4.3: = reference to rfc6206? All done. o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast. o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast. = What do an implementation do if the endpoint is not in M+U transport mode, and the unicast transport is reliable? Section 4.2 states If only reliable unicast transport is employed, Trickle is not used at all. for unicast mode and ML+U mode references that as well. (I do find the transport modes confusing, and I'm not sure I understand the MulticastListen mode). These modes, especially the listen one is only used for Dense Broadcast Link optimization. It is essentially the same as unicast, however the node listens for multicast traffic to detect the presence or abscence of a node with higher identifier on the underlying multicast-capable link. s/when using also secure unicast/when using secure unicast/ Done. Section 4.4: = What is meant by: link with shared bandwidth? I changed it to multiple access link for now, I think that makes it more clear. o Any other TLV: TLVs not
Re: [homenet] PREFIX-DOMAIN in HNCP
I still find the PREFIX-DOMAIN TLV confusing. Could you please confirm that the following is correct: 1. the PREFIX-DOMAIN TLV can only appear within a DELEGATED-PREFIX TLV; Correct. 2. if a DELEGATED-PREFIX TLV contains no PREFIX-DOMAIN, or if it contains a PREFIX-DOMAIN with Prefix Length = 0 (possibly among other such TLVs), then it MAY be used for assignment; otherwise, it MUST NOT be used for assignment; No, -07 currently says that locally generated prefixes (e.g. ULAs) and those with internet access are desired in the sense of draft-ietf-homenet-prefix-assignment (this is not standard normative language). Maybe we should ask Pierre what the actual normative translation to that is, my personal take is that desired means MUST assign unless changed by local policy. Anyway others aren't currently desired by default, i.e. except by policy. Thinking about that this might be too restrictive since we want to usually just pass on all information to clients by default. So consider this changed for -08, to all are desired by default. I'm currently considering a new type explicit or so which says that you must only assign prefixes from this is you can actually identify this by (manufacturer or administrator provided) local policy retaining that functionality. So you can still have special DPs which are only selectively assigned from. Also maybe this thing should be renamed to Prefix Policy TLV since this seems more accurate. 3. if a delegated prefix with non-zero domain is included within a prefix with zero domain, it still causes the (longer, smaller) prefix to be excluded from prefix assignment according to 6.2.1. It is intended as: Delegated Prefixes included within other Delegated Prefixes are ignored, as well as their nested options. I will make this more explicit. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
Am 07.07.2015 um 23:24 schrieb Brian E Carpenter: Your explanation is fine but the phrase and can therefore be used in fully autonomic as well as professionally managed networks still makes some big assumptions. How about and can therefore be used more widely than in unmanaged home networks? I would disagree here, the statement autonomic or fully autonomic is perfectly fitting for the kind of networks this algorithms can be used in. It can certainly also be used in professionally managed networks or do you see any reason why it cannot? This said, it does not necessarily mean that it is a perfect fit for all kinds of these networks, but nobody did claim that either. It is extensible though so there is no way to discard it for these usecases that easily. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] review: draft-ietf-homenet-dhcp-07
Hello Ole, hello Les, thank you both for your reviews. We will hopefully get back to you with a detailed reply and a list of changes we made based on your reviews by next week (due to vacations etc). Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP interaction with DHCP
What default routes should be announced to v4 clients? Just the one through the node serving as DHCPv4 server (and count on Redirects to optimise routing), snoop on the routing protocol and choose the best default router according to the routing protocol, or announce all the routers on the local link and trust the host to choose wisely? (On a related note, do you think that it is wise to snoop on the routing protocol and build something similar to the example in RFC 4191 Section 3.6?) This is what HNCP mandates: https://tools.ietf.org/html/draft-ietf-homenet-hncp-07#section-7.4 So most of what you mentioned was left out for the sake of simplicity. Now that I think of it we should probably add a MUST for a classless route for the IPv4 delegated prefix, at least in case there is no default route. What happens when a new router appears on the link, a new election is called, and the new router becomes the designated DHCPv4 server -- won't address collisions occur? Perhaps DHCPv4 service should be sticky, in the sense that a new election isn't called if the previously elected server is still alive. We had this discussion already months ago I think. From what I remember stickiness would solve this particular use case, but opens up others instead in case of e.g. merging or splitting links. I'm not sure if that discussion was on the list so you may find it in the archives or not. IIRC it boiled down to making one case worse in favor of another with added complexity on top. (With stateful DHCPv6, we could perhaps do something with RECONFIGURE, although I'm not sure if RECONFIGURE is able to force the client to choose a different server.) I only know of two implementations of dhcpv6 reconfigure on the client side so far, one is odhcp6c, the other is dhcpcd. Maybe this has changed meanwhile but to my knowledge nobody really does it. Funny enough RFC 7084 mandates it for routers on the client side, but I don't know how well that mandate is followed. Similarly I have yet to see a second (open source?) implementation of reconfigure on the dhcpv6 server side. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Border discovery without DHCP-PD
Reading Section 5 again, I don't see a way to force a link to be external without providing either stateful DHCPv4 or stateful DHCPv6-PD. HNCP mandates that manual configuration of interface categories MUST be possible. Should there be some stateless protocol one can run on a link in order to force all HNCP routers to treat the link as external? I don't think inventing yet another protocol makes sense here. What is your usecase here? Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Border discovery without DHCP-PD
One of the interfaces, say eth1, is connected to an IPv6-only network that doesn't do DHCPv6-PD. Another one is connected to an HNCP network, with some other router publishing an IPv6 prefix delegation. eth1 IPv6-only network - me - (HNCP network) - HNCP router with PD Since there's neither DHCPv6-PD nor DHCPv4 on the IPv6-only network, eth1 is detected as internal. Since there's an IPv6 prefix delegation, the HNCP daemon allocates a /64 to each link connected to each of its internal interfaces and starts sending RAs on eth1. I'm now sending RAs on a production network, with no way for the network administator to prevent that short of either (1) reconfiguring my router (and any other Homenet routers that might be connected to this network), or (2) enabling stateful DHCPv4 or DHCPv6-PD. I'm sorry, to me this seems a bit farfetched to blame this case on HNCP. If you would have connected any device that serves RA / DHCP on that interface you would have the exact same results. Since that can happen even with the HNCP router in place you would need to deal with it anyway. Plus if a rogue RA / DHCP on one link breaks your whole production network you probably have other issues besides that. Personally I don't see the point here, to add logic and complexity to address this in HNCP - it just looks like the wrong place to fix it unless the general consensus is different. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Border discovery without DHCP-PD
I don't think inventing yet another protocol makes sense here. What is your usecase here? Remember all the trouble we had with rogue RAs? An RA-killer protocol built-in from the start would have avoided all of that, so I'm thinking of an HNCP-killer protocol. Nothing complicitated, just react to any HNCP packet by unicasting an HNCP packet with a KILLER TLV. Periodic KILLER multicasts might be a good idea. If we don't do that, we'll gather a lot of bad press by breaking operational networks when stateful DHCP fails for some reason, with no easy way to work around that. Can you elaborate a bit more on the breaking operational network parts (not in the RA-sense but for HNCP)? I mean a concrete use-case or example of what would break or how? In general auto border discovery is a heuristic to increase user-friendliness, and it uses protocols that ISPs usually speak with us. At the moment it is also decoupled from HNCP in a sense that HNCP is only enabled after the interface category is determined to be internal. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Border discovery without DHCP-PD
My reading of hncp-06 is that we're supposed to do what you suggested (including continuous monitoring), except that no warning is logged if a DNCP adjacency is established over the external interface. Yes, there is continuous monitoring for new borders on all interfaces with automatic border discovery. Markus, Steven -- should DNCP synchronisation happen over the external link in that case? My reading is that it should, but I may have missed something. No, by default that does not happen, i.e. HNCP and IGP are not run on external links. However there is a _manual_ override in the form of the optional hybrid category. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
Hello everyone, this is HNCP revision 07 addressing comments mainly from Mikael, Juliusz and a few others as well as some updates to use the latest version of DNCP. Even though the WGLC is still running, we wanted to publish a new version before the IETF draft deadline for any further reviewers. There were mostly clarifications and additional explanations in this revision, though we changed the HNCP Version TLV to use version 1 in this revision. This was mainly to address behavior of the existing implementations. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
Well, even in the home, I still regard there being a need for at least SOME perimeter defense - at the moment I am leveraging the source specific routing information to establish clear paths within my network, and to then also block known to be problematic protocols originating outside it - like CIFS, and port 80/443/661 from the outside (way too many default passwords on way too many devices, like cameras), and for that matter, port 53... Well we are referencing normative language of RFC 7084 in HNCP, which means that RFC 6092 is a SHOULD for us and with that basically stateful firewalling. Heh. Well, is there any thinking over there about how to tie this into mdns or dns, sanely? Well MDNS is the node's own responsibility mostly. Since that is not really platform default everywhere we also specify naming based on hostnames acquired via (stateful) DHCPv6/v4 which is turned on in addition to SLAAC on routers that support it. Our reference implementation uses this - if ULAs are present - only for ULA addresses. With only SLAAC you cannot really do proper naming. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Concerns about HNCP
Hi Juliusz, thanks a lot for your comments. Replies inline. Cheers, Steven Packet format and transmission -- ### Port and IP Is a passive node allowed to use a non-standard port? If so, which TLVs are to be honoured from a non-standard port? I suggest: only requests, with NODE-ENDPOINT ignored. The draft - in its current version - does not really mandate that, so at the moment implementations must be ready to receive replies on the HNCP-PORT instead of the source port they used. I'm not sure if its worth it to change that. A passive node is not allowed to use global unicast (Section 3). Even when using security? HNCP only specifies link-local communication, i.e. any communication from non link-local addresses is ignored independent if security is enabled or not. ### Versioning HNCP includes a mandatory HNCP-VERSION TLV, that contains both an eight-bit version number (currently set to 0) and a set of capabilities. If a node does not recognise the version, it continues synchronising the data over DNCP, but ignores its contents. Unfortunately, as it is defined here, HNCP-VERSION is not likely to allow evolving the protocol, since it is impossible for a node to participate in both versions. I suggest simply renaming HNCP-VERSION to HNCP-VERSION-0, and expanding the Reserved field to the full 16 bits. Should the need arise to replace the protocol, we can always define a new HNCP-VERSION-2 TLV, so that a node can specify that it speaks HNCPv0 (using HNCP-VERSION-0), HNCPv2 (using HNCP-VERSION-2) or both (using both). This makes sense, we will change it in the draft. Prefix management - ### Prefix assignment policy is not specified There are a number of details that are not specified in the prefix assignment section. Should a router assign one prefix per link per external connection, one prefix per link per delegated prefix, just one per link, or is that a matter of local policy? If just one per link, since neither the delegated prefix nor the external connection TLVs carry a priority field, how can the network administrator cause one particular delegated prefix to be preferred (other than using the preferred time, with all the issues that this entails). Section 6.3.2 actually specifies when it is desired (in the prefix assignment sense) and that is usually one assignment per delegated prefix per (Common) link. Come to think of it since its a MUST there, we should probably add a stance like unless explicitly overriden by local choice. And should probably say that by default only locally generated and with internet access should be chosen. To allow for saner local policy choices we added the Prefix Domain TLV there, so you can attach a bit more meaning to a prefix. See below. If a node is assigning prefixes smaller than /64 (or /24 in IPv4), how does it prevent fragmentation of the available space? IIRC that is defined in the prefix assignment draft. ### Prefix Domain is not clear It is not clear to me what information the PREFIX-DOMAIN TLV is supposed to carry. I imagine that values 1-128 carry source-specific routing information (in which case this should be said explicitly, and the exact procedure for applying sources to routes should be described), but I have no idea what value 129 is supposed to mean. The prefix domain TLV is used to convey some meta-information about prefixes. The main intention is to be able to distinguish what the prefix actually is: i.e. is it locally generated, does it offer internet access, is it used to access a certain walled garden (i.e. company VPN, IPTV service etc.). There are several use cases here: * You may not want to assign prefixes from certain addresses to all links since your clients may choose a walled garden address to try to access the internet. (Clients only do very naive SAS) * Certain (e.g. IOT) devices may want to identify other devices of the same kind e.g. using the same cloud and reuse their connectivity to upstream. This was brought up as an idea at last IETF. * If you have a walled garden and know exactly whats on the other side you can fine tune your firewall to accept only packets from certain destinations. * ...? The encoding of prefix length is strange. Why not have one octet of type, one octet of prefix length, and then the prefix? Since we don't have prefixes longer than 128 why not use the remaining values for something more meaningful. Is this TLV allowed to appear multiple times within the same delegated prefix? If so, what is the meaning -- and, or? Or makes no sense to me really, so and. ### Unknown DHCP options in DELEGATED-PREFIX cause prefix assignment to fail If a DELEGATED-PREFIX TLV contains a DHCP4-DATA TLV which advertises an LPR server, and the local implementation doesn't know about the old Berkeley protocols, it will be ignored for prefix assignment Section 6.2.3). On the other hand, the
Re: [homenet] Concerns about HNCP
So it's essentially a vendor extension encoded as either an IP or a domain name? It is partly opaque if you are referring to that, but even for domain names you could find potentially clever uses like telling your resolver to use the associated DNS-servers for a special domain (only). I guess I should write the non-opaque usecases (e.g. firewalling, DNS) out. So unknown top-level options are simply forwarded. I'm still confused. If I'm not doing PD, am I not allowed to grab prefixes in a delegated prefix with unknown options? What should an implementation that doesn't speak DHCP do -- not even parse the DELEGATED-PREFIX sub-TLVs (which is what I do currently), or drop any delegated prefixes with any DHCP options at all? (I'm actually parsing DHCP, but only the name server bits.) Okay for more clarity (and note to self to make it more clear): DHCPV6/4-DATA can be contained in EXTERNAL-CONNECTION and / or DELEGATED-PREFIX. If it is in EXTERNAL-CONNECTION it contains the usual top-level options, e.g. DNS-Server, NTP server, what not. The HNCP implementation does not need to know every option here. If it is in DELEGATED-PREFIX then it contains special DP-specific options which MUST BE understood, e.g. RFC 6603. In DHCPv6 land these are not top-level options but contained within the OPTION_IAPREFIX DHCPv6 option. They are meaningful for prefix assignment and therefore cannot be ignored so you have to ignore that DP if you don't understand them. ### Domain name has no priority I suppose since we have a default value we might want to add that this MUST NOT be sent unless explicitly configured. I'd still like a priority field. It doesn't seem like it would add much implementation complexity. It seems unnecessary though if we actually define it that the source MUST be an administrator. If you think about silly vendor adverts in there, then these vendors might also just use the highest prio and then you would be back at the start. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-hncp-06 now in WGLC
Hm, regarding section 11, requirements for HNCP routers. How is that size hint calculated? Also, other kinds of behaviours like null-routing the delegated PD to avoid ping-pong routing when you receive packets for subnets currently not in use in the delegated prefix, where is that specified? I noticed it is actually a bit more tricky then I thought yesterday and adapted the text again regarding the size hint again since it is hard to actually calculate the number of /64s needed, given potential administrative policies and /127 links that were discussed here. The new requirement reads: If the CE sends a size-hint as indicated in WPD-2, the hint MUST NOT be determined by the number of LAN-interfaces of the CE, but SHOULD instead be large enough to at least accommodate prefix assignments announced for existing delegated or ULA-prefixes, if such prefixes exist and unless explicitly configured otherwise. The ping-pong avoidance is already part of RFC 7084 in the mentioned WPD-5, we just have to relax the requirement so that it not only allows traffic to prefixes assigned by the CE itself, but also to prefixes assigned by any other HNCP router, that's what the exception is aimed at. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Inconsistencies between hnetd and the DNCP/HNCP drafts
I've had two surprises trying to interoperate with hnetd. 1. nncp-06 Section 10 says that the Version is 0. hnetd sends and expects a version field of 1. 2. The same section says the following about versioning: Each node [...] MUST ignore (except for DNCP synchronization purposes) any TLVs with a type greater than 32 published by nodes not also publishing an HNCP-Version TLV or publishing such a TLV with a different Version number. However, this is not what hnetd does -- if there is no Version TLV or the Version is 0, it drops the node, which causes persistent desynchronisation of DNCP state, which causes repeated Trickle timer resets, which sucks. Good catch, I think we missed updating the software for these parts. The behavior you've seen sounds like what historic version of the draft said. I'll put it on our TODO. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-hncp-06 now in WGLC
Hello Mikael, thanks for your continuous feedback. Am 30.06.2015 um 14:41 schrieb Mikael Abrahamsson: 6.2.4 create an on-link route? What's an on-link route? Also, why is it a MAY that it doesn't create an address for itself to this prefix? An explanation and rationale here would be good. 6.2.6 The list of things to do there isn't clear to me. wait for them to be applied? Applied where? How? Using the HCNP Prefix Assignment Algorithm? In the RIB? It implies HNCP Prefix Assignment Algo afterwards, but this isn't clear to me. Section 11 about the MUST for RFC7084 compliance. What parts of RFC7084 must be implemented? MUSTs? SHOULDs? I just pushed an update to our drafts repository which should hopefully address your comments. Please see https://github.com/fingon/ietf-drafts/compare/c82f52d...c9f5b57 and let us know if you have any further issues. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] How to compute DNCP/HNCP node data?
Hi Juliusz, The glossary for node state should iirc say that hash function and size is defined in profile e.g. hncp. Profile recommendations section in dncp recommends sha-256. HNCP itself should also mention something in dncp profile. The hash function is used for both levels of the Merkle tree i.e. also for network state hash. DNCP specifies canonical form of node data as binary sorted so it should be all defined and unambiguous. Cheers, Steven___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-05.txt
Hi Juliusz, As mentioned previously, we did set up a wired HNCP network here in Paris last month, and it works beautifully (at least on wired links). I strongly support this work. thanks a lot for your (repeated) feedback and support. # Ad-hoc interfaces You don't define ad-hoc interfaces. From Section 4, it would seem that these are for non-transitive links with no prefix assignment (a la AHCP), but in that case some changes may be needed to DNCP, which I don't think will work on non-transitive links in its current shape. In any case, the purpose of this feature needs to be made explained to the naive reader. In it's current form the adhoc-interface category in-fact results in an assignment of a /64 per EACH adhoc-interface since the common-link is defined to only consist of the single ad-hoc interface (including potentially connected client-devices). An implementation can of course provide configuration mechanisms to turn off address assignment on a per-interface basis - independent of the interface being adhoc or not. # Border discovery What happens if there is a non-Homenet DHCP server on a link, but for some reason an address cannot be obtained from it (e.g. the server NAKs all DISCOVER/REQUEST messages)? My reading is that the interface will be considered internal, and therefore not firewalled. Is that the expected outcome? Your reading is correct. However since homenet routers also reject (or ignore) DHCP requests coming from other homenet routers, the situation would be ambiguous if the outcome was different. Also please note that the automatic border discovery is a best-effort heuristic to provide a good (zeroconf) user experience as also explicitly noted in the security considerations section. A router must in anyway provide means to set an interface to a fixed category of internal or external. # Policy needs review There is a certain amount of policy in Section 6.4 and in Section 7 that needs careful review by a competent third party. In particular, I'm not entirely comfortable with the IPv4 requirements in Section 6.4 (the IPv6 requirements look fine to my amateurish eyes). The IPv4-policy is a bit complex, yes. The reasoning behind this is that DHCP (and most client OS in general) do not really deal well with multiple IPv4-addresses thats why we make sure that there is at most one IPv4-prefix. There are other factors here, e.g. router's with global IPv4 connectivity having preference other router's that can only provide local IPv4 connectivity, etc. Section 7.1: I'm not familiar with DHCPv6, but is a preferred lifetime of 1s a good idea? Noted, I will change this in the next revision, the intention here is to keep fast renumbering working even with stateful DHCPv6. The given procedure is probably debatable and inferior to others, i.e. one might only hand out a lease for a ULA-based address and let global addresses be numbered using RAs only. Sections 7.2 and 7.4: why announce a route for each subnet? We've got redirects for that. I think you misread that. The text says to announce one route per delegated prefix not per assigned prefix. This is e.g. to allow differentiation of local and global connectivity. It is inherited from RFC 7084 which more or less mandates that (for IPv6). Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A few more DNCP nits
Thanks for the review. We just submitted https://tools.ietf.org/html/draft-ietf-homenet-dncp-05 and hope this versions addresses the remaining issues. Cheers, Steven On 02.06.2015 12:04, Mark Townsley wrote: Authors, We have reviewed your changes (just the diffs). Thank you for your efforts and the quick response to WGLC comments. We found a few nits of our own, would you mind including these in a quick -05 update? We will then hand this off to the ADs their review, IETF last call, and IESG review. Thanks, - Mark and Ray Terminology section - please delineate the terms from the definition. e.g., DNCP Profile: is a definition... We found the use of ()'s confusing. e.g., Effective (trust) verdict.. are the ()'s necessary? Something with data about most recent request(s) for network state - simplest one being a timestamp for the most recent request for network state (see Section 5.2). What is this something? This seems ambiguously worded. Section 4, and perhaps elsewhere in the doc now, suffers from a lack of delineation between the term being defined and the definition. What you had before was better in our view (with the articles, A, An, The...), but we are fine with you removing them if you make the terms stand out separately. Rather than Zeroed, can we say something like Padding (of value zero) ... Also, rather than These padding bytes MUST NOT beincluded in the length field. .. Of course you mean that the padding bytes must not contributed to the length field, or included in the calculation of the length field. But, that's not what the sentence actually says. Just above section 7.2, the pipe symbol used in the ascii art is in the wrong spot (16.5 rather than 16). Also, spurious with just before 7.2: for the node with matching node ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-05.txt
Hello everyone, as announced here is the latest version of HNCP. We would kindly like to request a WGLC for this as well. This one also already includes feedback for HNCP we got during the DNCP-LC, so thanks again for this. Draft URL: https://tools.ietf.org/html/draft-ietf-homenet-hncp-05 Notable changes since HNCP-04: * Renamed Adjacent Link to Common Link. * Changed single IPv4 uplink election from MUST to MAY. * Added explicit indication to distinguish (IPv4-)DPs for local connectivity and ones with uplink connectivity allowing e.g. better local-only IPv4-connectivity. Cheers, Steven, Markus Pierre On 02.06.2015 11:47, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Pierre Pfister Filename: draft-ietf-homenet-hncp-05.txt Pages : 30 Date: 2015-06-02 Abstract: This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-hncp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] FW: [hackathon] RIOT@IETF 93 Hackathon
As voiced earlier on this list it might be a good idea to have a homenet interop event with different routing protocol implementations etc. and I guess we could try to find ways to interop with IOT as well. I hope there is more demand for this here. Cheers, Steven On 01.05.2015 17:39, Charles Eckel (eckelcu) wrote: FYI, There will be an IETF Hackathon in Prague, July 18-19. We are in the process of determining the set of technologies included and are using hackat...@ietf.org for all discussions related to the hackathon. I thought this working group might be interested to work with RIOT and related technologies at the hackathon. If so, please subscribe the list (https://www.ietf.org/mailman/listinfo/hackathon) and participate in the discussions there. Cheers, Charles On 4/30/15, 1:02 PM, Matthias Waehlisch m.waehli...@fu-berlin.de wrote: Hi Charles, all, several people from the RIOT community (http://www.riot-os.org) will attend the upcoming IETF meeting and are pleased to work on IETF-related topics during the Hackathon. We plan to give an introduction to RIOT such that non-RIOTers can easily start with implementing their own ideas on this operating system for constrained devices. So far we have the following champions assigned to topics: (1) Lotte Steenbrink: update of AODVv2 (see draft-ietf-manet-aodvv2) (2) Hauke Petersen: CoAP for service discovery in the IoT (see draft-jimenez-p2psip-coap-reload) (3) Martine Lenders: general IoT network stack and boarder gateway between the IoT and current Internet (4) Kaspar Schleiser: ICN Anybody who is interested in working on these topics is more than welcome to join! If you have your own topic and want to implement this on RIOT, let us know in advance and we will tailor introduction etc. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net ___ hackathon mailing list hackat...@ietf.org https://www.ietf.org/mailman/listinfo/hackathon ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Actions
Hello everyone, we have just pushed dncp-02 which addresses the remaining open issues we had identified and that were brought forward to us. We - the authors - believe the draft to be complete now. Changelog: 1. Changed DNCP messages into series of TLV streams, allowing optimized round-trip saving synchronization. 2. Added fragmentation extension for bigger node data and for chunking in absence of reliable L2 and L3 fragmentation. 3. Various minor cleanups and clarifications On 05.03.2015 15:25, Ray Bellis wrote: Please provide further reviews for the recently updated draft-ietf-homenet-dncp and draft-ietf-homenet-hncp-04. We believe these are very close to ready for WGLC. We would kindly request doing a last call for DNCP since no further issues were brought up in Dallas nor in a subsequent call to the list ( https://www.ietf.org/mail-archive/web/homenet/current/msg05128.html ) Latest Draft: https://tools.ietf.org/html/draft-ietf-homenet-dncp-02 Cheers, Steven and Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] DNCP - open issues?
Hello WG, referring to my talk at the WG meeting: Does anyone still has open issues for DNCP? Anything we should improve for homenet? Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix-assignment-03 [Reminder - WG Actions]
PA is just a general purpose distributed numbering algorithm. The way you handle lifetimes is out of the scope of PA. But it surely is in the scope of HNCP (ietf-homenet-hncp). HNCP attaches the preferred and valid lifetimes to each delegated prefix, which are in turn provided to the hosts by the mean of RAs. In the make-before-break case, PA numbers the links with the new prefix before removing the prefixes associated with the old one. It let hosts renumber gracefully based on preferred lifetime values. Right. So the next question is: what will trigger HNCP to start this process? RFC 4192 seems to assume a guiding intelligence performing a careful sequence of actions. A variety of events are possible, in general HNCP references RFC 7084 here, i.e. homenet routers support DHCPv6-PD, the DHCPv6 dynamic reconfigure mechanism and in addition possibly 6rd as sources of IPv6 prefixes. So either of those usually or other events such as a link-down on an uplink interface etc. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-03.txt
I have read this draft. It looks very good. I agree (having reviewed probably all the various iterations of that document). I have the following questions: 1. What are the interoperability considerations if the node also contains (historical) configuration for acting as an RFC7084 router? Especially with respect to requirement L2 and L8. I think that is more of an implementation matter not so much draft-relevant. I mean sure if you design your OS from the ground up with that in mind that would be easy. However in the reference implementation we deliberately do not do that as that would require emulating a lot of OS-specific behavior. You can however replicate this configuration by defining the interface as hnet with mode=leaf (i.e. always internal, not connected to routers = doesn't speak RP nor HNCP on it) and you can give hnet a hint on what size and or id of the prefix you want to have assigned. As for L8 (running DHCPv6) hncp-04 has similar requirements, DHCPv6 behavior was at some point actually in the PA draft but it was moved to hncp I suppose for clarity reasons though Pierre could probably talk about this in more detail. 2. may/should/must a Homenet router that participates in the draft-ietf-homenet-prefix-assignment-03.txt also act as a proxy for an old RFC7084 router connected to one interface? This - as well - is defined in hncp-04 instead and we do this in the reference implementation. Internally the delegating router announces the DP on behalf of the legacy router using HNCP and inserts a local route. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Incremental Testing Deployment of HNCP and Routing Protocols
Hello everyone, I've written up a little transitional extension to our HNCP reference implementation. The intention is to be able to keep shipping HNCP with e.g. OpenWrt, to be able to test HNCP independently of or together with one or more routing protocols (e.g. for a future plugfest as suggested on the ML) and to be able to encourage people to play with it and get some early adoption and feedback without being blocked by a missing decision or lack of implementation of any chosen IGP. This extension is intended to be obsolete once the WG has agreed upon a routing protocol and once there is a reasonably deployable implementation of it that can be shipped with HNCP's reference implementation. That said the draft is purely informational and describes non-standard behavior of HNCP's reference implementation. It is aimed at implementers, integraters and testers and not intended for standardization unless there is explicit desire for that. Feedback is nevertheless appreciated from all parties. As for the reference implementation not much will change, we will still support source-specific babel and autoisis and - as noted in the past - I will still try to help integrate (and potentially package) any other homenet-ready routing protocol implementation that anyone desires. Draft: http://datatracker.ietf.org/doc/draft-barth-homenet-incremental-deployment/ Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Thanks for the quick reply. Looks like I will be having something to read on the plane to Dallas. On 02.03.2015 15:56, Christian Hopps wrote: On Mar 2, 2015, at 9:07 AM, Steven Barth cy...@openwrt.org wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The Decision Process (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Basically a trimmed down version is level-1 operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00
typically the ISP router snoops DHCPv6 messages and does route injection based on that, or the DHCPv6 server runs on the ISP router and does route injection based on binding state. I'm doing the latter at home since I don't have any native IPv6 here so I have a router doing 6in4 to he.net on the wan-side and it serves prefixes using DHCPv6-PD to the lan side. I regularly connect homenet routers to it or bridge a VM with homenet to the wired side for testing. OpenWrt's DHCPv6-server does that automatically if you assign a prefix larger than /64 to an interface (first /64 is assigned via RA/DHCPv6 to clients on-link, rest is avaialble via PD, routes are set up based on binding). Btw. HNCP specifies optional downstream PD from a homenet to legacy / stub-routers and our reference implementation should support that as well so its not all too offtopic for homenet I suppose. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCPD usability issues
On 22.02.2015 02:03, Dave Taht wrote: On Sat, Feb 21, 2015 at 3:51 PM, Ted Lemon mel...@fugue.com wrote: Is there an hncpd howto somewhere? Please see http://www.homewrt.org/doku.php?id=run-conf It is still up-to-date. The webinterface these days has some support for HNCP configuration as well. Just make sure to not use the names lan oder wan for any hnet. In the end its just as easy as installing the hnet-full package and adding a config section config interface homenet1 option ifname eth1 option proto hncp for each of your interfaces. I am not sure if the howto is entirely up to date - for example I hope they switched to using the standard openwrt ip6assign instead ip6_plen in the /etc/config/network file. Not yet. As for my relay issue in the previous mail, I think the sanest/fastest thing for me (as opposed to the hnetd folk) to do is write a generic udp relay program for ipv6, (there are many for ipv4, none I have yet found decrement the TTL. Sigh), rather than try to understand the codebase. As noted before option disable_pa 1 in the relevant interface config-section should actually just disable assigning prefixes to that interface. Alternatively as noted you can just change the prefix length to /80 or so. At some point we added support for assigning only a /128 to lo but I haven't actually tested it in a while and I don't think its in our unittests. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCPD usability issues
In the end its just as easy as installing the hnet-full package and adding a config section config interface homenet1 option ifname eth1 option proto hncp option proto hnet sorry, typo ;) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCPD usability issues
If the original interface-name was lan or wan you should rename them to something different (but do not need to change anything else). Additional note: Do NOT run DHCP or DHCPv6 manually (either server or client) on interfaces you run hnet on as this will cause confusion or worse. hnet takes care of anything DHCP(v6). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCPD usability issues
On 22.02.2015 09:38, Dave Taht wrote: OK, I think. So if I have a stanza like this? config interface 'lan' option ifname 'eth0.1' option force_link '1' option proto 'static' option ipaddr '172.21.80.1' option netmask '255.255.255.0' option ip6assign '64' config interface 'homenet1' option ifname 'eth0.1' option proto ´hnet' option disable_pa 1 that interface would act as a relay, and not assign a /64 to the lan interface? As noted please avoid assigning the names lan or wan to interfaces running hnet on, but besides that it's worth a try. I'm sort of on holiday for a few days, so I can try it out some time late next week. I note the last time I tried to install hnet-full it bricked the router, killing dnsmasq entirely, killing dhcp, etc, so I was leery of experimenting again... but I am willing to try again, being a glutton for pain at 1AM. Was this with CeroWrt? I'd recommend starting with a vanilla OpenWrt. moving on to more complexity, so getting that first 64 would look like? config interface 'lan' option ifname 'eth0.1' option force_link '1' option proto 'static' option ipaddr '172.21.80.1' option netmask '255.255.255.0' config interface 'homenet1' option ifname 'eth0.1' option proto 'hnet' option disable_pa 0 option p6_plen 64 ? Then getting a dynamic ipv4? Just removing disable_pa and (i)p6_plen will resort to defaults, i.e. 1 /64 per link for IPv6 and 1 /24 for IPv4. Moving into more functionality, I see the documentation recommends against using the hnet protocol on predefined interfaces like lan entirely... if I wanted ipv4 address assignment (and I dont - without dns to ip mapping actually working finding a box again is impossible), what happens to these two stanzas? The only reason to not use wan or lan is that OpenWrt's firewall has some special semantics for interface named after firewall zones. So you can just rename the sections and it will work. Or as you noted previously you can add an additional static-configuration section for the same interface (you just shouldn't name it lan or wan). How does the firewall pick it all up? hnetd tells the firewall which firewall zone (lan or wan) an interface should be assigned to. The zones depend on border discovery (manual or automatic). And then, there is the final caution to the winds, go pure hnetd option. This is my freshly built, openwrt chaos calmer based config file. It is an interior gw router (no nat): http://snapon.lab.bufferbloat.net/~d/network What changes are needed to drink the koolaid? For each interfaces you want hnet to run on add a config section. config interface homnet1 option ifname foo1 option proto hnet If the original interface-name was lan or wan you should rename them to something different (but do not need to change anything else). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon mel...@fugue.com: Hm, I will have to try it out. Is it in a distribution? ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. Manual configuration without hncp is a bit awkward since you need to name each link manually and on every router configure the resolver (e.g. dnsmasq). I guess we might want to provide a little example for 2 links at some point. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
So a quick poll: 0) Have you managed to get ipv6 working at all? If so, how? What sort of problems did you Yes. Most foss router software sucked with v6. Tried to fix some things. Still not 100% convinced. 1) Have you attempted to deploy a routing protocol in your home? Which one, and why? Well babels autoisis but only for testing purposes. My production network is still single link. 2) Have you attempted to get hnetd's prefix distribution system working? (it supports linux mainline and openwrt presently) Yes 3) Do you use ethernet? How many clients in your home are ethernet connected? 3 to 4 4) Do you use wifi? How many clients are wifi connected? Do you use range extenders? Yes. 5 to 8. No. 5) How many devices do you think you will have connected to the network in your home in 5 years? How many now? I guess 50-100% increase. 6) Do you use any other network connected technologies (homeplug, 802.14, LTE, etc). If so, which ones, and why? Does bluetooth count? Otherwise 3.5g as connectivity backup. 7) Do you use mdns service discovery? Seldom. When setting up my printer. Seldomly the .local resolving.___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
Am 20. Februar 2015 21:01:50 MEZ, schrieb Ted Lemon mel...@fugue.com: I'd be a bit curious to know what people are using for test hardware. That's a big issue for me. I have a WNDR3800 as an internal router, and a Mac Mini as my edge router, and haven't had time to really try to make HNCP and Babel work with them. Making IPv6 prefix delegation work on a stock Ubuntu device is not seamless. :/ Buffalo wzr600dhp with some bleeding edge openwrt w/ hnetd (hncp + dhcpv6pd) etc. as primary router + small number of wndr3800 and / or tplinks for testing openwrt and hncp. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 19.02.2015 10:00, Dave Taht wrote: hnetd exclusive of the library dependencies (which I could easily run a sloccount for, also, if you care) d@nuc-client:~/git/hnetd$ sloccount --personcost 11 generic src test openwrt SLOCDirectorySLOC-by-Language (Sorted) 12936 src ansic=12936 5806testansic=5806 417 generic sh=417 99 openwrt sh=99 As a rough estimate of those 12-13 KLOC only about one sixth should be related to DNCP. So I very much doubt that hooking it up to a 3rd-party daemon for topology/TLV-management would make any noticable impact. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I am not convinced by this; one of the issues I see here is that until DNSSD comes up with a solution, we are breaking service discovery on the home network by doing this. Granted, we already do that from Wifi to wired, but this seems gratuitous. There is draft-ietf-dnssd-hybrid-00 for which we have specified glued to HNCP and a reference implementation. I think DNSSD is actually mostly covered or are you referring to any specific issue of that solution? UPNP (SSDP) is a different beast though and would probably depend on having proper multicast routing. This is from memory but I guess Markus could elaborate here. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I was not proposing to use the HNCP TLVs for routing. Actually, I wasn't proposing to change the internal use of TLV movement much at all in HNCP, I was proposing to move them to IS-IS and use that to synchronize them instead of using the current transport. I do not see the fundamental difference in syncronizing TLVs between machines by means of HNCP (trickle based) and by means of a link state protocol (ISIS). One of the problems here I think is that it runs on L2, thus you cannot simply encrypt and / or asymmetrical authenticate it with anything like IPsec or (D)TLS. Therefore you would need to actually define, maintain and implement your own IS-IS specific TLS or IKE-like protocol which would actually add a lot more complexity than DNCP as a transport does. Actually one might even argue in the opposite direction that unless the IGP offers some fancy dynamic metrics based on e.g. bandwidth or reliablity etc., what would be the point of combining HNCP with a single-area LSP if you might as well do a simple graph traversal on the HNCP topology to generate routes? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
The Commission for Truth in Advertising requests that I mention that we haven't evaluated HNCP's behaviour in unstable and marginal networks yet. I agree, however this would need to be adressed anyway and irregardless of the chosen IGP that runs alongside it. I mean the IGP working but HNCP failing wouldn't really help the case. My point is just that I don't see much use in moving away from DNCP (and the current profile) as a transport for HNCP unless there is something better (i.e. supporting asymmetrical cryptography and encryption in a sane way and is proven to work in maginal networks). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Implementations of IS-IS
Out of interest: how is ISIS done on Linuxish devices? Grabbing ISIS packets off the link with libpcap? The Erlang version uses a PF_PACKET, SOCK_RAW socket. The alpha Quagga version appears to have three implementations: - on Linux, it uses a PF_PACKET, SOCK_DGRAM socket; I was aware that you can use that to *send* raw frames, but didn't know you could use that to receive as well (done via joining the [ethernet] multicast groups). libpcap is just the higher-level userspace interface to PF_PACKET on Linux. That said in any case you have to be a bit careful with PF_PACKET sockets and their settings especially if you use them to broadly (e.g. capture all L3 messages) your forwarding performance will go down even if you have a BPF-filter attached since the kernel has to copy / inspect a lot of packages. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Implementations of IS-IS [was: Routing protocol comparison document]
On 16 Feb 2015, at 12:44, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: If you know of any reasonably complete open source implementations of IS-IS other than the Erlang implementation and the (alpha quality) Quagga implementation, please let me know (perhaps by private mail), so I can mention them in -02. Actually, the Chairs would like to know of this too :) I think it would be equally interesting to see a specification of that homenet-variant/subset of IS-IS. The comparison draft is very vague on that front and judging by some on-list and off-list discussions there seems to be a lack of consensus for at least some of the details. I mean not (yet) having an implementation is one thing, but not even knowing what the protocol will look like doesn't really help here either. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Implementations of IS-IS [was: Routing protocol comparison document]
You mean what the TLVs look like exactly for the src/dst extensions to ISIS? Well not all too specific. I want to read or at least scan through the specifications that tell me how this homenet-variant of IS-IS would look like, i.e. what drafts / RFCs or chapters of these are relevant and which aren't. For IS-IS the comparison draft points me to RFC 1142 which seems to be the obsoleted OSI-standard and then straight to the auto-conf and source-specific drafts which doesn't really help (at least me) very much. For Babel I can read: RFC 6126 and draft-boutier-babel-source-specific about 50-60 pages and that seems to be it. What's the equivalent of that for the homenet IS-IS variant? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks for writing up the document. As a general comment: I think it should be added that there is a huge difference in building enterprise routers and home routers in terms of budgets for development / support and margins. This should somehow reflect in the complexity of the specifications and reference software we choose or produce in this WG. A few more specific ones. wrt. Link State Algorithm This information can be used by other applications outside the routing protocol itself. Additionally the flooding algorithm has been found as an efficient method for other applications to distribute node-specific application data, although some care must be taken with this use so as not to disrupt the fundamental routing function. Is this relevant for the homenet case, since this additional information (Prefix Assignment, Naming, Security, etc.) is exchanged using HNCP already? wrt. Algorithm Comparison Loop-Avoiding Distance Vector [...] scales badly in extremely dense deployments, where a single node has thousands of direct neighbours Are thousands of direct neighbors relevant for the homenet usecase? In general if we are talking about 100-200 routers here we've built OLSR and BATMAN mesh networks in that range with WRT54GLs and similar devices back then. wrt. Link Metrics Do the protocols assign any metrics by default (e.g. based on link speed / delay / reliability)? For Babel it is mentioned that it does so for WiFi however is there a generic case? Does IS-IS do something similar? I mean in the end what good does a 16-bit or 24-bit metric space do us in a more or less unmanged environment if all hops cost the same by default unless otherwise configured? wrt. Security Features We should just state whether each protocol supports auth or encryption, and whether it supports symmetric or something more exciting. I agree. To my knowledge it seemed that none of the protocols supported encryption or asymmetric authentication. While we can manage PSKs in HNCP to solve the authentication issue we might want to mention the potential insight that someone might gain from sniffing the unencrypted traffic of either routing protocol. wrt. IS-IS all major router vendors implement IS-IS As all major routing vendors have (proprietary) IS-IS implementations Is this really true for home router vendors? I don't doubt it is for enterprise routers but really the only routing protocol I've seen in home router firmwares so far is RIP and even that only in very few cases. Somewhat related: is source-specific routing in general deployed anywhere in the enterprise (or similar) space already? Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-03.txt
hncp-03 concludes our series of rewrites. This version has been refactored to be based on dncp-00 and specifies the parameters of a DNCP profile, thus low-level protocol interactions, and security measures can now be found in the dncp-00 draft. The hncp-03 draft itself still contains all the homenet-specific TLVs (prefix assignment, naming / service discovery, dhcp election), the border discovery algorithm (and its security implications) and additionally requirements and rules for running RA, DHCP servers and MDNS proxies and generic homenet router requirements such as the use of a TBD routing protocol to replace routing protocol election and the so called fallback routing mechanism. We hope the draft is now easier to understand and we hope that you all give it a read and provide feedback and input. Cheers, Steven On 06.01.2015 15:25, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Pierre Pfister Filename: draft-ietf-homenet-hncp-03.txt Pages : 29 Date: 2015-01-06 Abstract: This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-hncp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for Routing Protocol
As in the past, there was strong support for choosing a MUST Implement routing protocol for all Homenet routers and that candidate routing protocols must have an open source implementation available that can be demonstrated to work in a Homenet alongside HNCP. There was also strong support for setting a hard date, likely early 2015, to make a decision. Since we are sort of in early 2015 now... The two currently available routing protocols are IS-IS and Babel but at this point there is no consensus on which is preferred, and other protocols may emerge during the ongoing discussion. Margaret Wasserman has volunteered to work on a draft comparing the two. @ Margaret et al. do we have any updates on this matter or any ETA for a draft? Is there any additional help needed at this point? Regards, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Queries on draft-ietf-homenet-hncp-02
oooh - there's a way to get my attention:-) Is that saying that HNCP used have some asymmetric crypto that wasn't implemented and that's going to be cut from the spec? It had stubs for TLVs for that matter but never a concrete specification. We eventually decided to drop it since (re)inventing assymetric crypto in-protocol would have been a nightmare to specifiy, implement and maintain correctly and would have easily gotten more complex than the state-synchronization protocol itself. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
