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] 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] 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 1
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] 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] 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] 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 is
Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Hello Benoit, in addition to the new appendix in -10 we have now staged the following text for the next Revision https://github.com/fingon/ietf-drafts/commit/fa712e2a2935fe3f4b6383582913ca6f4bc9e9f0 Does this address your issue or do you think we should add further applicability explanations. PS: Sorry for the resend i screwed up my mail client earlier. Thanks, Steven Am 17. September 2015 17:22:55 GMT+01:00, schrieb Benoit Claise : >Markus, > >Instead of focusing on the specific questions/answers, the key message >is. >The applicability section doesn't answer my questions: when to (re-)use > >this protocol? > >Regards, Benoit >> On 17.9.2015, at 12.11, 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. >>> >>> I see, under the applicability section, under which conditions to >use >>> it. >>> Basically, suitable to exchange any TLV tuples, infrequently. >> This is the gist of it. Even more frequently is ok, but then you have >extra complexity without gaining from it. >> >> _That_ is what you have to determine if you want to use it; do you >want to synchronize a small set of TLV tuples, communicating >efficiently, across a set of nodes. >> >>> However, this applicability section doesn't tell me when to re-use >DNCP >>> (or define a profile for it). >>> What about the environment: home network versus LAN versus WAN? How >big >>> can the network be? >>> Does the technology matter? >>> Regarding transport, it's basically any transport, unicast or >multicast, >>> right? (DNCP can be used in networks where only unicast transport is >>> available. While DNCP uses the least amount of bandwidth when >multicast >>> is utilized) >> Guesses are correct, but given it is more of an algorithm than >concrete protocol, your questions are hard to respond in a generic way. >> >>> All devices in a DNCP network must be DNCP node? >> It is actually definition of DNCP network ; a set of DNCP nodes. >> >>> I have a DNCP network with profile 1, can I use the same DNCP >network >>> with profile 2? >> If the profiles’ transport details match and use a shared IANA TLV >space, then yes. >> >>> IANA and enterprise specific TLVs? >> I am not sure what you mean by this; ultimately actually used TLVs >are matter of (DNCP profile specific) IANA sub-registry, which should >reserve the space. While DNCP itself reserves some space for >DNCP-specific extensions (so far considered fragmentation, delta >synchronization, authentication/confidentiality of multicast traffic >using PSKs, and few other things), and leaves most of space open (for >e.g. to be used as bits later on), the rest is up to profile. >> >>> UDP is fine as a transport? >> There is another DISCUSS on this, I will reply to it there. >> >>> What if I know my topology already (I see later: "may use multicast >for >>> Trickle-based shared state dissemination and topology discovery") >>> etc. >> You can define a protocol that is solely TCP unicast based, for >example, and make it’s definition of peer liveliness depend only on the >TCP connections +- knowledge of topology graph changing. >> >> (This assuming you know which nodes need to communicate with each >other.) >> >>> Just reading the intro and the applicability, I scratched my head: >it's >>> so generic, should I even consider it for ANIMA? >> Funny, I get the opposite impression reading ANIMA mailing list, as I >wonder if it is too generic for DNCP. >> >> E.g. what if someone wants to share a DVD image to upgrade their >routers using the protocol? DNCP is _not_ the way. URL + hash of >content, or magnet link, perhaps, but not the image. >> >>> A few paragraphs, somewhere in the document, would solve my DISCUSS: >>> - this protocol should be used to exchange the following type of >data >>> ... >> See edit of first sentence of introduction in [1]. Still work in >progress, but emphasizing that a) set of TLVs published by a node is >small, and b) it has hard cap of 64kb. >> >>> - it's envisioned that this generic state synchronization protocol >will >>> be used in the following environments … >>> - potential DNCP-based protocols include … >> I do not really see where to stick these or what the exact content >would be; >> >> ‘anywhere you can use _a_ transport protocol’, ’to synchronize stuff >(home automation? configuration?
Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Am 17. September 2015 17:22:55 GMT+01:00, schrieb Benoit Claise : >Markus, > >Instead of focusing on the specific questions/answers, the key message >is. >The applicability section doesn't answer my questions: when to (re-)use > >this protocol? > >Regards, Benoit >> On 17.9.2015, at 12.11, 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. >>> >>> I see, under the applicability section, under which conditions to >use >>> it. >>> Basically, suitable to exchange any TLV tuples, infrequently. >> This is the gist of it. Even more frequently is ok, but then you have >extra complexity without gaining from it. >> >> _That_ is what you have to determine if you want to use it; do you >want to synchronize a small set of TLV tuples, communicating >efficiently, across a set of nodes. >> >>> However, this applicability section doesn't tell me when to re-use >DNCP >>> (or define a profile for it). >>> What about the environment: home network versus LAN versus WAN? How >big >>> can the network be? >>> Does the technology matter? >>> Regarding transport, it's basically any transport, unicast or >multicast, >>> right? (DNCP can be used in networks where only unicast transport is >>> available. While DNCP uses the least amount of bandwidth when >multicast >>> is utilized) >> Guesses are correct, but given it is more of an algorithm than >concrete protocol, your questions are hard to respond in a generic way. >> >>> All devices in a DNCP network must be DNCP node? >> It is actually definition of DNCP network ; a set of DNCP nodes. >> >>> I have a DNCP network with profile 1, can I use the same DNCP >network >>> with profile 2? >> If the profiles’ transport details match and use a shared IANA TLV >space, then yes. >> >>> IANA and enterprise specific TLVs? >> I am not sure what you mean by this; ultimately actually used TLVs >are matter of (DNCP profile specific) IANA sub-registry, which should >reserve the space. While DNCP itself reserves some space for >DNCP-specific extensions (so far considered fragmentation, delta >synchronization, authentication/confidentiality of multicast traffic >using PSKs, and few other things), and leaves most of space open (for >e.g. to be used as bits later on), the rest is up to profile. >> >>> UDP is fine as a transport? >> There is another DISCUSS on this, I will reply to it there. >> >>> What if I know my topology already (I see later: "may use multicast >for >>> Trickle-based shared state dissemination and topology discovery") >>> etc. >> You can define a protocol that is solely TCP unicast based, for >example, and make it’s definition of peer liveliness depend only on the >TCP connections +- knowledge of topology graph changing. >> >> (This assuming you know which nodes need to communicate with each >other.) >> >>> Just reading the intro and the applicability, I scratched my head: >it's >>> so generic, should I even consider it for ANIMA? >> Funny, I get the opposite impression reading ANIMA mailing list, as I >wonder if it is too generic for DNCP. >> >> E.g. what if someone wants to share a DVD image to upgrade their >routers using the protocol? DNCP is _not_ the way. URL + hash of >content, or magnet link, perhaps, but not the image. >> >>> A few paragraphs, somewhere in the document, would solve my DISCUSS: >>> - this protocol should be used to exchange the following type of >data >>> ... >> See edit of first sentence of introduction in [1]. Still work in >progress, but emphasizing that a) set of TLVs published by a node is >small, and b) it has hard cap of 64kb. >> >>> - it's envisioned that this generic state synchronization protocol >will >>> be used in the following environments … >>> - potential DNCP-based protocols include … >> I do not really see where to stick these or what the exact content >would be; >> >> ‘anywhere you can use _a_ transport protocol’, ’to synchronize stuff >(home automation? configuration? cache synchronization? routing? you >name it, this can do it, although not necessarily well, and all have >_already been done_ although not necessarily documented in the IETF)’ >> >>> >-- >>> COMMENT: >>> >-- >>> >>> - I would agree with Alvaro
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 r
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] Host naming in Homenet
> On 01/09/2015 01:06, Mark Andrews wrote: >> >> Why is topology being forced into the naming? DNS is independent >> of topology. We have *a* home. I really don't care what link my >> printer is connected too. It is not something I want to see in its >> name unless I put it there. > > No-hat: > > I'm very much with MarkA on this one. > > I want my devices to have a persistent name identifier, regardless of > which part of the topology they happen to be plugged into at the time. > > I wouldn't mind if the "canonical" identifier happens to be topology > dependent, so long as there's some mechanism (e.g. CNAME) to > automatically map the persistent identifier to the topology-dependent one. Please consider the following thoughts in no particular: * In each "zone" collisions need to be handled gracefully. ** Also: there can be legitimate reasons for having devices with the same (per-link) name in different parts of your network and if you do service-discovery it can even be useful to know where the device you found is located / what it is connected to (e.g. printer.ethernet.office.home vs. printer.wifi.children.home) * We currently have 2 sources of names from devices: MDNS and DHCP(v6), it is complicated to extend them from their natural per-link to a multi- link scope. ** MDNS does conflict resolution per link, extending it to multiple ones is problematic (c.f. draft-ietf-homenet-hybrid-proxy-zeroconf-00#appendix-C) ** Implementing multi-link hostname conflict resolution in DHCP(v6) servers sounds very painful (besides there are enough people already that don't even want to have stateful DHCPv6 by default). * Having full-blown DNS-servers supporting zone transfers etc., on each and every router puts a huge additional burden on implementers, personally I don't see having a bind9 or similar on every router as very realistic or desirable. For some schemes a single one per network might but enough, but that would put the burden on the user to know, care and buy / install the "one". * As noted by someone else in this thread, (most) users don't know about or actively use hostnames, so indiscriminately publishing all of them in a top-level zone and syncing them across the network might not be worth it. ** Many auto-generated hostnames are very opaque (e.g. foobar-a18cb3) and without additional service discovery information are relatively useless to a user, in presence of service discovery information though the names become less relevant. ** All that said, HNCP is already suitable to publish top-level hostnames under .home, for a selected set of devices. Resolutions for some or all of these issues are of course welcome. Cheers, Steven ___ 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
>Now could we achieve this in a multi-link Homenet without any >elections? The primary purpose of the election is to avoid having multiple different zones and names for the same link. It's not so much an issue of running multiple mdns proxies but mainly to avoid duplication. That's why the first tie breaker in the election favors routers that also offer other services as to centralize mdns and dhcp-fueled naming on a link. Cheers, Steven ___ 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
> 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
> If you don't like the idea using the NODE NAME TLV to announce DNS > information of the local hosts, how would you do it without a central > server configured by a network admin? What we currently have defined and implemented is this: Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Common Link (Section 6.1) for which it is the designated DHCPv4, stateful DHCPv6 server, MDNS proxy, or for which it provides forward or reverse DNS services on behalf of connected devices. This means that we don't use a central server, but each HNCP router (or well one per link) SHOULD offer name resolution for that link and announce a name (e.g. lan1.router1.home) using an HNCP TLV. Under that zone it places hostnames acquired via DHCPv4, DHCPv6 (or other methods). If it runs an MDNS hybrid proxy (dns->mdns querier) it also announces the zone as DNS-SD browsable using a flag in the TLV. The hybrid proxy itself issues an MDNS-request for each DNS-request it receives for the specific link and collects and aggregates all MDNS-replies and sends them back to the originator of the DNS-request. Each HNCP router SHOULD provide a recursive name resolution server which honors the announcements made in Delegated Zone TLVs (Section 10.5), Domain Name TLVs (Section 10.6) and Node Name TLVs (Section 10.7) Now this finally ensures that if you - as a client - are connected to an HNCP router you can resolve all client hostnames (laptop.lan1.router1.home), HNCP hostnames (router1.home), and enumerate all DNS-SD domains announced by any HNCP routers. DNS-SD clients already send requests to all DNS-SD browsable domains (i.e. all hybrid proxies in your homenet) on their own. If you client speaks DNS-SD, like most Linux, Android & Apple devices do (and Windows with additional software), you can thereby enumerate MDNS-capable devices and services on links which announce a hybrid proxy. So this is all zero-conf basically but your implementation should let you fine-tune it, e.g. change link and router names to something more elegant so your hostnames are like printer.lan.office.home, or tv.wifi.bedroom.home) and should let you add manual hostnames (using Node Name TLVs) like nas.home. ___ 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
> 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] 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 : >>> 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] 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] 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] [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] 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] 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] 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] What to do when we lose DHCPv4 election?
> Steven Barth 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] 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] 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=homenet&gbt=1&index=4PT0dEjoh_rSVbxoqT8vHZho5_A ;) Cheers, Steven ___ 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] 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 nits re DHCPv4
Hi Juliusz,
as always, thanks for your comments.
> I might experiment with working around some of these issues by using RFC
> 3203 and RFC 6704 (forcerenew with nonce authentication, which is
> reportedly implemented by dhcpcd). If you have experience with this
> subprotocol, please drop me a note.
The problem is we can't rely on it since it is not widely supported by
clients.
>
> I have the following nits:
>
> 1. The election process is described in Section 7.3, and uses an ordering
>that is sort-of defined in Section 4 (the bit that maps capabilities to
>a single integer). This confused me, I suggest either making an
>explicit reference to Section 4 in Section 7.3, or simplifying the
>election procedure so that the first tie-breaker is not used.
Added more xrefs where Capability Value is mentioned. This tie-breaker is
intentional to centralize certain services to single routers (e.g. stateful
DHCPv6 and PD).
>
> 2. Section 7.3 says that DHCPv4 should only announce a default route if
>the RP is announcing one. This means that if the RP's default route is
>flapping, clients will randomly get or not get the default route. Since
>DHCPv4 has much larger latencies than the RP, I think this should be
>changed to always announcing a DHCPv4 default route, and trusting ICMP
>to do the right thing with respect to unreachable networks.
>
> 3. Related to the above, 7.3 requests that a static route be announced to
>each delegated prefix. Again, DHCPv4 latencies are too large to make
>this useful, and in any case this is redundant if a default route is
>unconditionally announced.
I agree, it now always MUST announce itself as router. Dropped the parts about
classless routes.
>
> 4. Section 7.3 says "DHCPv4 lease times SHOULD be short (i.e., not longer
>than 5 minutes) in order to provide reasonable response times to
>changes." I'm not sure that's necessary -- wouldn't a longer lease
>time but with a low rebind timer (T2 in RFC 2131) be more robust?
That was the intended meaning, it has been a while since I dealt with DHCPv4,
but IIRC there is no lease time besides T1 and T2, anyway clarified.
>
> 5. The election is not stateful: should the elected router be unstable,
>the election process will be repeated every time it goes up or down.
>Since there is no mechanism for passing around the lease database, this
>will cause duplicate address allocations (hopefully worked around by
>clients performing duplicate detection, but still). A stateful, sticky
>(OSPF-style) election process would be preferable to the stateless,
>unstable (IS-IS-style) election process currently mandated, but would
>cause republishing of node state at each election (since DNCP has no
>link-local signalling).
Yes, this trade-off was discussed several times already I think.
>
> 6. The election state is not signalled -- there is no way to find out
>whether a router currently considers itself elected by just looking at
>its published node state. This makes debugging tricky, but is perhaps
>the right thing to do in order to avoid republishing node state at each
>election (since DNCP has no link-local signalling).
Well you can recalculate the elections to know which router is elected, so
there is a way to find out for all local interfaces / Common Links.
You can also calculate it for non-neighboring (transitive) links,
given the topology graph.
> I'm not familiar with DHCPv6 (SLAAC ftw!), but I think that many of the
> above nits apply to stateful DHCPv6 as well. I believe that the spec
> should say that stateful DHCPv6 MUST NOT be provided for prefixes of
> length 64 (I know that Steven disagrees, see odhcpd issue #55).
Well, the reason is that it is relatively useful to collect hostnames,
in absence of any other way of doing this cross-platform.
But yes, the same issues apply in theory. HNCP has a sentence discussing
this for a while. The latest staged one now says:
"Stateful addresses SHOULD be assigned in a
way not hindering fast renumbering even if the DHCPv6 server or
client do not support the DHCPv6 reconfigure mechanism, e.g., by only
handing out leases from locally-generated (ULA) prefixes and prefixes
with a length different from 64, and by using low renew and rebind
times (i.e., not longer than 5 minutes)."
This should help to minimize the issues.
> On a related note, I'm not sure the draft is sufficiently clear about when
> it is allowed to provide stateless ("O") DHCPv6 -- should a router that
> has lost the DHCPv6 election provide stateless DHCPv6 service? How will
> clients behave if they get RAs with conflicting "M" values?
RFC 7084 says a router MUST always either provide stateless or stateful DHCPv6.
HNCP mandates when a router MUST and MUST NOT do stateful, so in theory if you
don't do stateful you MUST do stateless on client links, which is fine since
they
do not interfere in gen
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] [ieee-ietf-coord] Despair
Am 7. August 2015 09:02:29 MESZ, schrieb Mikael Abrahamsson : >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] 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 ther
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
>Why don't you set the valid lifetime to 0 as well? > >If a new host is connecting to the network while you're advertising the >max(old valid lft, 2h) valid lifetime, it will actually auto-configure >itself with an address from the withdrawn prefix. If you set valid >lifetime to 0, it won't. Sounds good, i don't mind. Just have to phrase so that it's sent more than once in any case. We could also say it needs to be sent in 3 successive RAs independent of the time frame. What do you people think? ___ 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] HNCP, RA and DHCPv4
> To me a flash renumbering = power failure and recovery or a power cycle. It does not matter if its a power failure or something else. If your edge router looses connectivity for any reason, its delegated prefix is removed once its falls out of the HNCP network or once it starts announcing a different set of TLVs. Then RFC 7084 deprecation kicks in for all routers who have assigned a prefix from it. In addition for WiFi routers (or if your whole home power cycles) there is a good chance your clients get a link change event anyway. > Or are we relying on some device, somewhere, reliably keeping all > state on flash? The prefix assignment draft defines a (non-mandatory) stable storage to store your own assignments btw. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
Am 31.07.2015 um 17:08 schrieb STARK, BARBARA H: > When the old prefix is deprecated, (many?some?) routers apparently are > sending that info out just once. > Any host that didn't get the one announcement doesn't know and has no way of > knowing. > Does it make sense for routers to continue sending the deprecated prefix in > RA messages > for the duration of the prefix's original validity? Is there something HNCP > should also do to > continue to provide info for the duration of the original valid lifetime? Actually RFC 6204 (and its successor 7084) have a requirement that enforces keeping it in the RA for at least 2h. HNCP makes following 7084 mandatory atm. Some more details of how HNCP handles graceful and ungraceful currently: https://mailarchive.ietf.org/arch/msg/homenet/eBt_ANocpvbxsnhBBl-hngKdiVk ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
>> Much will depend if the ISP is offering their customer a ‘graceful’ >> renumbering event. If they do, then the principle applied in RFC4192 >> could be applied, and you will have a period where both prefixes (old >> and new) co-exist, before the old prefix is removed. In that case, the >> older connections can be retained, at least until that removal. > > I don't think that HNCP announces the "deprecated" status of a delegated > prefix, so there's no way for an HNCP node to propagate it from the > delegated to the assigned prefix. Markus, Steven, Pierre? For all intents and purposes a "deprecated" prefix is one with a preferred lifetime of 0 so that is supported (TLV has valid and preferred lifetimes). If your ISP does a graceful renumbering than that is what happens, your RA server just has to play ball here though. In an ungraceful case (flash renumbering) we stop announcing the prefix in HNCP and the individual routers who have assigned it, MUST deprecate it according to RFC 7084 (not just stop announcing it in RAs). This deprecation sets preferred lifetime to 0 and valid lifetime to max (old valid lft, 2h). > FORCERENEW with > Nonce authentication might also be helpful, I'm not sure. Nobody (I know) implements that, though. Even for DHCPv6 it is rare (haven't seen a host OS that does) and there its part of the main standard. ___ 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: 11-31: Free - policy of 'standards action' should be used 32-511: Reserved for per-DNCP profile use 512-767: Free - policy of 'standards action' should be used 768-1023: Private use 1024-65535: Reserved for future protocol evolution (for example, DNCP version 2) 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" ;) Address an identifier used as source or destination of a DNCP message flow, e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport. Endpoint a 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 . 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
[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] 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
Re: [homenet] HNCP, RA and DHCPv4
> There's no "attached host control" part in HNCP -- there's just RA and > DHCPv4 (DHCPv6 optional). HNCP is purely a router-router protocol. (stateless) DHCPv6 is mandatory as per RFC 7084, since not all clients support getting RDNSS and search-domains from RAs (e.g. Windows-based). In general, while having something minimal in there is nice, I think making it optional or at least separating it so it can be easily removed is a good idea as well. For some stuff you might not want to have DHCPv4 / IPv4, or you want to have a better-featured RA-server that actually reacts to default route changes, or sends out link MTU & HW-address or can unicast replies etc. All in all, that's some modularity even hnetd has :P 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] 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] 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] Questions about HNCP Section 7.2
At first: you should probably CC Pierre for these PA related parts as well. I'd probably remove that whole paragraph since we reference RFC 7084 anyway and this seems duplicate and was taken from there originally. Maybe 1 or 2 extra modifications are necessary, see section 11. I've queued something for the next revision. Cheers, Steven Am 12.07.2015 um 16:14 schrieb Juliusz Chroboczek: > Section 7.2: > >o The default Router Lifetime MUST be set to an appropriate non-null > value whenever an IPv6 default route is known in the HNCP network > and MUST be set to zero otherwise. > > In the presence of source-specific routing, the term "default route" is > ambiguous. There are marvelous interactions here between source-specific > routing, on-link prefixes, autonomous address configuration flags and DHCPv6 > servers. Could you please clarify what needs to be done here? > >o A Prefix Information Option MUST be added for each assigned and > applied IPv6 prefix on the given link. The autonomous address- > configuration flag MUST be set whenever the prefix is suitable for > stateless configuration. > > What's "suitable" here? I assume you mean /64 or shorter? (But then RFC > 7421 Section 4.3.1 implies that we might as well not bother, and always set > the flag.) > >o A Route Information Option [RFC4191] MUST be added for each > delegated IPv6 prefix known in the HNCP network. Additional ones > SHOULD be added for each non-default IPv6 route with an external > destination prefix advertised by the routing protocol. > > That's to handle isolated Homenets, right? Some rationale would be helpful. > >o To allow for optimized routing decisions for clients on the local > link routers SHOULD adjust their Default Router Preference and > Route Preferences [RFC4191] so that the priority is set to low if > the next hop of the default or more specific route is on the same > interface as the Route Advertisement being sent on. > > I'm not sure I follow. If the host has accurate on-link information, the > redundant route will be ignored anyhow. If the host is multihomed and > doesn't have on-link information, then setting the priority to low might > cause it to route through a different interface, thus rendering the redirect > mechanism ineffective. > >Every router sending Router Advertisements MUST immediately send an >updated Router Advertisement via multicast as soon as it notices a >condition resulting in a change of any advertised information. > > "Immediately"? I'd rather do that after a random delay in order to avoid > collisions (think multicast on wireless). > > -- 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] 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 change
Re: [homenet] PREFIX-DOMAIN in HNCP
> Oh, my. > > In that case, please clarify whether prefixes assigned from non-zero > policy prefixes should be treated specially, by HNCP, by the routing > protocol, or by RA/DHCP. (E.g. do I just serve such a prefix normally > over DHCPv4? Do I tag it somehow in the routing protocol? Do I serve the > associated DHCP options normally, say DNS servers?) > > Steven, I'd really be grateful for a usage scenario. There is the section "Special Purpose Prefixes" (now renamed to "Prefix Policy") which specifies extra behavior. In general (unless noted there) you do not treat them differently than other prefixes. Just serve them via RA/DHCPv6 as usual if they are assigned. Also HNCP does not specify routing protocol behavior so that's out of scope. At some point when mif-wg has finalized their work on special RA or DHCPv6 options, clients will be able to identify and interpret them based on the TBD options that HNCP just passes through, until then its basic SAS. IPv4 / DHCPv4 only allows a single prefix, so it doesn't really apply there anyway. Example usecases for Prefix Policy (autonomous and manual): 1. You have a (company?) VPN router and only want to be able to reach the VPN from a certain link, e.g. only in your home office. 2. You are an IOT-device manufacturer and want to form a single prefix / "IOT-network" if a user has multiple of your IOT-gateways (and with that even discover there is a second one already). 3. You are an ISP and have a special purpose uplink or vlan (e.g. for IPTV) and only want to assign prefixes from these to your HNCP-Enabled STPs that can really use them, but you want the user to be able to place these boxes anywhere in the network. Maybe it would be worth adding 1 or 2 of them to the draft as well. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
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] RtgDir review: draft-ietf-homenet-dncp-07.txt
Hello Les, > > [Les:] We are not understanding each other. Let me try to explain more > clearly than I did the first time. > > DNCP has two dependencies: > > 1)The (routing) protocol which uses it I'm sorry, but I can't seem to follow your logic. Are you thinking of a DNCP-based routing protocol here? But even then how can a thing using DNCP be a dependency of DNCP? > 2)The profile "protocol" which completes the specification of what > information needs to be sent by DNCP. Let me tackle this another way: Trickle does not depend on DNCP, but DNCP depends on Trickle. That's why the DNCP specification has a Normative Reference on Trickle, but not the other way around. Similarly RPL uses Trickle, but that doesn't affect Trickle either and does not make it responsible if something was missing in RPL. > To have high confidence that the DNCP specification is complete we would like > to have experience w multiple routing protocols/profile protocols. So... I don't see how building routing protocols out of DNCP proofs or disproofs anything. Furthermore, in general how could adding something proof or disproof the completeness of it, especially if the original thing is deliberately abstract? Or do you think existing routing protocols have any impact on DNCP? That is not the case either, i.e. DNCP-based profiles can rely purely on link-local communication - like HNCP does - and are thus unaffected by presence or absence of routing protocols. Or are you referring to mentions of "IGP" and "routing protocol" in the HNCP draft? If so, then these are unrelated to DNCP since they are in a separate draft. However even for HNCP there is not much sense, since it merely tells the router whether to run or not run any routing protocol on a network interface. It can also optionally provide a pre-shared key to use for authentication, but that's about it. > This makes me concerned that we don't really know what gaps/problems might > exist in DNCP because we simply don't have enough experience with it yet. You may want to scan through https://www.ietf.org/id/draft-jin-homenet-dncp-experience-00.txt for some up-to-date information on the current state of DNCP and HNCP implementations. This draft also includes simulation results using a relatively bare-metal DNCP-profile (e.g. just using DNCP-TLVs IIRC). > [Les:] Well "neighbor" is not defined - though yours would not be the only > specification to omit that definition. And I could intuit using "peer" to > identify other nodes operating the protocol who are not necessarily neighbors > - but that can't be done using your definition of "peer". The sentence you quoted didn't have the term "neighbor" in it but rather "Neighbor TLV" which is clearly defined as one of the TLVs in the document. >> TLVs that are part of the database are sent within the Node State TLV (Node >> Data field). Said Node State TLV is mentioned just before "Any other TLV" >> in the same list and thus not meant to be part of "other TLV"s. The text now >> states this explicitly. > [Les:] But there can be TLVs within the Node State TLV - and these cannot be > discarded - though they could be ignored. So there seem to be two classes of > "unrecognized TLVs" - those within the Node State TLV and those not > associated with the Node State TLV. > ?? Yes, "Any other TLVs" as well as all the other elements of that enumeration are referring to top-level TLVs, not nested ones. I currently propose "TLVs not recognized by the receiver MUST be silently ignored unless they are sent as part of the payload of one of the TLVs above (such as TLVs in the Node Data field of a Node State TLV)." to make that more clear. Furthermore the definition of the Node State TLV already states that the Node Data content MUST not be modified, so it should be fine. > >> This is described in detail in 4.2, a reference has been added. >> > [Les:] Ahhh - thanx for the pointer. I searched for "Node Endpoint" - but > Section 4.2 uses simply "Endpoint" - so I did not find a match. If you could > use the full TLV name in Section 4.2 that would be helpful. Yes, I noticed that as well when adding the reference and corrected it. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt
Hello Les, thanks for your review. Please find detailed replies inline. Cheers, Steven & Markus > Major Issues: > > > > My biggest concern is that the document - and its companion HNCP - are not > yet mature enough to be doing last call. Please note that DNCP does not depend on nor reference HNCP in any way. It is a separate draft and it can and should be used not only by HNCP. Furthermore while DNCP has been submitted to the IESG, HNCP has not and is still in WGLC. Therefore I'd kindly ask you to keep issues separate from one another. > What is being defined here is a > "state synchronization protocol" which is used within the context of a > "parent protocol" (most interestingly a routing protocol for the homenet > context) and which depends upon another configuration protocol > (presumably HNCP) to fully define the behavior. I don't believe this to be an accurate summary. Again DNCP does not depend on HNCP, rather the reverse is true. DNCP even defines some extensions that are not used or intended to be used in HNCP. Neither of the two protocols depend on any routing protocol for correct operation. DNCP does not even mention routing anywhere in the draft. HNCP in fact enables routing protocols to operate in typical home network scenarios. > Judging from the review comments provided by others (notably Thomas Clausen's > detailed review) and the continued discussion on the mailing list it has not > yet been demonstrated that the specification is clear enough and robust enough > for implementations to meet all the requirements and interoperate. > > This is not to suggest that you are on the wrong track - but given the > dependencies pushing this to last call seems - to put it politely - > very "ambitious". I would prefer to see more implementation experience before > the document moves to a state where it is presumed to be complete. We addressed Thomas' comments to the best of our knowledge. Please let us know, if any of the issues still remain in the current revisions. Also, a second independent and interoperable implementation of DNCP and (parts of) HNCP exists: https://github.com/jech/shncpd Comments of the author regarding clarity of the draft are already integrated in the current revisions, some more are queued for the next. > I still have some trouble calling this a protocol. This is more of a process - > or part of a process - which comprises a routing protocol. Again "comprises a routing protocol" is simply incorrect. > The process defined > here serves to support reliable distribution and synchronization of "state" > in an efficient manner under a limited set of conditions. I don't want to > quibble too much about the term "protocol" - but I would prefer something > like: > > "a generic set of procedures which - when supplemented by a specific profile - > define a means of maintaining state synchronization" It is very hard to find a wording for this that everyone agrees with. For now it was changed to “DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol.” based on a suggestion in Ole Troan’s review. > Section 2 Terminology > > > The term "neighbor" is not defined - but used frequently in the document. > The term "peer" is defined as: > "another DNCP node with which a DNCP node communicates using a particular > local and remote endpoint pair." > > What I am used to is that the definition above for "peer" is usually > associated with the term "neighbor", whereas the term "peer" is more generic - > it is associated with a node in the network which performs the same functions > in the protocol - but is not necessarily a neighbor. The terms "peer" and "neighbor" are used relatively interchangeably in this document. The terminology has been adapted to reflect that. > Section 4.5 illustrates why I find this confusing as it says > > "When receiving a Node Endpoint TLV... the remote node MUST be added as a peer > on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created > for it." > ??? I think this particular case should actually not be confusing, since all terms used here are defined in the Terminology or as TLVs. However, we may have a look at it again. > Section 4.4 - final bullet on Page 11 > >o Any other TLV: TLVs not recognized by the receiver MUST be > silently ignored. > > Does "ignore mean "discard"? (This is one traditional meaning) > > If so this seems inappropriate as it is part of the database sent by > the node and therefore needs to be retained in order to keep a consistent > database. Perhaps "store but do not process" is a more accurate behavioral > description? TLVs that are part of the database are sent within the Node State TLV (Node Data field). Said Node State TLV is mentioned just before "Any other TLV" in the same list and thus not meant to be part of "other TLV"s. The text now states this explicitly. > Section 6.1 Keep-alives > > Are keep alives s
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] 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] 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
> 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] 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] 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] 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] 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] 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
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] 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] 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] How to compute DNCP/HNCP node data?
>> Profile recommendations section in dncp recommends sha-256. > >Er... -06 recommends the leading 8 octets of MD-5. Section 3. DNCP recommends sha256 for profiles. HNCP uses what you mentioned. >1. simply copy the has received from the originator, no questions >asked; >2. hash the raw data received from the originator; >3. hash data that I've formatted from my internal data structures. Since dncp mandates the canonical order this essentially means 2 and 3 are identical. I personally don't believe in supporting buggy clients as in clients violating MUST statements since at some point it just breaks. Cheers, 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] RtgDir review: draft-ietf-homenet-dncp-05.txt
Hello Thomas, thanks a lot for your elaborate review, we have just pushed revision -06 of DNCP addressing your issues and comments and that of other reviewers. Please see more detailed comments inline. Cheers, Steven & Markus On 16.06.2015 17:45, Thomas Clausen wrote: > Comments: > > o Is there any good reason why the authors have no listed > affiliation? As we are independent consultants, an affiliation would probably not be much more useful than our names themselves. > > o It is somewhat contradictory that the abstract talks about > "...describes a protocol" and then later "...leaves some details >to be specified in profiles, which define actual implementable > DNCP >based protocols" > >Does that not mean, then, that this document specifies an > algorithm, >a framework, and not a protocol? This was debated publicly and tbh. we are not sure what the correct phrase would be, maybe “abstract protocol”, but even that was not liked by everyone. Other than that we tried to clear up the introduction and abstract in that regard. > > o On that, I see "DNCP protocol" several places. Expanded, that > becomes > "Dynamic Network Configuration Protocol Protocol" ... Fixed, found only one. (long form is wrong btw.) > > o In general, and despite actually knowing some of the core > algorithms > somewhat before this review, I found the document really tough > to > read, with convoluted sentences, inconsistent > requirements-language, > and a lack of introductory "here's the 1000ft view of the > protocol, > what it does, how it works, and under which conditions it > works". > > o On that, I do not find the chosen structure of the document to > be > optimal for conveying an unambiguous protocol specification. > For one, > the same concepts are occasionally described slightly > differently. > For another, it is often hard to find the information needed to > parse a specific mandated processing (for example). I provide an > example of what I would suggest a better structure in the below. > > The goal is to provide first concepts and an overview, followed > by a > single, easy to identify place for "precise and unambiguous > definitions > of concepts", and then use those in the detailed expression of > the > protocol. Note that this is just an example, of course: > > Section "Terminology:" > The Network State Hash is a hash value which > represents the > current state of the network, as known by a > node. > > Section "Protocol Overview and Functioning" > > When receiving a FOO TLV, the DNCP node > compares the received > Network State Hash with its own Network State > Hash. This > represents the consistency check rom RFC6206. > If same, > then...if not, then > > Section "Protocol Information Bases" > For the purpose of this specification, the > Protocol > Information Bases are orgnaized as sets of > tuples ... any > implementation can chose whatever > representation it wants. > > The Network State Information Base in a > DNCP node is a set > of tuples: > (x, y, z, w) > > where x is ..., y is ..., z is ..., and > w is ... > > Section "How to calculate the Network State Hash": > >The network State Hash is calculated using the > information >from the Network State Information Base, as > follows: > > 1. First, the tuples in that > information base are sorted > in ascending order based on > > > 2. Second, (concatenation) > > 3. Third, the hash function > f
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] I-D Action: draft-ietf-homenet-dncp-04.txt
Thanks for all the comments we got on-list and in private during the WGLC. We tried to address them in -04. Besides clarifications there is one minor change: Added mandatory rate limiting for network state requests, and optional slightly faster convergence mechanism by including current local network state in the remote network state requests. We will prepare the next version of the HNCP-draft in the coming days so it can be last called as well. Thanks, Steven and Markus On 01.06.2015 11:01, 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 : Distributed Node Consensus Protocol > Authors : Markus Stenberg > Steven Barth > Filename: draft-ietf-homenet-dncp-04.txt > Pages : 27 > Date: 2015-06-01 > > Abstract: >This document describes the Distributed Node Consensus Protocol >(DNCP), a generic state synchronization protocol which uses Trickle >and Merkle trees. DNCP is transport agnostic and leaves some of the >details to be specified in profiles, which define actual >implementable DNCP based protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-homenet-dncp-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-04 > > > 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" 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] I-D Action: draft-ietf-homenet-dncp-03.txt
Just a quick update, based on the feedback we got here and on private
channels.
This is mostly a cleanup to remove the partly ambiguous use of the terms
"connection" and "message"
and one backwards-incompatible change to TLVs to simplify the state
machines and get rid of an unnecessary TLV-to-TLV dependency as well as
an accompanyingTLV-renumbering.
Draft: https://tools.ietf.org/html/draft-ietf-homenet-dncp-03
Cheers,
Steven
On 24.04.2015 12:56, 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 : Distributed Node Consensus Protocol
Authors : Markus Stenberg
Steven Barth
Filename: draft-ietf-homenet-dncp-03.txt
Pages : 27
Date: 2015-04-24
Abstract:
This document describes the Distributed Node Consensus Protocol
(DNCP), a generic state synchronization protocol which uses Trickle
and Merkle trees. DNCP is transport agnostic and leaves some of the
details to be specified in profiles, which define actual
implementable DNCP based protocols.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-dncp-03
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-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] 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
Re: [homenet] Selecting a routing protocol for HOMENET
>I 'll note that RPL already addresses the problems the Margaret listed >in Dallas, in with a proposed standard doc. The shortest time to >Homenet is probably to explain how to use RPL at home, and that >probably requires only a guideline informational document... Interesting. Does RPL fulfill the requirements for a homenet RP already: supporting source-dest-routes and being autoconfiguring? Also is there any good linux-compatible C implementation to play with? Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Selecting a routing protocol for HOMENET
I like to think that the IETF standards process has considerable value, and that the specifications that we produce as standards-track RFCs are higher-quality, not just in document quality but in the technical quality of the protocols, than the documents that enter the process. What do you think about ISO standards (or RFCs imported from them)? 1) A mandatory-to-implement security mechanism. The current draft says that security can be accomplished by using a lower-layer security solution, like IPsec. It doesn't specify one, and (perhaps more importantly) doesn't specify how the Babel session would be bound to a lower-layer security mechanism. A lower layer mechanism can't really be used to secure a higher-layer protocol, unless the identifiers used in the higher-layer protocol are properly bound to the identifiers used in the lower-layer security mechanism. There is RFC7298 for Babel which is mentioned in the comparison draft. On a more general matter, IIRC both our candidates (and I think most IETF routing protocols) have equally non-existent asymmetric authentication and that is not even talking about encryption. If you want to have encrypted routing protocol traffic, you are going to have a bad time last time I looked. The best we can currently achieve seems to be HNCP managing a PSK to at least have symmetric authentication. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Selecting a routing protocol for HOMENET
Are there any other comments in either the positive or negative direction? Please WG, speak up. Please take into consideration that the intended solution is aimed at relatively low-cost mass-produced devices not big industry routers that come with expensive support contracts, i.e. the specifications should be relatively simple and clear so it can be implemented in a reasonable timeframe by people not knowing the protocol. Similarly these boxes are mostly unadministered and the overall complexity added by the protocol should reflect in the added benefit. What I mean is, if the outcome was a protocol that requires compliance with 100 pages of specification then it should have a very sophisticated mechanism to find the best path without an administrator telling it which hops are preferrable. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Selecting a routing protocol for HOMENET
+1 Am 26. März 2015 11:53:11 CDT, schrieb Lorenzo Colitti : >On Thu, Mar 26, 2015 at 11:11 AM, Terry Manderson >> wrote: > >> For each >> highly plausible candidate routing protocol, the design team will >> estimate the work needed and the associated timeline to get an >> acceptable, full, standardized solution using each protocol. > > >I find it concerning to say that a decision will be made only on the >"work >needed" to get to an acceptable solution, without considering the >likelihood of said work happening and who is expected, able, and >especially, willing to do it. > >Example: > >For IS-IS, the existence of a small-footprint, >source-destination-routing >capable implementation is a blocker for an "acceptable, full" solution. >That requires that either a) someone with knowledge of an existing >implementation extend said existing implementation to meet these >requirements, or b) that someone write a new implementation to meet >these >requirements. > >On the other hand, for babel, much of the work is in addressing the >fact >that the specification is perceived to be underspecified, and verifying >that the existing implementations conform to the specification and >interoperate, and taking the specifications through the standards >process. > >The types of work involved are radically different, and the people able >to >do each may or may not be willing to do it. So if one of the two (say, >IS-IS) is perceived to be lower work, but nobody is willing to actually >*do* that work, then the design team could come to a perfectly logical >conclusion, consistent with its charter, that ends in failure to reach >the >full solution. > >Or, more succintly: what happened to the "running code" part of the >IETF >motto? > > > > >___ >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
[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
