From owner-zeroconf@merit.edu Tue Jul 3 11:26:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08666 for ; Tue, 3 Jul 2001 11:26:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3592F91208; Tue, 3 Jul 2001 11:26:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 037A1912BF; Tue, 3 Jul 2001 11:26:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25D4691208 for ; Tue, 3 Jul 2001 11:26:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 757015DDAD; Tue, 3 Jul 2001 11:27:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EEEDB5DDA9 for ; Tue, 3 Jul 2001 11:27:31 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09657; Tue, 3 Jul 2001 09:26:34 -0600 (MDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id RAA21485; Tue, 3 Jul 2001 17:26:33 +0200 (MET DST) Date: Tue, 3 Jul 2001 17:38:33 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Host Profile for Zero Configuration Networking To: zeroconf@merit.edu Cc: erik.guttman@sun.com, cheshire@apple.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk We have a chartered work item which we have not yet embarked upon. Aug 01 Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking. The charter describes this host profile as follows: This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. The second, which follows the first, will detail a 'profile' specifying which standards specifically satisfy ZEROCONF requirements. I propose to create an internet draft before the i-d cutoff date which essentially says: - Address Autoconfiguration IPv4: use v4LL autoconf, v6 ADDRCONF - Name Resolution: use mDNS (ipv4 and ipv6) - Service Discovery: use SLPv2 for distinct services (ones you want to select among by attributes), use DNS SRV and mDNS for services which are indistinct (like SMTP relays, recursive back end DNS resolvers, etc.) (ipv4 and ipv6) - Multicast address allocation: use ZMAAP (ipv4 and ipv6) Note that (1) mDNS and ZMAAP are not yet through WG last call, that is, work is not yet complete, (2) a security section to the profile doc will describe how to meet zeroconf security requirements with these protocols and (3) the profile document's category (should it be Informational, BCP, what?) Please discuss. Erik From owner-zeroconf@merit.edu Tue Jul 3 11:26:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08778 for ; Tue, 3 Jul 2001 11:26:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4682D912BF; Tue, 3 Jul 2001 11:26:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1650F912C0; Tue, 3 Jul 2001 11:26:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A36F2912BF for ; Tue, 3 Jul 2001 11:26:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CCD25DDAD; Tue, 3 Jul 2001 11:27:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id ADBE35DDA9 for ; Tue, 3 Jul 2001 11:27:37 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08896; Tue, 3 Jul 2001 08:26:42 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id RAA21492; Tue, 3 Jul 2001 17:26:40 +0200 (MET DST) Date: Tue, 3 Jul 2001 17:38:40 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: status report and moving forward To: zeroconf@merit.edu Cc: erik.guttman@sun.com, cheshire@apple.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk ZEROCONF Status Report: We are making progress on our charter. Goals and Milestones: DONE Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. DONE Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. Aug 01 Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC. Please comment on draft-ietf-zeroconf-zmaap-01.txt!!! Aug 01 Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking. We need to open discussion on this, on the mailing list. Moving Forward [1] Complete work on ZMAAP. Please review the ZMAAP draft. [2] Create a zeroconf host profile? Of what form? Erik From owner-zeroconf@merit.edu Tue Jul 3 11:33:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09066 for ; Tue, 3 Jul 2001 11:33:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0AB66912C0; Tue, 3 Jul 2001 11:33:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA3E3912C1; Tue, 3 Jul 2001 11:33:12 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF22F912C0 for ; Tue, 3 Jul 2001 11:33:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 597C35DDAD; Tue, 3 Jul 2001 11:34:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D3A785DDA9 for ; Tue, 3 Jul 2001 11:34:26 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13657; Tue, 3 Jul 2001 09:33:27 -0600 (MDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id RAA21551; Tue, 3 Jul 2001 17:33:27 +0200 (MET DST) Date: Tue, 3 Jul 2001 17:45:27 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: discuss: agenda for IETF 51 To: zeroconf@merit.edu Cc: erik.guttman@sun.com, cheshire@apple.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk What should we discuss at the London zeroconf meeting? We need to put together a schedule before requesting time on the IETF agenda. Suggestions: 1. ZMAAP 2. Profile document 3. Charter extension or conclusion There are topics which folks have expressed interest in pursuing, but we have put them off as they are not on our charter: - Router autoconfiguration for multihop zeroconf networks - Easy security configuration - Edge server considerations (mini-DHCP, dynamic DNS, etc.) Perhaps the third one is appropriate for ZEROCONF, if there is work to do. Router autoconf and Easy Security conf probably require a BOF and a new working group to be formed, likely outside of the Internet Area. Erik From owner-zeroconf@merit.edu Mon Jul 9 13:45:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23532 for ; Mon, 9 Jul 2001 13:45:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB44B9120D; Mon, 9 Jul 2001 13:45:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF1389120E; Mon, 9 Jul 2001 13:45:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF1FF9120D for ; Mon, 9 Jul 2001 13:45:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB6725DDB4; Mon, 9 Jul 2001 13:46:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by segue.merit.edu (Postfix) with ESMTP id 6ECAE5DDB0 for ; Mon, 9 Jul 2001 13:46:58 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA16482 for ; Mon, 9 Jul 2001 13:41:38 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA27186 for ; Mon, 9 Jul 2001 13:45:55 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id NAA25455 for ; Mon, 9 Jul 2001 13:42:22 -0400 Message-Id: <200107091742.NAA25455@rotala.raleigh.ibm.com> To: zeroconf@merit.edu Subject: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Mon, 09 Jul 2001 13:42:22 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk The WG has reqested this document be advanced as a Proposed Standard. In anticipation of starting the Last Call, I reviewed the document and have the following questions/comments. I'm sending this to the WG rather than just the authors as some if the issues go beyond just editorial clarification. Thomas 2.4 Source Address Selection Since each interface on a host may have a link-local address in addition to zero or more other addresses configured by other means (e.g. manually or via a DHCP server), a host may have to make a choice about what source address to use when it sends a packet or initiates a TCP connection. If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MUST use its link-local source address. The rules in this section seem overly strong to me. In particular, they make it a protocol violation to use certain combinations of addresses, when: a) it is not clear there is a need for such a restriction b) it makes it a protocol violation to use certain combinations when it seems to be that little or no harm would come from it (i.e, communication would work just fine). I'll also note that the decision here is different than the approach taken in IPv6, where the issue of addresses having different scopes is much more prevalent. Is this really needed? Also, do these rules mean that a node can't just swap src/dest addresses when responding to a packet? If so, this would seem to be an extra check stacks must do, and it would also prevent certain types of communication where there would appear to be no harm in allowing it. If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MUST use its link-local source address. too strong? If the destination address is: (a) a unicast address outside the 169.254/16 prefix, or (b) a multicast address with scope larger than link-local and the TTL in the IP header is greater than 1, then the host MUST NOT use its link-local source address, and should instead use an appropriate routable source address. why? Any host receiving an IPv4 packet whose destination addresses is in the 169.254/16 prefix MUST discard the packet if the source address is not in the 169.254/16 prefix. all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP request constructed this way with an all-zero 'sender IP address' is referred to as an "ARP probe". terminology: what is 'target IP address'? ARP has "target protocol address". ditto for sender IP address? I think the terminology may need tweaking throughout the document on this point. In addition, if during this period the host receives any ARP packet where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of any of the host's interfaces, then the host MUST similarly treat this as an address collision and select a new address as above. This can occur if two (or more) hosts attempt to configure the same link- local address at the same time. They above text seems wrong. If a router is trying to ARP for my address, wouldn't it send out a packet that by the above rules indicate an address collision? Shouldn't the check be if the Sender Protocol address is IP address and is 0, and the hardware source address is not one of my own? A host should maintain a counter of the number of address collisions it has experienced in the process of trying to acquire an address, and if the number of collisions exceeds ten then the host MUST limit the rate at which it probes for new addresses to no more than one new address per second. This is to prevent catastrophic ARP storms in pathological failure cases, such as a rogue host that answers all ARP probes, causing legitimate hosts to go into an infinite loop attempting to select a usable address. Hmm. Seems to me that if you have ten collisions in a row, you've either got: 1) bad algorithm for chosing addresses, in which case retrying at all is a waste of time (or worse)... 2) DOS attack in progress in which someone is claiming ownership of all addresses. In this case, continuing on every second seems useless too. I'd suggest in the name of network friendliness that after ten tries, one should either quit entirely (maybe too extreme) or at least back off *very* significantly, say no more than once every few minutes or so. (b) If a host currently has active TCP connections or other reasons to prefer to keep the same IP address, and it has not seen any other conflicting ARP packets recently (for Ethernet, within the last ten seconds) then it MAY elect to attempt to defend its address, by recording the time that the conflicting ARP packet was received, and then broadcasting one single gratuitous ARP request, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is recent (within ten seconds for Ethernet) then the host MUST immediately cease using this address and configure a new link-local IP address as described above. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address. Once you've concluded that one of the nodes needs to give up its address, should you just pick one, rather than forcing both to pick a new one? I.e, let the lower numbered ethernet address win? At least that way only one gives up the address. This would be less disruptive on average. All ARP packets (replies as well as requests) that contain a link- local sender address SHOULD be sent using link-level broadcast instead of link-level unicast. This aids timely detection of duplicate addresses. An example illustrating how this helps is given in Section 4. Seems like this should be a MUST. Why should this be an implementation choice? Nits: Since MS has a patent on technology related to this document (see the IETF IPR Web Page), the document needs to include text noting that there are possible IPR concerns. In particular, just include paragraphs (A) and (D) of Section 10.4 in RFC 2026. Don't mention the specific patent itself in the document. needs an iana considerations section that indicates that IANA has assigned the 169.254 address for this purpose. the special rules regarding duplicate detection and automatic conf- iguration that pertain to addresses in this prefix. While RFC 2131 don't split words across lines... all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP request constructed this way with an all-zero 'sender IP address' is referred to as an "ARP probe". From owner-zeroconf@merit.edu Mon Jul 9 14:07:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24316 for ; Mon, 9 Jul 2001 14:07:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6736091209; Mon, 9 Jul 2001 14:07:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 392CE9120A; Mon, 9 Jul 2001 14:07:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F61D91209 for ; Mon, 9 Jul 2001 14:07:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FA565DDB8; Mon, 9 Jul 2001 14:09:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by segue.merit.edu (Postfix) with ESMTP id BA4C35DDB0 for ; Mon, 9 Jul 2001 14:09:22 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA17686 for ; Mon, 9 Jul 2001 14:04:03 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA30066 for ; Mon, 9 Jul 2001 14:08:19 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA25669 for ; Mon, 9 Jul 2001 14:04:47 -0400 Message-Id: <200107091804.OAA25669@rotala.raleigh.ibm.com> To: zeroconf@merit.edu Subject: draft-ietf-zeroconf-reqts-08.txt Date: Mon, 09 Jul 2001 14:04:47 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk The WG has reqested this document be published as an Informational RFC. I have reviewed the document and have the following questions/comments. Thomas How about a more descriptive title than "zeroconf requirements" > A zeroconf protocol is able to operate correctly in the absence > of configured information from either a user or infrastructure > services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, > RFC 1035] servers. Zeroconf protocols may use configured > information, when it is available, but do not rely on it being > present. One possible exception is the use of MAC addresses > (i.e. layer two addresses) as parameters in zeroconf protocols. I do not consider a MAC address to be configured information. It is built-in as far as the end user is concerned. This may be a minor nit, but it may be worth pointing out that DHCP *protocols* could be used in a zeroconf environment, so long as no user configuration were needed. One can imagine a DHCP server figuring out a lot of things on its own without being configured (and there has been talk on the list about this). > 1.5 Routable Protocol Requirement > > If a protocol is intended to span multiple IP subnets it SHOULD > NOT use broadcasts or link-local addressing. define what link-local addressing is? i.e., self-configured addresses? I.e., this term is clearly defined in IPv6, but I don't believe its defined for IPv4 in any document (and IMO, it should be). > Requirement: > - Protocols intended to span multiple IP subnets SHOULD NOT use > broadcasts or link-local addressing. Why not? just stating something should or should not be done without context isn't always very convincing. > Topology changes or other events such as adding and removing hosts > may cause conflicts and state changes within a protocol. Zeroconf > protocols must be able to resolve conflicts and state changes caused > by topology changes or other events. The scenario in the 2.1.2 Bridge > Installed section is the only scenario that illustrates the need for > this requirement, thus the below requirement is duplicated in section > 2.1.2. However, this requirement applies to all protocol areas. Suggested rewording of the first part: Topology changes or other events such as adding and removing hosts may cause changes to the overall system state, invalidate assumptions made by some protocols, and lead to incorrect or undesirable operating states. Zeroconf protocols must be able to detect and resolve conflicts and state changes caused by topology changes or other events in some cases. The scenario in the 2.1.2 Bridge Installed section is the only scenario that illustrates the need for this requirement, thus the below requirement is duplicated in section 2.1.2. However, this requirement applies to all protocol areas. > Requirement: > - MUST respond to state changes and resolve conflicts in a timely > manner. Note that his is really open ended, so I don't really know what "MUST" means specifically. What conflicts need to be resolved? Indeed, what is a "conflict"? My suspicion is that having a MUST here in a generic sense is not appropriate. What you want is a MUST in specific sitations that it is felt should or should not happen. > Requirements: > - MUST configure an appropriate netmask. > - MUST have unique IP addresses within an IP subnet. > - MUST have some routing information > (for the internetwork scenario). On the last point, would it be more correct to say, needs the address of one or more default routers? Or is there more to this? > - MUST have unique IP subnets within an internetwork > (only for the internetwork scenario). Do you need to scope this more? I.e., can't an "internetwork" consist of the entire Internet (per the earlier definition?) > Topology changes from the installation of a bridge or a router may > create the following problems: multiple default routes that cause > dial out lines to be used instead of broadband connections, > duplicate IP addresses within an IP subnet, or duplicate IP > subnets within an internetwork. I don't understand the comment (or implication) about multiple default routes leading to dial-out lines being used. > Requirement: > - MUST resolve conflicts and state changes in a timely manner. Can the document be more specific and say just what conflicts need to be resolved? Or is the assumption that the previously discussed issues is what needs to be addressed? > 2.1.3 IPv6 Considerations > > IPv6 allows a host to select an appropriate IP address, netmask, > and routing information, thus if a host is using IPv6, a zeroconf > IP interface configuration solution already exists. Is this fully correct? Do routers automatically (without user configuration) advertise themselves as default routers? Indeed, I'm a bit confused about whether this document assumes multiple subnets are present. It seems to, but I thought the WG decided that a single router was assumed. It would be good to state up front what the assumptions are for the enivironment zeroconf is operating in. Will there be just one router? Or multiple routers? Or no routers? > 2.2.1 Web Browsing > > An URL typically contains the name of a Web server. When a user > enters an URL into a Web browser, the name must be translated to > an IP address before any actual Web browsing occurs. Web servers > often record log files of accesses, and wish to map the client's > IP address back to a human-readable name for recording in the log > file. Thus, a mechanism to translate the IP address to a name is > required. > > Requirement: > - MUST translate a name to an IP address. > - MUST translate an IP address to a name. This text curiously doesn't mention the DNS. But, for the web server, isn't the DNS reverse lookup specifically what is assumed/required? Seems like the reqirement is much more specific than just "translate name to address" and vice versa, and involves integration with the DNS. > 2.3.1 Scope Enumeration > > Applications that leave the choice of scope up to the user require > the ability to enumerate what scopes the host is operating within. > In addition, services that are assigned relative addresses require > the ability to enumerate what scopes the host is within; only then > will a host be able to apply the relative address to a scope. > > Requirements: > - MUST list which of the scopes (local, link-local, or site-local) > are available for hosts. > - MUST list per-scope address ranges that may be allocated. I'm not clear what the requirement above is. That is, *who* is responsbile for the MUST? The application? How is the application supposed to determine this? Is the point that this information must somehow be determinable? (General comment: This may all be an artifact from the fact that the Requirements bullets are not using full sentences.) > 2.3.4 IPv6 Considerations > > To date, no range has been reserved for source-specific addresses > in IPv6. Hence, until such a range is reserved, dynamic allocation > of source-specific addresses applies only to IPv4. > > To date, no range has been reserved for dynamic allocation of > Link-scoped addresses in IPv4. Hence, unless such a range is > reserved, dynamic allocation of link-scoped addresses applies only > to IPv6. Is there reason to think that the mechanisms in IPv4 and IPv6 might be different? > 2.4 Service Discovery Scenarios > > Service discovery protocols allow users to select services and/or > hosts by a name that is discovered dynamically, rather than requiring > that the user know the name in advance and type it in correctly. Can't an application find and select services without the user being queried? E.g., isn't DNS a service? Should the user choose the DNS server? Should the user always be prompted, or is there room for the user not having to select at all, if there is only one choice? > The IPv4 interface configuration protocol MAY omit security > mechanisms if and only if that protocol is not used for IPv6 and > cannot be extended to support IPv6. It is strongly recommended that > it include security mechanisms, because many protocols are extended > later in ways not anticipated by the original developer(s). Explain > use a printer that doesn't exist, no printed upon paper appears.) parsing On the security considerations. I'd like to run this by the Security ADs before commenting specifically. So there may be some specific comments on this point coming later. From owner-zeroconf@merit.edu Mon Jul 9 15:11:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26177 for ; Mon, 9 Jul 2001 15:11:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D9BF91212; Mon, 9 Jul 2001 15:11:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 377A891214; Mon, 9 Jul 2001 15:11:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 478DB91212 for ; Mon, 9 Jul 2001 15:11:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DCF05DDAA; Mon, 9 Jul 2001 15:13:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 3095E5DDA9 for ; Mon, 9 Jul 2001 15:13:02 -0400 (EDT) Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f69JBvp07521 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 9 Jul 2001 15:11:58 -0400 Message-Id: <5.1.0.14.2.20010709150627.03df2430@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 15:11:57 -0400 To: Thomas Narten , zeroconf@merit.edu From: Daniel Senie Subject: Re: draft-ietf-zeroconf-reqts-08.txt In-Reply-To: <200107091804.OAA25669@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I've interspersed some comments below. At 02:04 PM 7/9/01, Thomas Narten wrote: >The WG has reqested this document be published as an Informational >RFC. I have reviewed the document and have the following >questions/comments. > >Thomas > >How about a more descriptive title than "zeroconf requirements" > > > A zeroconf protocol is able to operate correctly in the absence > > of configured information from either a user or infrastructure > > services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, > > RFC 1035] servers. Zeroconf protocols may use configured > > information, when it is available, but do not rely on it being > > present. One possible exception is the use of MAC addresses > > (i.e. layer two addresses) as parameters in zeroconf protocols. > >I do not consider a MAC address to be configured information. It is >built-in as far as the end user is concerned. > >This may be a minor nit, but it may be worth pointing out that DHCP >*protocols* could be used in a zeroconf environment, so long as no >user configuration were needed. One can imagine a DHCP server figuring >out a lot of things on its own without being configured (and there has >been talk on the list about this). There was a lot of debate about this. As I recall, the concern is that Zeroconf can't rely on there being a server. No server means no DHCP. > > 1.5 Routable Protocol Requirement > > > > If a protocol is intended to span multiple IP subnets it SHOULD > > NOT use broadcasts or link-local addressing. > >define what link-local addressing is? i.e., self-configured addresses? yes. See the link local draft... >I.e., this term is clearly defined in IPv6, but I don't believe its >defined for IPv4 in any document (and IMO, it should be). > > > Requirement: > > - Protocols intended to span multiple IP subnets SHOULD NOT use > > broadcasts or link-local addressing. > >Why not? just stating something should or should not be done without >context isn't always very convincing. Link local addressing can't be routed per definitions in the other draft. > > Topology changes or other events such as adding and removing hosts > > may cause conflicts and state changes within a protocol. Zeroconf > > protocols must be able to resolve conflicts and state changes caused > > by topology changes or other events. The scenario in the 2.1.2 Bridge > > Installed section is the only scenario that illustrates the need for > > this requirement, thus the below requirement is duplicated in section > > 2.1.2. However, this requirement applies to all protocol areas. > >Suggested rewording of the first part: > > Topology changes or other events such as adding and removing hosts > may cause changes to the overall system state, invalidate > assumptions made by some protocols, and lead to incorrect or > undesirable operating states. Zeroconf protocols must be able to > detect and resolve conflicts and state changes caused by topology > changes or other events in some cases. The scenario in the 2.1.2 > Bridge Installed section is the only scenario that illustrates the > need for this requirement, thus the below requirement is duplicated > in section 2.1.2. However, this requirement applies to all protocol > areas. > > > Requirement: > > - MUST respond to state changes and resolve conflicts in a timely > > manner. > >Note that his is really open ended, so I don't really know what "MUST" >means specifically. What conflicts need to be resolved? Indeed, what >is a "conflict"? My suspicion is that having a MUST here in a generic >sense is not appropriate. What you want is a MUST in specific >sitations that it is felt should or should not happen. > > > > Requirements: > > - MUST configure an appropriate netmask. > > - MUST have unique IP addresses within an IP subnet. > > - MUST have some routing information > > (for the internetwork scenario). > >On the last point, would it be more correct to say, needs the address >of one or more default routers? Or is there more to this? > > > - MUST have unique IP subnets within an internetwork > > (only for the internetwork scenario). > >Do you need to scope this more? I.e., can't an "internetwork" consist >of the entire Internet (per the earlier definition?) > > > Topology changes from the installation of a bridge or a router may > > create the following problems: multiple default routes that cause > > dial out lines to be used instead of broadband connections, > > duplicate IP addresses within an IP subnet, or duplicate IP > > subnets within an internetwork. > >I don't understand the comment (or implication) about multiple default >routes leading to dial-out lines being used. > > > Requirement: > > - MUST resolve conflicts and state changes in a timely manner. > >Can the document be more specific and say just what conflicts need to >be resolved? Or is the assumption that the previously discussed issues >is what needs to be addressed? > > > 2.1.3 IPv6 Considerations > > > > IPv6 allows a host to select an appropriate IP address, netmask, > > and routing information, thus if a host is using IPv6, a zeroconf > > IP interface configuration solution already exists. > > >Is this fully correct? Do routers automatically (without user >configuration) advertise themselves as default routers? > >Indeed, I'm a bit confused about whether this document assumes >multiple subnets are present. It seems to, but I thought the WG >decided that a single router was assumed. It would be good to state up >front what the assumptions are for the enivironment zeroconf is >operating in. Will there be just one router? Or multiple routers? Or >no routers? > > > 2.2.1 Web Browsing > > > > An URL typically contains the name of a Web server. When a user > > enters an URL into a Web browser, the name must be translated to > > an IP address before any actual Web browsing occurs. Web servers > > often record log files of accesses, and wish to map the client's > > IP address back to a human-readable name for recording in the log > > file. Thus, a mechanism to translate the IP address to a name is > > required. > > > > Requirement: > > - MUST translate a name to an IP address. > > - MUST translate an IP address to a name. > >This text curiously doesn't mention the DNS. But, for the web server, >isn't the DNS reverse lookup specifically what is assumed/required? Web servers as such are not dependent on DNS in any form. Implementations of web servers often have such dependencies, but reverse lookups are NOT required for proper operation of web servers. >Seems like the reqirement is much more specific than just "translate >name to address" and vice versa, and involves integration with the >DNS. Zeroconf is an environment without servers. How are you going to do a DNS lookup without a server? > > 2.3.1 Scope Enumeration > > > > Applications that leave the choice of scope up to the user require > > the ability to enumerate what scopes the host is operating within. > > In addition, services that are assigned relative addresses require > > the ability to enumerate what scopes the host is within; only then > > will a host be able to apply the relative address to a scope. > > > > Requirements: > > - MUST list which of the scopes (local, link-local, or site-local) > > are available for hosts. > > - MUST list per-scope address ranges that may be allocated. > >I'm not clear what the requirement above is. That is, *who* is >responsbile for the MUST? The application? How is the application >supposed to determine this? Is the point that this information must >somehow be determinable? (General comment: This may all be an artifact >from the fact that the Requirements bullets are not using full >sentences.) > > > 2.3.4 IPv6 Considerations > > > > To date, no range has been reserved for source-specific addresses > > in IPv6. Hence, until such a range is reserved, dynamic allocation > > of source-specific addresses applies only to IPv4. > > > > To date, no range has been reserved for dynamic allocation of > > Link-scoped addresses in IPv4. Hence, unless such a range is > > reserved, dynamic allocation of link-scoped addresses applies only > > to IPv6. > >Is there reason to think that the mechanisms in IPv4 and IPv6 might be >different? > > > 2.4 Service Discovery Scenarios > > > > Service discovery protocols allow users to select services and/or > > hosts by a name that is discovered dynamically, rather than requiring > > that the user know the name in advance and type it in correctly. > >Can't an application find and select services without the user being >queried? E.g., isn't DNS a service? Should the user choose the DNS >server? If there's no server serving DNS, it'll be hard to use it. >Should the user always be prompted, or is there room for the user not >having to select at all, if there is only one choice? > > > The IPv4 interface configuration protocol MAY omit security > > mechanisms if and only if that protocol is not used for IPv6 and > > cannot be extended to support IPv6. It is strongly recommended that > > it include security mechanisms, because many protocols are extended > > later in ways not anticipated by the original developer(s). > >Explain > > > use a printer that doesn't exist, no printed upon paper appears.) > >parsing > >On the security considerations. I'd like to run this by the Security >ADs before commenting specifically. So there may be some specific >comments on this point coming later. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Mon Jul 9 15:12:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26190 for ; Mon, 9 Jul 2001 15:12:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E1DA91214; Mon, 9 Jul 2001 15:12:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C03591216; Mon, 9 Jul 2001 15:12:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7404591214 for ; Mon, 9 Jul 2001 15:12:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E2A75DDAA; Mon, 9 Jul 2001 15:13:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 5AAE45DDA9 for ; Mon, 9 Jul 2001 15:13:53 -0400 (EDT) Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f69JCop07603 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 9 Jul 2001 15:12:50 -0400 Message-Id: <5.1.0.14.2.20010709151222.03e47880@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 15:12:49 -0400 To: zeroconf@merit.edu From: Daniel Senie Subject: Fwd: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Forgot to CC the list on this message... >Date: Mon, 09 Jul 2001 15:04:02 -0400 >To: Thomas Narten >From: Daniel Senie >Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt > >I've commented on some of your comments. I've got some ideas on others, >but no immediate comments. Hopefully some other folks will have some >useful commentary as well. > >At 01:42 PM 7/9/01, you wrote: >>The WG has reqested this document be advanced as a Proposed >>Standard. In anticipation of starting the Last Call, I reviewed the >>document and have the following questions/comments. I'm sending this >>to the WG rather than just the authors as some if the issues go beyond >>just editorial clarification. >> >>Thomas >> >> 2.4 Source Address Selection >> >> Since each interface on a host may have a link-local address in >> addition to zero or more other addresses configured by other means >> (e.g. manually or via a DHCP server), a host may have to make a >> choice about what source address to use when it sends a packet or >> initiates a TCP connection. >> >> If the destination address is in the 169.254/16 prefix (including the >> 169.254.255.255 broadcast address), the host MUST use its link-local >> source address. >> >>The rules in this section seem overly strong to me. In particular, >>they make it a protocol violation to use certain combinations of >>addresses, when: >> >>a) it is not clear there is a need for such a restriction >>b) it makes it a protocol violation to use certain combinations when >> it seems to be that little or no harm would come from it (i.e, >> communication would work just fine). >> >>I'll also note that the decision here is different than the approach >>taken in IPv6, where the issue of addresses having different scopes is >>much more prevalent. >> >>Is this really needed? > >IMO, yes. > > >>Also, do these rules mean that a node can't just swap src/dest >>addresses when responding to a packet? If so, this would seem to be an >>extra check stacks must do, and it would also prevent certain types of >>communication where there would appear to be no harm in allowing it. >> >> If the destination address is in the 169.254/16 prefix (including the >> 169.254.255.255 broadcast address), the host MUST use its link-local >> source address. >> >>too strong? > >No. Not too strong. If the other station ONLY speaks link-local, it's >likely going to be unable to communicate with anything outside of >169.254/16. This rule ensures stations will be able to talk to one >another. A good thing, I think. > > >> If the destination address is: >> (a) a unicast address outside the 169.254/16 prefix, or >> (b) a multicast address with scope larger than link-local and >> the TTL in the IP header is greater than 1, >> then the host MUST NOT use its link-local source address, and should >> instead use an appropriate routable source address. >> >>why? > >link local addresses should not be used behind NAT devices, since there's >no mechanism to distribute a "default gateway" other than ICMP Router >Discovery, and the discussion on a proposal in this whole general area was >strongly opposed to using link local addresses with NAT gateways. > >Keeping link local to a truly local state avoids a variety of interesting >and odd cases. > >The limit on the TTL also ensures people don't try to route link-local, >which has some interesting (and likely bad) side effects (address conflict >resolutions, etc.). > > >> Any host receiving an IPv4 packet whose destination addresses is in >> the 169.254/16 prefix MUST discard the packet if the source address >> is not in the 169.254/16 prefix. > >Yes. This enforces the separation between link-local and other address >space. The list discussions were, as I recall, strongly in favor of >enforcing this separation. > > >> all zeroes. The 'target IP address' field MUST be set to the address >> being probed. An ARP request constructed this way with an all-zero >> 'sender IP address' is referred to as an "ARP probe". >> >>terminology: what is 'target IP address'? ARP has "target protocol >>address". ditto for sender IP address? I think the terminology may >>need tweaking throughout the document on this point. > >Agree this should get clarified. > > >> In addition, >> if during this period the host receives any ARP packet where the >> packet's 'target IP address' is the address being probed for, and >> the packet's 'sender hardware address' is not the hardware address >> of any of the host's interfaces, then the host MUST similarly treat >> this as an address collision and select a new address as above. This >> can occur if two (or more) hosts attempt to configure the same link- >> local address at the same time. >> >>They above text seems wrong. If a router is trying to ARP for my >>address, wouldn't it send out a packet that by the above rules >>indicate an address collision? Shouldn't the check be if the Sender >>Protocol address is IP address and is 0, and the hardware source >>address is not one of my own? > >I think the intent is that the arp be a gratuitous arp, arping for one's >own IP address. > > >> A host should maintain a counter of the number of address collisions >> it has experienced in the process of trying to acquire an address, >> and if the number of collisions exceeds ten then the host MUST limit >> the rate at which it probes for new addresses to no more than one new >> address per second. This is to prevent catastrophic ARP storms in >> pathological failure cases, such as a rogue host that answers all >> ARP probes, causing legitimate hosts to go into an infinite loop >> attempting to select a usable address. >> >>Hmm. Seems to me that if you have ten collisions in a row, you've >>either got: >> >>1) bad algorithm for chosing addresses, in which case retrying at all >> is a waste of time (or worse)... > >or random number generators in lock-step, but that's really a case of a >bad algorithm. > > >>2) DOS attack in progress in which someone is claiming ownership of >> all addresses. In this case, continuing on every second seems >> useless too. > >link-local has vulnerabilities to DoS, however the intent is to use it on >local links, where you should be able to find and slap silly the person >launching the attack. > > >>I'd suggest in the name of network friendliness that after ten tries, >>one should either quit entirely (maybe too extreme) or at least back >>off *very* significantly, say no more than once every few minutes or >>so. > >Quitting is a bad idea. It would mean that one disturbance on a network >could permanently shut down devices. Backing off is reasonable, though. > > >> (b) If a host currently has active TCP connections or other reasons >> to prefer to keep the same IP address, and it has not seen any other >> conflicting ARP packets recently (for Ethernet, within the last ten >> seconds) then it MAY elect to attempt to defend its address, by >> recording the time that the conflicting ARP packet was received, and >> then broadcasting one single gratuitous ARP request, giving its own >> IP and hardware addresses as the sender addresses of the ARP. Having >> done this, the host can then continue to use the address normally >> without any further special action. However, if this is not the first >> conflicting ARP packet the host has seen, and the time recorded for >> the previous conflicting ARP packet is recent (within ten seconds for >> Ethernet) then the host MUST immediately cease using this address and >> configure a new link-local IP address as described above. This is >> necessary to ensure that two hosts do not get stuck in an endless >> loop with both hosts trying to defend the same address. >> >>Once you've concluded that one of the nodes needs to give up its >>address, should you just pick one, rather than forcing both to pick a >>new one? I.e, let the lower numbered ethernet address win? At least >>that way only one gives up the address. This would be less disruptive >>on average. > >The question is how to pick who gives in. The idea of keying it off the >MAC address isn't bad, assuming a media type which has mac addresses. > > >> All ARP packets (replies as well as requests) that contain a link- >> local sender address SHOULD be sent using link-level broadcast >> instead of link-level unicast. This aids timely detection of >> duplicate addresses. An example illustrating how this helps is >> given in Section 4. >> >>Seems like this should be a MUST. Why should this be an implementation >>choice? > > > > >>Nits: >> >>Since MS has a patent on technology related to this document (see the >>IETF IPR Web Page), the document needs to include text noting that >>there are possible IPR concerns. In particular, just include >>paragraphs (A) and (D) of Section 10.4 in RFC 2026. Don't mention the >>specific patent itself in the document. >> >>needs an iana considerations section that indicates that IANA has >>assigned the 169.254 address for this purpose. >> >> the special rules regarding duplicate detection and automatic conf- >> iguration that pertain to addresses in this prefix. While RFC 2131 >> >>don't split words across lines... >> >> all zeroes. The 'target IP address' field MUST be set to the address >> being probed. An ARP request constructed this way with an all-zero >> 'sender IP address' is referred to as an "ARP probe". ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Tue Jul 10 15:42:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17327 for ; Tue, 10 Jul 2001 15:42:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B832B91253; Tue, 10 Jul 2001 15:42:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85F0491254; Tue, 10 Jul 2001 15:42:12 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A67C491253 for ; Tue, 10 Jul 2001 15:42:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3A415DE0F; Tue, 10 Jul 2001 15:43:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 67C925DDD8 for ; Tue, 10 Jul 2001 15:43:40 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA22118 for ; Tue, 10 Jul 2001 12:42:37 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 10 Jul 2001 12:42:35 -0700 Received: from [206.111.147.149] (vpn-gh-1045.apple.com [17.254.140.20]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id MAA13532; Tue, 10 Jul 2001 12:42:34 -0700 (PDT) Message-Id: <200107101942.MAA13532@scv3.apple.com> Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Tue, 10 Jul 2001 12:42:33 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Thomas Narten" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Thanks for your quick response to our request for document review. I have attempted to answer your comments below: ---- > 2.4 Source Address Selection > >The rules in this section seem overly strong to me. In particular, >they make it a protocol violation to use certain combinations of >addresses, when: > >a) it is not clear there is a need for such a restriction >b) it makes it a protocol violation to use certain combinations when > it seems to be that little or no harm would come from it (i.e, > communication would work just fine). The intention here was to limit accidental leakage of 169.254/16 packets into or out of the local link. Leakage into the local link exposes link-local devices to potential attack from a larger set of hosts than their designer may have designed for. Leakage out of the local link potentially annoys network operators, making them complain, "what are these 169.254/16 packets doing on my network?" However, with the TTL=255 check advocated by Dave Thaler and others, link-local devices have a better way to protect against external packets leaking into the local link, and arguably, annoying network operators is not our concern -- they should filter out errant 169.254/16 packets if they are worried about them. If no one makes strong arguments to the contrary, I am happy to relax these requirements. (See below.) ---- > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host MUST use its link-local > source address. > >too strong? Would the following be acceptable? If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link-local source address if it has one. ---- > If the destination address is: > (a) a unicast address outside the 169.254/16 prefix, or > (b) a multicast address with scope larger than link-local and > the TTL in the IP header is greater than 1, > then the host MUST NOT use its link-local source address, and should > instead use an appropriate routable source address. Would the following be acceptable? then the host SHOULD use an appropriate routable source address if it has one. ---- > Any host receiving an IPv4 packet whose destination addresses is in > the 169.254/16 prefix MUST discard the packet if the source address > is not in the 169.254/16 prefix. This can be deleted. ---- > all zeroes. The 'target IP address' field MUST be set to the address > being probed. An ARP request constructed this way with an all-zero > 'sender IP address' is referred to as an "ARP probe". > >terminology: what is 'target IP address'? ARP has "target protocol >address". ditto for sender IP address? I think the terminology may >need tweaking throughout the document on this point. My experience with earlier drafts of this document is that many of its readers asked questions which made it clear they knew little about ARP. My feeling was that the term 'sender IP address' is clear and unambiguous to more readers than the term 'sender protocol address', and I did not want to make this document unnecessarily obscure to the majority of readers. Would the following introductory text in the "Conventions and Terminology" section be acceptable? Wherever this document uses the term "sender IP address" or "target IP address" it is referring to the fields of the ARP packet identified in the ARP specification [RFC 826] as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol Address) respectively. For the usage of ARP described in this document, these fields always contain an IP address. ---- > In addition, > if during this period the host receives any ARP packet where the > packet's 'target IP address' is the address being probed for, and > the packet's 'sender hardware address' is not the hardware address > of any of the host's interfaces, then the host MUST similarly treat > this as an address collision and select a new address as above. This > can occur if two (or more) hosts attempt to configure the same link- > local address at the same time. > >They above text seems wrong. If a router is trying to ARP for my >address, wouldn't it send out a packet that by the above rules >indicate an address collision? Shouldn't the check be if the Sender >Protocol address is IP address and is 0, and the hardware source >address is not one of my own? If a router is trying to ARP for my address, then it *cannot* be trying to talk to *me*, since I just picked this random number, and have not yet advertised that fact to the world. Hence if a router (or any host) is trying to ARP for this address, then that must mean that *someone else* is (or was recently) using this address. Hence it is safest if I don't use this address. ---- > A host should maintain a counter of the number of address collisions > it has experienced in the process of trying to acquire an address, > and if the number of collisions exceeds ten then the host MUST limit > the rate at which it probes for new addresses to no more than one new > address per second. This is to prevent catastrophic ARP storms in > pathological failure cases, such as a rogue host that answers all > ARP probes, causing legitimate hosts to go into an infinite loop > attempting to select a usable address. > >Hmm. Seems to me that if you have ten collisions in a row, you've >either got: > >1) bad algorithm for chosing addresses, in which case retrying at all > is a waste of time (or worse)... > >2) DOS attack in progress in which someone is claiming ownership of > all addresses. In this case, continuing on every second seems > useless too. There are networks at Apple with 1000 active hosts and 1016 usable AppleTalk addresses. Hosts regularly AARP 60 times or more before getting a free AppleTalk address. I'm not saying this is good, just observing that it happens. >I'd suggest in the name of network friendliness that after ten tries, >one should either quit entirely (maybe too extreme) or at least back >off *very* significantly, say no more than once every few minutes or >so. Is "no more than one new address per minute" acceptable? ---- > (b) If a host currently has active TCP connections or other reasons > to prefer to keep the same IP address, and it has not seen any other > conflicting ARP packets recently (for Ethernet, within the last ten > seconds) then it MAY elect to attempt to defend its address, by > recording the time that the conflicting ARP packet was received, and > then broadcasting one single gratuitous ARP request, giving its own > IP and hardware addresses as the sender addresses of the ARP. Having > done this, the host can then continue to use the address normally > without any further special action. However, if this is not the first > conflicting ARP packet the host has seen, and the time recorded for > the previous conflicting ARP packet is recent (within ten seconds for > Ethernet) then the host MUST immediately cease using this address and > configure a new link-local IP address as described above. This is > necessary to ensure that two hosts do not get stuck in an endless > loop with both hosts trying to defend the same address. > >Once you've concluded that one of the nodes needs to give up its >address, should you just pick one, rather than forcing both to pick a >new one? I.e, let the lower numbered ethernet address win? At least >that way only one gives up the address. This would be less disruptive >on average. This "defend once" behaviour usually provides this result. Collisions not detected during the probing phase are usually because someone booted up their laptop first, and then plugged it into an Ethernet hub. The first network operation they try to do on their laptop will almost always result in an ARP request being broadcast, which the other host sees, defends once, and then the laptop reconfigures. ---- > All ARP packets (replies as well as requests) that contain a link- > local sender address SHOULD be sent using link-level broadcast > instead of link-level unicast. This aids timely detection of > duplicate addresses. An example illustrating how this helps is > given in Section 4. > >Seems like this should be a MUST. Why should this be an implementation >choice? Older Mac OS and Windows did not broadcast ARP *replies*, yet they still broadcast ARP *requests* frequently enough that collision detection was effective. Broadcasting ARP replies as well is certainly better, because it enables quicker collision detection? I will change this to a MUST if no one makes strong arguments to the contrary. ---- >Since MS has a patent on technology related to this document (see the >IETF IPR Web Page), the document needs to include text noting that >there are possible IPR concerns. In particular, just include >paragraphs (A) and (D) of Section 10.4 in RFC 2026. Don't mention the >specific patent itself in the document. Done. ---- >needs an iana considerations section that indicates that IANA has >assigned the 169.254 address for this purpose. Done: 6. IANA Considerations The IANA has allocated the network prefix 169.254/16 for the use described in this document. No other IANA services are required by this document. ---- Thanks for your comments. I await feedback from other Working Group members. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Jul 10 15:43:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17419 for ; Tue, 10 Jul 2001 15:43:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B807991254; Tue, 10 Jul 2001 15:43:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85C3991255; Tue, 10 Jul 2001 15:43:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A646791254 for ; Tue, 10 Jul 2001 15:43:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBBC15DE0F; Tue, 10 Jul 2001 15:44:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 602805DDD8 for ; Tue, 10 Jul 2001 15:44:43 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id MAA28042 for ; Tue, 10 Jul 2001 12:43:40 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 10 Jul 2001 12:41:55 +0100 Received: from [206.111.147.149] (vpn-gh-1045.apple.com [17.254.140.20]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id MAA13865; Tue, 10 Jul 2001 12:43:39 -0700 (PDT) Message-Id: <200107101943.MAA13865@scv3.apple.com> Subject: Re: draft-ietf-zeroconf-reqts-08.txt Date: Tue, 10 Jul 2001 12:43:37 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Thomas Narten" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I'll let Myron, our document editor, answer the points in detail, but I have two quick comments of my own: >This may be a minor nit, but it may be worth pointing out that DHCP >*protocols* could be used in a zeroconf environment, so long as no >user configuration were needed. One can imagine a DHCP server figuring >out a lot of things on its own without being configured (and there has >been talk on the list about this). "Zeroconf" != "Zero User Admin" If there's a DHCP server on the network, then it is acting as a central repository of authoritative configuration information for client hosts. It does't matter whether that DHCP server was configured by the end user or by the manufacturer, from the client host's point of view it's just a regular old configured network. This works today (e.g. the Apple AirPort base station, and many other similar devices, do this). If the answer to the Zeroconf problem is, "plug an AirPort base station into your network and carry on running your old host software," then the IETF didn't need a Working Group just to rubber-stamp Apple's AirPort base station with a cool "Zeroconf Compliant" logo. No, the focus of Zeroconf is, "IP should work even if there *isn't* a DHCP server on the network." >This text curiously doesn't mention the DNS. But, for the web server, >isn't the DNS reverse lookup specifically what is assumed/required? >Seems like the reqirement is much more specific than just "translate >name to address" and vice versa, and involves integration with the >DNS. In practice, we believe that Multicast DNS will be the answer. However, from a strict requirements standpoint, the web server calls an OS or library API routine to map an address to a name -- whether that's done using DNS packets, or mDNS, or NetBIOS, is of no concern to the web server software. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Jul 10 23:14:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06704 for ; Tue, 10 Jul 2001 23:14:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A278191201; Tue, 10 Jul 2001 21:47:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E05D91233; Tue, 10 Jul 2001 21:47:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7428291201 for ; Tue, 10 Jul 2001 21:47:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 115EE5DDA9; Tue, 10 Jul 2001 21:48:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by segue.merit.edu (Postfix) with ESMTP id 9E9E15DDA7 for ; Tue, 10 Jul 2001 21:48:30 -0400 (EDT) Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id f6B1lCr27657; Tue, 10 Jul 2001 18:47:12 -0700 (PDT) Received: from galatica.pc.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id SAA06969; Tue, 10 Jul 2001 18:47:16 -0700 (PDT) Received: by GALATICA with Internet Mail Service (5.5.2448.0) id ; Tue, 10 Jul 2001 18:26:52 -0700 Message-ID: From: Jim Busse To: Stuart Cheshire , Thomas Narten , zeroconf@merit.edu Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Tue, 10 Jul 2001 18:26:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Sturart: It' s too long, so I'll just put this at the top: > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host MUST use its link-local > source address. > >too strong? In my opinion, is no reason to change the wording to "should". I think the concept that the169/254/16 prefix packets are coming from a "friendly" link-local network, the use of some other address may look like an "intruder". I like the original wording best. Maybe Thomas could give a reason for the "too strong"? -----Original Message----- From: Stuart Cheshire [mailto:cheshire@apple.com] Sent: Tuesday, July 10, 2001 12:43 PM To: Thomas Narten; zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt Thanks for your quick response to our request for document review. I have attempted to answer your comments below: ---- > 2.4 Source Address Selection > >The rules in this section seem overly strong to me. In particular, >they make it a protocol violation to use certain combinations of >addresses, when: > >a) it is not clear there is a need for such a restriction >b) it makes it a protocol violation to use certain combinations when > it seems to be that little or no harm would come from it (i.e, > communication would work just fine). The intention here was to limit accidental leakage of 169.254/16 packets into or out of the local link. Leakage into the local link exposes link-local devices to potential attack from a larger set of hosts than their designer may have designed for. Leakage out of the local link potentially annoys network operators, making them complain, "what are these 169.254/16 packets doing on my network?" However, with the TTL=255 check advocated by Dave Thaler and others, link-local devices have a better way to protect against external packets leaking into the local link, and arguably, annoying network operators is not our concern -- they should filter out errant 169.254/16 packets if they are worried about them. If no one makes strong arguments to the contrary, I am happy to relax these requirements. (See below.) ---- > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host MUST use its link-local > source address. > >too strong? Would the following be acceptable? If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link-local source address if it has one. ---- > If the destination address is: > (a) a unicast address outside the 169.254/16 prefix, or > (b) a multicast address with scope larger than link-local and > the TTL in the IP header is greater than 1, > then the host MUST NOT use its link-local source address, and should > instead use an appropriate routable source address. Would the following be acceptable? then the host SHOULD use an appropriate routable source address if it has one. ---- > Any host receiving an IPv4 packet whose destination addresses is in > the 169.254/16 prefix MUST discard the packet if the source address > is not in the 169.254/16 prefix. This can be deleted. ---- > all zeroes. The 'target IP address' field MUST be set to the address > being probed. An ARP request constructed this way with an all-zero > 'sender IP address' is referred to as an "ARP probe". > >terminology: what is 'target IP address'? ARP has "target protocol >address". ditto for sender IP address? I think the terminology may >need tweaking throughout the document on this point. My experience with earlier drafts of this document is that many of its readers asked questions which made it clear they knew little about ARP. My feeling was that the term 'sender IP address' is clear and unambiguous to more readers than the term 'sender protocol address', and I did not want to make this document unnecessarily obscure to the majority of readers. Would the following introductory text in the "Conventions and Terminology" section be acceptable? Wherever this document uses the term "sender IP address" or "target IP address" it is referring to the fields of the ARP packet identified in the ARP specification [RFC 826] as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol Address) respectively. For the usage of ARP described in this document, these fields always contain an IP address. ---- > In addition, > if during this period the host receives any ARP packet where the > packet's 'target IP address' is the address being probed for, and > the packet's 'sender hardware address' is not the hardware address > of any of the host's interfaces, then the host MUST similarly treat > this as an address collision and select a new address as above. This > can occur if two (or more) hosts attempt to configure the same link- > local address at the same time. > >They above text seems wrong. If a router is trying to ARP for my >address, wouldn't it send out a packet that by the above rules >indicate an address collision? Shouldn't the check be if the Sender >Protocol address is IP address and is 0, and the hardware source >address is not one of my own? If a router is trying to ARP for my address, then it *cannot* be trying to talk to *me*, since I just picked this random number, and have not yet advertised that fact to the world. Hence if a router (or any host) is trying to ARP for this address, then that must mean that *someone else* is (or was recently) using this address. Hence it is safest if I don't use this address. ---- > A host should maintain a counter of the number of address collisions > it has experienced in the process of trying to acquire an address, > and if the number of collisions exceeds ten then the host MUST limit > the rate at which it probes for new addresses to no more than one new > address per second. This is to prevent catastrophic ARP storms in > pathological failure cases, such as a rogue host that answers all > ARP probes, causing legitimate hosts to go into an infinite loop > attempting to select a usable address. > >Hmm. Seems to me that if you have ten collisions in a row, you've >either got: > >1) bad algorithm for chosing addresses, in which case retrying at all > is a waste of time (or worse)... > >2) DOS attack in progress in which someone is claiming ownership of > all addresses. In this case, continuing on every second seems > useless too. There are networks at Apple with 1000 active hosts and 1016 usable AppleTalk addresses. Hosts regularly AARP 60 times or more before getting a free AppleTalk address. I'm not saying this is good, just observing that it happens. >I'd suggest in the name of network friendliness that after ten tries, >one should either quit entirely (maybe too extreme) or at least back >off *very* significantly, say no more than once every few minutes or >so. Is "no more than one new address per minute" acceptable? ---- > (b) If a host currently has active TCP connections or other reasons > to prefer to keep the same IP address, and it has not seen any other > conflicting ARP packets recently (for Ethernet, within the last ten > seconds) then it MAY elect to attempt to defend its address, by > recording the time that the conflicting ARP packet was received, and > then broadcasting one single gratuitous ARP request, giving its own > IP and hardware addresses as the sender addresses of the ARP. Having > done this, the host can then continue to use the address normally > without any further special action. However, if this is not the first > conflicting ARP packet the host has seen, and the time recorded for > the previous conflicting ARP packet is recent (within ten seconds for > Ethernet) then the host MUST immediately cease using this address and > configure a new link-local IP address as described above. This is > necessary to ensure that two hosts do not get stuck in an endless > loop with both hosts trying to defend the same address. > >Once you've concluded that one of the nodes needs to give up its >address, should you just pick one, rather than forcing both to pick a >new one? I.e, let the lower numbered ethernet address win? At least >that way only one gives up the address. This would be less disruptive >on average. This "defend once" behaviour usually provides this result. Collisions not detected during the probing phase are usually because someone booted up their laptop first, and then plugged it into an Ethernet hub. The first network operation they try to do on their laptop will almost always result in an ARP request being broadcast, which the other host sees, defends once, and then the laptop reconfigures. ---- > All ARP packets (replies as well as requests) that contain a link- > local sender address SHOULD be sent using link-level broadcast > instead of link-level unicast. This aids timely detection of > duplicate addresses. An example illustrating how this helps is > given in Section 4. > >Seems like this should be a MUST. Why should this be an implementation >choice? Older Mac OS and Windows did not broadcast ARP *replies*, yet they still broadcast ARP *requests* frequently enough that collision detection was effective. Broadcasting ARP replies as well is certainly better, because it enables quicker collision detection? I will change this to a MUST if no one makes strong arguments to the contrary. ---- >Since MS has a patent on technology related to this document (see the >IETF IPR Web Page), the document needs to include text noting that >there are possible IPR concerns. In particular, just include >paragraphs (A) and (D) of Section 10.4 in RFC 2026. Don't mention the >specific patent itself in the document. Done. ---- >needs an iana considerations section that indicates that IANA has >assigned the 169.254 address for this purpose. Done: 6. IANA Considerations The IANA has allocated the network prefix 169.254/16 for the use described in this document. No other IANA services are required by this document. ---- Thanks for your comments. I await feedback from other Working Group members. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Jul 11 03:31:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27137 for ; Wed, 11 Jul 2001 03:31:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2405B91233; Wed, 11 Jul 2001 03:31:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3F0891234; Wed, 11 Jul 2001 03:31:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A58991233 for ; Wed, 11 Jul 2001 03:31:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5BCD65DD93; Wed, 11 Jul 2001 03:33:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id ADAD05DD8F for ; Wed, 11 Jul 2001 03:33:09 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id AAA19302 for ; Wed, 11 Jul 2001 00:32:05 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 11 Jul 2001 00:30:16 +0100 Received: from [206.111.147.149] (vpn-gh-1045.apple.com [17.254.140.20]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id AAA02776; Wed, 11 Jul 2001 00:32:00 -0700 (PDT) Message-Id: <200107110732.AAA02776@scv3.apple.com> Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Wed, 11 Jul 2001 00:31:57 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Jim Busse" , "Thomas Narten" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >In my opinion, is no reason to change the wording to "should". I think the >concept that the169/254/16 prefix packets are coming from a "friendly" >link-local network, the use of some other address may look like an >"intruder". I like the original wording best. Maybe Thomas could give a >reason for the "too strong"? I think the reasoning is this: Say you have two devices on the same physical Ethernet. Device A implements link-local addresses, and has assigned itself one. Device B does not implement link-local addresses, but has a manually configured address of 10.0.0.1. These devices are on the same physical Ethernet. Is it useful for the link-local draft to prohibit them from talking to each other? We may like to dictate that Device B MUST implement link-local addresses, but the world doesn't work like that. If the vendor of Device B doesn't have the engineering resources to implement link-local addresses, then is it better for the user if the devices can talk safely, or not? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Jul 11 09:30:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02835 for ; Wed, 11 Jul 2001 09:30:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E8A591236; Wed, 11 Jul 2001 09:29:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C74F91238; Wed, 11 Jul 2001 09:29:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73A8791236 for ; Wed, 11 Jul 2001 09:29:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B01505DD93; Wed, 11 Jul 2001 09:31:21 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id 081FA5DD90 for ; Wed, 11 Jul 2001 09:31:19 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6BDS9d01696; Wed, 11 Jul 2001 09:28:10 -0400 Message-Id: <200107111328.f6BDS9d01696@hygro.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt In-Reply-To: Message from Stuart Cheshire of "Tue, 10 Jul 2001 12:42:33 PDT." <200107101942.MAA13532@scv3.apple.com> Date: Wed, 11 Jul 2001 09:28:09 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart Cheshire writes: > > 2.4 Source Address Selection > > > >The rules in this section seem overly strong to me. In particular, > >they make it a protocol violation to use certain combinations of > >addresses, when: > > > >a) it is not clear there is a need for such a restriction > >b) it makes it a protocol violation to use certain combinations when > > it seems to be that little or no harm would come from it (i.e, > > communication would work just fine). > The intention here was to limit accidental leakage of 169.254/16 packets > into or out of the local link. > Leakage into the local link exposes link-local devices to potential > attack from a larger set of hosts than their designer may have designed > for. > Leakage out of the local link potentially annoys network operators, > making them complain, "what are these 169.254/16 packets doing on my > network?" > However, with the TTL=255 check advocated by Dave Thaler and others, > link-local devices have a better way to protect against external packets > leaking into the local link, and arguably, annoying network operators is > not our concern -- they should filter out errant 169.254/16 packets if > they are worried about them. Right. You don't want routers to forward packets. But if two nodes on the same link happen to use a link-local/global address combination, why disallow that? That is where I'm coming from. And, the way to ensure that a node that is using link-local addresses doesn't accidentally talk to someone behind a router is to use something like the TTL=255 trick. I.e., this does not rely on other boxes to "behave". An attacker, for instance, wouldn't follow the rules. Hmm. The following requirement: > 2.5 Link-Local Addresses Are Not Forwarded > > Any host sending an IPv4 packet to a destination addresses in the > 169.254/16 prefix MUST set the TTL in the IP header to 255. Any > host receiving an IPv4 packet whose destination addresses is in the > 169.254/16 prefix MUST discard the packet if the TTL in the IP header > is not 255. Doesn't the latter rule mean that devices that implement this specification WILL NOT interoperate with existing devices that use link-local addresses? I.e, for the stacks that already support link-local addresses, do they always set the TTL to 255? > If no one makes strong arguments to the contrary, I am happy to relax > these requirements. (See below.) > ---- > > If the destination address is in the 169.254/16 prefix (including the > > 169.254.255.255 broadcast address), the host MUST use its link-local > > source address. > > > >too strong? > Would the following be acceptable? > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host SHOULD use its link-local > source address if it has one. Personally, I think SHOULDs for all these cases is better. But I leave it to the WG. I'm just raising the issue. > > Any host receiving an IPv4 packet whose destination addresses is in > > the 169.254/16 prefix MUST discard the packet if the source address > > is not in the 169.254/16 prefix. > This can be deleted. Works for me. > ---- > > all zeroes. The 'target IP address' field MUST be set to the address > > being probed. An ARP request constructed this way with an all-zero > > 'sender IP address' is referred to as an "ARP probe". > > > >terminology: what is 'target IP address'? ARP has "target protocol > >address". ditto for sender IP address? I think the terminology may > >need tweaking throughout the document on this point. > My experience with earlier drafts of this document is that many of its > readers asked questions which made it clear they knew little about ARP. > My feeling was that the term 'sender IP address' is clear and unambiguous > to more readers than the term 'sender protocol address', and I did not > want to make this document unnecessarily obscure to the majority of > readers. > Would the following introductory text in the "Conventions and > Terminology" section be acceptable? > Wherever this document uses the term "sender IP address" or > "target IP address" it is referring to the fields of the ARP > packet identified in the ARP specification [RFC 826] as "ar$spa" > (Sender Protocol Address) and "ar$tpa" (Target Protocol Address) > respectively. For the usage of ARP described in this document, > these fields always contain an IP address. This works for me. > ---- > > In addition, > > if during this period the host receives any ARP packet where the > > packet's 'target IP address' is the address being probed for, and > > the packet's 'sender hardware address' is not the hardware address > > of any of the host's interfaces, then the host MUST similarly treat > > this as an address collision and select a new address as above. This > > can occur if two (or more) hosts attempt to configure the same link- > > local address at the same time. > > > >They above text seems wrong. If a router is trying to ARP for my > >address, wouldn't it send out a packet that by the above rules > >indicate an address collision? Shouldn't the check be if the Sender > >Protocol address is IP address and is 0, and the hardware source > >address is not one of my own? > If a router is trying to ARP for my address, then it *cannot* be trying > to talk to *me*, since I just picked this random number, and have not yet > advertised that fact to the world. Hence if a router (or any host) is > trying to ARP for this address, then that must mean that *someone else* > is (or was recently) using this address. Hence it is safest if I don't > use this address. What about the case where a node uses a link-local address, shuts down, and then restarts. Per the document, it should try to use the same address. Other devices could still be trying to communicate with the device using its previous (and soon-to-be current) address. This can happen with any node on the link, not just the router. > There are networks at Apple with 1000 active hosts and 1016 usable > AppleTalk addresses. Hosts regularly AARP 60 times or more before getting > a free AppleTalk address. I'm not saying this is good, just observing > that it happens. We shouldn't be operating in this kind of environment. The 169.254/16 address has more like 65K usable addresses. > >I'd suggest in the name of network friendliness that after ten tries, > >one should either quit entirely (maybe too extreme) or at least back > >off *very* significantly, say no more than once every few minutes or > >so. > Is "no more than one new address per minute" acceptable? This would be better, but might still be a bit aggressive. In a large environment with a bridged network, the traffic could be a problem. We want this to follow the "do no harm" rule if a device gets plugged in somewhere where the zeroconf stuff gets invoked, even though maybe it shouldn't. I'm not sure what the right number should be. > >Once you've concluded that one of the nodes needs to give up its > >address, should you just pick one, rather than forcing both to pick a > >new one? I.e, let the lower numbered ethernet address win? At least > >that way only one gives up the address. This would be less disruptive > >on average. > This "defend once" behaviour usually provides this result. Collisions not > detected during the probing phase are usually because someone booted up > their laptop first, and then plugged it into an Ethernet hub. The first > network operation they try to do on their laptop will almost always > result in an ARP request being broadcast, which the other host sees, > defends once, and then the laptop reconfigures. I agree the defend once handles the case of a newly booting device. But what about a bridge network being connected together? The requirements document indicates that this case must be handled, and for *that* case, where two nodes are using an address, it would see to be better to let one continue using it rather than forcing both to reset. Thomas From owner-zeroconf@merit.edu Wed Jul 11 09:30:14 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02850 for ; Wed, 11 Jul 2001 09:30:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A089791235; Wed, 11 Jul 2001 09:29:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7699091236; Wed, 11 Jul 2001 09:29:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 766C791235 for ; Wed, 11 Jul 2001 09:29:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F01895DD93; Wed, 11 Jul 2001 09:31:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id E75955DD90 for ; Wed, 11 Jul 2001 09:31:08 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6BDS1J01689; Wed, 11 Jul 2001 09:28:01 -0400 Message-Id: <200107111328.f6BDS1J01689@hygro.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-reqts-08.txt In-Reply-To: Message from Stuart Cheshire of "Tue, 10 Jul 2001 12:43:37 PDT." <200107101943.MAA13865@scv3.apple.com> Date: Wed, 11 Jul 2001 09:28:01 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart Cheshire writes: > >This text curiously doesn't mention the DNS. But, for the web server, > >isn't the DNS reverse lookup specifically what is assumed/required? > >Seems like the reqirement is much more specific than just "translate > >name to address" and vice versa, and involves integration with the > >DNS. > In practice, we believe that Multicast DNS will be the answer. However, > from a strict requirements standpoint, the web server calls an OS or > library API routine to map an address to a name -- whether that's done > using DNS packets, or mDNS, or NetBIOS, is of no concern to the web > server software. Is there any sort of requirement that whatever is developed is transparent to existing applications? I.e., looks like DNS to (most) applications? I would think that requiring applications to be aware that they are on a zeroconf network and then behave differently sets a pretty high bar. Seems to me like the requirement could be specified with a bit more detail. Thomas From owner-zeroconf@merit.edu Wed Jul 11 09:30:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02861 for ; Wed, 11 Jul 2001 09:30:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF3F891238; Wed, 11 Jul 2001 09:30:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51E4491237; Wed, 11 Jul 2001 09:30:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2457291238 for ; Wed, 11 Jul 2001 09:30:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9ED9F5DD93; Wed, 11 Jul 2001 09:31:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id D1F8C5DD90 for ; Wed, 11 Jul 2001 09:31:28 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6BDSNY01710; Wed, 11 Jul 2001 09:28:23 -0400 Message-Id: <200107111328.f6BDSNY01710@hygro.adsl.duke.edu> To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt In-Reply-To: Message from Daniel Senie of "Mon, 09 Jul 2001 15:04:02 EDT." <5.1.0.14.2.20010709145110.03e81600@mail.amaranth.net> Date: Wed, 11 Jul 2001 09:28:23 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Daniel Senie writes: > > If the destination address is: > > (a) a unicast address outside the 169.254/16 prefix, or > > (b) a multicast address with scope larger than link-local and > > the TTL in the IP header is greater than 1, > > then the host MUST NOT use its link-local source address, and should > > instead use an appropriate routable source address. > > > >why? > link local addresses should not be used behind NAT devices, since there's > no mechanism to distribute a "default gateway" other than ICMP Router > Discovery, and the discussion on a proposal in this whole general area was > strongly opposed to using link local addresses with NAT gateways. > Keeping link local to a truly local state avoids a variety of interesting > and odd cases. > The limit on the TTL also ensures people don't try to route link-local, > which has some interesting (and likely bad) side effects (address conflict > resolutions, etc.). IMO, having routers not forward link-local packets and doing the TTL=255 trick provides adequate protection to the forwarding problem. I think I've responded to your other comments in other postings. > >I'd suggest in the name of network friendliness that after ten tries, > >one should either quit entirely (maybe too extreme) or at least back > >off *very* significantly, say no more than once every few minutes or > >so. > Quitting is a bad idea. It would mean that one disturbance on a network > could permanently shut down devices. Backing off is reasonable, though. Right. I think you want to backoff enough so that the traffic contributed doesn't become an issue (once a second seems too high). I agree also that if you quit, then you run into the situation where a temporary hiccup in the network doesn't get corrected on its own (i.e., nodes would need to be restarted after the network was back in proper working order). That's not something we want either. Thomas From owner-zeroconf@merit.edu Wed Jul 11 09:33:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02942 for ; Wed, 11 Jul 2001 09:33:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A11B191237; Wed, 11 Jul 2001 09:33:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7108D9123A; Wed, 11 Jul 2001 09:33:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 873CD91237 for ; Wed, 11 Jul 2001 09:33:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15F825DD93; Wed, 11 Jul 2001 09:35:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 9CCDE5DD90 for ; Wed, 11 Jul 2001 09:35:23 -0400 (EDT) Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6BDY9p25335 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 11 Jul 2001 09:34:09 -0400 Message-Id: <5.1.0.14.2.20010711092739.00a9d580@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 09:34:08 -0400 To: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , From: Daniel Senie Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt In-Reply-To: <200107110732.AAA02776@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 03:31 AM 7/11/01, Stuart Cheshire wrote: > >In my opinion, is no reason to change the wording to "should". I think the > >concept that the169/254/16 prefix packets are coming from a "friendly" > >link-local network, the use of some other address may look like an > >"intruder". I like the original wording best. Maybe Thomas could give a > >reason for the "too strong"? > >I think the reasoning is this: > >Say you have two devices on the same physical Ethernet. Device A >implements link-local addresses, and has assigned itself one. Device B >does not implement link-local addresses, but has a manually configured >address of 10.0.0.1. > >These devices are on the same physical Ethernet. Is it useful for the >link-local draft to prohibit them from talking to each other? If a link-local device has only 169.254/16 in its admittedly small routing table, won't it just look at the 10/8 address and decide there's no route to that network? There's no default route, and no way for it to know that it should try to ARP for that 10/8 address. So, it still won't communicate. >We may like to dictate that Device B MUST implement link-local addresses, >but the world doesn't work like that. If the vendor of Device B doesn't >have the engineering resources to implement link-local addresses, then is >it better for the user if the devices can talk safely, or not? My point here is that if the other device tries to answer with the non-link-local address, a box working in link-local-only mode may have no way to respond. If boxes are going to use multiple addresses, then we have to handle communicating with boxes which don't know how to reach any addresses other than link-local. Alternatively (and I'm not in favor of this alternative), we could say that a box which is running link-local-only should indeed treat 0/0 as link local, and ARP for any and all addresses. This would seem to be a very bad idea. While it would allow a device in link-local-only mode to talk to a box with both link-local and another address to function, it would also allow a link-local-only box to talk to a box with only a configured address. This box with the configured address would not know to ARP for the link-local address on the local wire, though, if it's only configured for non-link-local. I think any change in this area would require touching most hosts code to ensure compatability. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 10:59:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06297 for ; Wed, 11 Jul 2001 10:59:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4FC39123B; Wed, 11 Jul 2001 10:59:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACDB59123D; Wed, 11 Jul 2001 10:59:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B8D9D9123B for ; Wed, 11 Jul 2001 10:59:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 623A35DDB9; Wed, 11 Jul 2001 11:00:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 04C3B5DDA9 for ; Wed, 11 Jul 2001 11:00:42 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02678; Wed, 11 Jul 2001 07:59:33 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA10984; Wed, 11 Jul 2001 16:59:27 +0200 (MET DST) Date: Wed, 11 Jul 2001 17:11:30 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: draft-ietf-zeroconf-reqts-08.txt To: Thomas Narten Cc: Daniel Senie , zeroconf@merit.edu In-Reply-To: "Your message with ID" <200107111327.f6BDRqi01681@hygro.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > > > 2.2.1 Web Browsing > > > > Requirement: > > > > - MUST translate a name to an IP address. > > > > - MUST translate an IP address to a name. > > > > > >This text curiously doesn't mention the DNS. But, for the web server, > > >isn't the DNS reverse lookup specifically what is assumed/required? > > > Web servers as such are not dependent on DNS in any form. Implementations > > of web servers often have such dependencies, but reverse lookups are NOT > > required for proper operation of web servers. > > But the text in the document specifically says web servers do the reverse > mapping, and that drives the requirement that a reverse mapping be > doable. Existing web servers use the DNS for this. Are you saying that > in a zeroconf environment, Web servers can and/or should use something > other than DNS to do the reverse mapping? > > The point I'm trying to amke is that it seems misleading at best to > suggest that a generic address to name mapping is needed, if what is > actually needed is one that applications can use just as they do today > with DNS. Yes. What we want to say is that the upper layer support apps relying on RFC 1123 DNS interfaces will continue to be supported. We do not have to, nor should we, say in the reqts doc how this support is achieved. > > >Seems like the reqirement is much more specific than just "translate > > >name to address" and vice versa, and involves integration with the > > >DNS. > > > Zeroconf is an environment without servers. How are you going to do a DNS > > lookup without a server? > > The web server example above says they will need to do the reverse > mapping. The web server example is motivate and support the listed reqts for forward and reverse lookup. What we should really do, perhaps, is require support for RFC 1123, section 6.1. > > > > 2.4 Service Discovery Scenarios > > > > > > > > Service discovery protocols allow users to select services and/or > > > > hosts by a name that is discovered dynamically, rather than requiring > > > > that the user know the name in advance and type it in correctly. > > > > > >Can't an application find and select services without the user being > > >queried? E.g., isn't DNS a service? Should the user choose the DNS > > >server? > > > If there's no server serving DNS, it'll be hard to use it. > > Yes. The text suggests that service discovery requires user choose > from a menu of choices. Is that also true of services like the DNS? > Does the above exclude services that are generic and where it doesn't > matter who offers it? What we really want to say is that services can be discovered and selected, by users or by a computer program. That way the location of the server does not need to be known in advance for client-server software to function. We will quickly get into a rathole about DNS here. One can use mDNS to resolve DNS names when there is no DNS server. You can query DNS SRV RRs to request service instances by type. That type is a name. So, the essential thing is not that one doesn't know the name of the service in advance, but rather, one doesn't know the particular server instance yet. One uses a service discovery protocol to obtain these concrete service locations. In summary, I suggest that this text be changed to: 2.4 Service Discovery Scenarios Service discovery protocols allow users or software to discover instances and select among available services. This removes the requirement that the user or client software know a server's location in advance and in order for the client to communicate with the server. Erik From owner-zeroconf@merit.edu Wed Jul 11 11:14:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06938 for ; Wed, 11 Jul 2001 11:14:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5471291234; Wed, 11 Jul 2001 09:29:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2667F91235; Wed, 11 Jul 2001 09:29:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C93991234 for ; Wed, 11 Jul 2001 09:29:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 223FF5DE1A; Wed, 11 Jul 2001 09:31:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id C46575DE06 for ; Wed, 11 Jul 2001 09:30:59 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6BDRqi01681; Wed, 11 Jul 2001 09:27:52 -0400 Message-Id: <200107111327.f6BDRqi01681@hygro.adsl.duke.edu> To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-reqts-08.txt In-Reply-To: Message from Daniel Senie of "Mon, 09 Jul 2001 15:11:57 EDT." <5.1.0.14.2.20010709150627.03df2430@mail.amaranth.net> Date: Wed, 11 Jul 2001 09:27:52 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Daniel Senie writes: > At 02:04 PM 7/9/01, Thomas Narten wrote: > >This may be a minor nit, but it may be worth pointing out that DHCP > >*protocols* could be used in a zeroconf environment, so long as no > >user configuration were needed. One can imagine a DHCP server figuring > >out a lot of things on its own without being configured (and there has > >been talk on the list about this). > There was a lot of debate about this. As I recall, the concern is that > Zeroconf can't rely on there being a server. No server means no DHCP. So I see. :-) I'm OK leaving the text as is then. > > > 1.5 Routable Protocol Requirement > > > > > > If a protocol is intended to span multiple IP subnets it SHOULD > > > NOT use broadcasts or link-local addressing. > > > >define what link-local addressing is? i.e., self-configured addresses? > yes. See the link local draft... Ah, yes, that makes sense. > > > Requirement: > > > - Protocols intended to span multiple IP subnets SHOULD NOT use > > > broadcasts or link-local addressing. > > > >Why not? just stating something should or should not be done without > >context isn't always very convincing. > Link local addressing can't be routed per definitions in the other draft. My point was more on the "should not use broadcast". Per the definition of link-local addressing, it *can't* be used -- routers will drop the traffic, so this would seem to need to be stronger than a "SHOULD NOT". > > > 2.2.1 Web Browsing > > > > > > An URL typically contains the name of a Web server. When a user > > > enters an URL into a Web browser, the name must be translated to > > > an IP address before any actual Web browsing occurs. Web servers > > > often record log files of accesses, and wish to map the client's > > > IP address back to a human-readable name for recording in the log > > > file. Thus, a mechanism to translate the IP address to a name is > > > required. > > > > > > Requirement: > > > - MUST translate a name to an IP address. > > > - MUST translate an IP address to a name. > > > >This text curiously doesn't mention the DNS. But, for the web server, > >isn't the DNS reverse lookup specifically what is assumed/required? > Web servers as such are not dependent on DNS in any form. Implementations > of web servers often have such dependencies, but reverse lookups are NOT > required for proper operation of web servers. But the text in the document specifically says web servers do the reverse mapping, and that drives the requirement that a reverse mapping be doable. Existing web servers use the DNS for this. Are you saying that in a zeroconf environment, Web servers can and/or should use something other than DNS to do the reverse mapping? The point I'm trying to amke is that it seems misleading at best to suggest that a generic address to name mapping is needed, if what is actually needed is one that applications can use just as they do today with DNS. > >Seems like the reqirement is much more specific than just "translate > >name to address" and vice versa, and involves integration with the > >DNS. > Zeroconf is an environment without servers. How are you going to do a DNS > lookup without a server? The web server example above says they will need to do the reverse mapping. > > > 2.4 Service Discovery Scenarios > > > > > > Service discovery protocols allow users to select services and/or > > > hosts by a name that is discovered dynamically, rather than requiring > > > that the user know the name in advance and type it in correctly. > > > >Can't an application find and select services without the user being > >queried? E.g., isn't DNS a service? Should the user choose the DNS > >server? > If there's no server serving DNS, it'll be hard to use it. Yes. The text suggests that service discovery requires user choose from a menu of choices. Is that also true of services like the DNS? Does the above exclude services that are generic and where it doesn't matter who offers it? Thomas From owner-zeroconf@merit.edu Wed Jul 11 11:14:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06954 for ; Wed, 11 Jul 2001 11:14:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0AEF91239; Wed, 11 Jul 2001 09:30:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 576C391237; Wed, 11 Jul 2001 09:30:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F56591239 for ; Wed, 11 Jul 2001 09:30:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14C4A5DDB9; Wed, 11 Jul 2001 09:31:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id DA0005DD90 for ; Wed, 11 Jul 2001 09:31:34 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6BDSIB01703; Wed, 11 Jul 2001 09:28:18 -0400 Message-Id: <200107111328.f6BDSIB01703@hygro.adsl.duke.edu> To: Jim Busse Cc: Stuart Cheshire , zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt In-Reply-To: Message from Jim Busse of "Tue, 10 Jul 2001 18:26:51 PDT." Date: Wed, 11 Jul 2001 09:28:17 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Jim Busse writes: > > If the destination address is in the 169.254/16 prefix (including the > > 169.254.255.255 broadcast address), the host MUST use its link-local > > source address. > > > >too strong? > In my opinion, is no reason to change the wording to "should". I think the > concept that the169/254/16 prefix packets are coming from a "friendly" > link-local network, the use of some other address may look like an > "intruder". I like the original wording best. Maybe Thomas could give a > reason for the "too strong"? Stuart captured my concern precisely. Namely, if two nodes are on the same link, and one uses a global address rather than a link local (it might not even have a link-local address!), I don't think you want to outlaw communication when there would seem to be no harm. So, actually, I'm mostly OK with the above wording, since it basically says if you can use a link-local address, you MUST. What I worry is too strong, is saying you MUST drop packets if the src/dst addresses are not both link-local. To make it absolutely clear, perhaps the text "(if it has one)" could be added to the above text., i.e.: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MUST use its link-local source address (if it has one). Thomas From owner-zeroconf@merit.edu Wed Jul 11 11:29:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07745 for ; Wed, 11 Jul 2001 11:29:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96B7C9125A; Wed, 11 Jul 2001 11:11:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6893A9125B; Wed, 11 Jul 2001 11:11:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76C209125A for ; Wed, 11 Jul 2001 11:11:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 158085DDA9; Wed, 11 Jul 2001 11:13:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 8AC2E5DD93; Wed, 11 Jul 2001 11:13:03 -0400 (EDT) Received: from yarrow.senie.com (dialup-63.214.80.96.Dial1.Boston1.Level3.net [63.214.80.96]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6BFBkp01741 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 11 Jul 2001 11:11:49 -0400 Message-Id: <5.1.0.14.2.20010711110916.03d59b30@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 11:11:45 -0400 To: Spencer.Giacalone@predictive.com From: Daniel Senie Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 11:08 AM 7/11/01, Spencer.Giacalone@predictive.com wrote: >I noticed that the example uses a 1918 address. Do you only propose this >enhancement for hosts using 1918 on the same net as zero conf? Thomas had used that as an example, so I did too, but I don't see this as a case where the fact that the address is RFC1918 vs. publicly routable has any bearing. > >If a link-local device has only 169.254/16 in its admittedly small >routing > >table, won't it just look at the 10/8 address and decide there's no route > > >to that network? > >Sounds right to me, unless you mess with something else.. > >There's no default route, and no way for it to know that > >it should try to ARP for that 10/8 address. So, it still won't >communicate. > >Right. You'd need a router for this inter network communication, but... >Please refer to my next note. > > >We may like to dictate that Device B MUST implement link-local addresses, > >but the world doesn't work like that. If the vendor of Device B doesn't > >have the engineering resources to implement link-local addresses, then is > >it better for the user if the devices can talk safely, or not? > >This is starting to sound like the reasoning I used to propose gateway >discovery/NAT solutions for Zeroconf nets. At that time I presented the >idea that a "vendor of Device B doesn't have the engineering resources to >implement link-local addresses". As you no doubt remember, this logic was >rejected. > >To me, in addition to the fact that there are some relevant operational >issues (like ARP) this idea sounds either like A) a bad/confusing idea, or >B) a reason to re-open proposals for expanding zero conf functionality >(hint). Also, IMHO, this is adding fuel to the dynamic gateway discovery >argument. > >By the way, it's seems clear that hosts talking to both zero conf AND >normal IP on the same net has some security implications. Backdoor, >anyone? This was the core of the anti-NAT argument.. All good points. > >Alternatively (and I'm not in favor of this alternative), we could say >that > >a box which is running link-local-only should indeed treat 0/0 as link > >local, and ARP for any and all addresses. This would seem to be a very >bad > >idea. While it would allow a device in link-local-only mode to talk to a > >box with both link-local and another address to function, it would also > >allow a link-local-only box to talk to a box with only a configured > >address. This box with the configured address would not know to ARP for >the > >link-local address on the local wire, though, if it's only configured for > > >non-link-local. I think any change in this area would require touching >most > >hosts code to ensure compatability. > >Other ideas that dont sound too good- Router based proxy ARP? That'll open >up some issues. How about secondary IP addresses support on a host basis, >so host know what specific, but seperate ranges to ARP for? > >Or, perhaps, we could just use NAT and a gateway discovery protocol to >zero conf hosts talk to ""vendor of Device B doesn't have the engineering >resources to implement link-local addresses", and keep zero conf host on >their on little networks :-) Ick. Let's see if we can find a way to stay far from this territory... > >:-) Spence > > > > > > > >Daniel Senie >Sent by: owner-zeroconf@merit.edu >07/11/01 09:34 AM > > > To: Stuart Cheshire , "Jim Busse" > , >"Thomas Narten" , > cc: > Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt > > >At 03:31 AM 7/11/01, Stuart Cheshire wrote: > > >In my opinion, is no reason to change the wording to "should". I think >the > > >concept that the169/254/16 prefix packets are coming from a "friendly" > > >link-local network, the use of some other address may look like an > > >"intruder". I like the original wording best. Maybe Thomas could give >a > > >reason for the "too strong"? > > > >I think the reasoning is this: > > > >Say you have two devices on the same physical Ethernet. Device A > >implements link-local addresses, and has assigned itself one. Device B > >does not implement link-local addresses, but has a manually configured > >address of 10.0.0.1. > > > >These devices are on the same physical Ethernet. Is it useful for the > >link-local draft to prohibit them from talking to each other? > >If a link-local device has only 169.254/16 in its admittedly small routing > >table, won't it just look at the 10/8 address and decide there's no route >to that network? There's no default route, and no way for it to know that >it should try to ARP for that 10/8 address. So, it still won't >communicate. > > >We may like to dictate that Device B MUST implement link-local addresses, > >but the world doesn't work like that. If the vendor of Device B doesn't > >have the engineering resources to implement link-local addresses, then is > >it better for the user if the devices can talk safely, or not? > >My point here is that if the other device tries to answer with the >non-link-local address, a box working in link-local-only mode may have no >way to respond. If boxes are going to use multiple addresses, then we have > >to handle communicating with boxes which don't know how to reach any >addresses other than link-local. > >Alternatively (and I'm not in favor of this alternative), we could say >that >a box which is running link-local-only should indeed treat 0/0 as link >local, and ARP for any and all addresses. This would seem to be a very bad > >idea. While it would allow a device in link-local-only mode to talk to a >box with both link-local and another address to function, it would also >allow a link-local-only box to talk to a box with only a configured >address. This box with the configured address would not know to ARP for >the >link-local address on the local wire, though, if it's only configured for >non-link-local. I think any change in this area would require touching >most >hosts code to ensure compatability. > >----------------------------------------------------------------- >Daniel Senie dts@senie.com >Amaranth Networks Inc. http://www.amaranth.com ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 11:29:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07756 for ; Wed, 11 Jul 2001 11:29:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF9D091240; Wed, 11 Jul 2001 11:05:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 957FF9123F; Wed, 11 Jul 2001 11:05:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3929791259 for ; Wed, 11 Jul 2001 11:05:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB4B95DDB1; Wed, 11 Jul 2001 11:07:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from athena.predictive.com (athena.predictive.com [208.209.197.197]) by segue.merit.edu (Postfix) with ESMTP id 6281D5DD93; Wed, 11 Jul 2001 11:07:08 -0400 (EDT) To: Daniel Senie Cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: Spencer.Giacalone@predictive.com Message-ID: Date: Wed, 11 Jul 2001 11:08:34 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.07a |May 14, 2001) at 07/11/2001 11:08:42 AM, Serialize complete at 07/11/2001 11:08:42 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk I noticed that the example uses a 1918 address. Do you only propose this enhancement for hosts using 1918 on the same net as zero conf? >If a link-local device has only 169.254/16 in its admittedly small routing >table, won't it just look at the 10/8 address and decide there's no route >to that network? Sounds right to me, unless you mess with something else.. >There's no default route, and no way for it to know that >it should try to ARP for that 10/8 address. So, it still won't communicate. Right. You'd need a router for this inter network communication, but... Please refer to my next note. >We may like to dictate that Device B MUST implement link-local addresses, >but the world doesn't work like that. If the vendor of Device B doesn't >have the engineering resources to implement link-local addresses, then is >it better for the user if the devices can talk safely, or not? This is starting to sound like the reasoning I used to propose gateway discovery/NAT solutions for Zeroconf nets. At that time I presented the idea that a "vendor of Device B doesn't have the engineering resources to implement link-local addresses". As you no doubt remember, this logic was rejected. To me, in addition to the fact that there are some relevant operational issues (like ARP) this idea sounds either like A) a bad/confusing idea, or B) a reason to re-open proposals for expanding zero conf functionality (hint). Also, IMHO, this is adding fuel to the dynamic gateway discovery argument. By the way, it's seems clear that hosts talking to both zero conf AND normal IP on the same net has some security implications. Backdoor, anyone? This was the core of the anti-NAT argument.. >Alternatively (and I'm not in favor of this alternative), we could say that >a box which is running link-local-only should indeed treat 0/0 as link >local, and ARP for any and all addresses. This would seem to be a very bad >idea. While it would allow a device in link-local-only mode to talk to a >box with both link-local and another address to function, it would also >allow a link-local-only box to talk to a box with only a configured >address. This box with the configured address would not know to ARP for the >link-local address on the local wire, though, if it's only configured for >non-link-local. I think any change in this area would require touching most >hosts code to ensure compatability. Other ideas that dont sound too good- Router based proxy ARP? That'll open up some issues. How about secondary IP addresses support on a host basis, so host know what specific, but seperate ranges to ARP for? Or, perhaps, we could just use NAT and a gateway discovery protocol to zero conf hosts talk to ""vendor of Device B doesn't have the engineering resources to implement link-local addresses", and keep zero conf host on their on little networks :-) :-) Spence Daniel Senie Sent by: owner-zeroconf@merit.edu 07/11/01 09:34 AM To: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , cc: Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt At 03:31 AM 7/11/01, Stuart Cheshire wrote: > >In my opinion, is no reason to change the wording to "should". I think the > >concept that the169/254/16 prefix packets are coming from a "friendly" > >link-local network, the use of some other address may look like an > >"intruder". I like the original wording best. Maybe Thomas could give a > >reason for the "too strong"? > >I think the reasoning is this: > >Say you have two devices on the same physical Ethernet. Device A >implements link-local addresses, and has assigned itself one. Device B >does not implement link-local addresses, but has a manually configured >address of 10.0.0.1. > >These devices are on the same physical Ethernet. Is it useful for the >link-local draft to prohibit them from talking to each other? If a link-local device has only 169.254/16 in its admittedly small routing table, won't it just look at the 10/8 address and decide there's no route to that network? There's no default route, and no way for it to know that it should try to ARP for that 10/8 address. So, it still won't communicate. >We may like to dictate that Device B MUST implement link-local addresses, >but the world doesn't work like that. If the vendor of Device B doesn't >have the engineering resources to implement link-local addresses, then is >it better for the user if the devices can talk safely, or not? My point here is that if the other device tries to answer with the non-link-local address, a box working in link-local-only mode may have no way to respond. If boxes are going to use multiple addresses, then we have to handle communicating with boxes which don't know how to reach any addresses other than link-local. Alternatively (and I'm not in favor of this alternative), we could say that a box which is running link-local-only should indeed treat 0/0 as link local, and ARP for any and all addresses. This would seem to be a very bad idea. While it would allow a device in link-local-only mode to talk to a box with both link-local and another address to function, it would also allow a link-local-only box to talk to a box with only a configured address. This box with the configured address would not know to ARP for the link-local address on the local wire, though, if it's only configured for non-link-local. I think any change in this area would require touching most hosts code to ensure compatability. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 12:10:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09418 for ; Wed, 11 Jul 2001 12:10:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84F899125E; Wed, 11 Jul 2001 12:11:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50B5E9125F; Wed, 11 Jul 2001 12:11:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4896F9125E for ; Wed, 11 Jul 2001 12:11:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 051EC5DDB9; Wed, 11 Jul 2001 12:12:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from athena.predictive.com (athena.predictive.com [208.209.197.197]) by segue.merit.edu (Postfix) with ESMTP id ACCF65DD93; Wed, 11 Jul 2001 12:12:32 -0400 (EDT) To: Daniel Senie Cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: Spencer.Giacalone@predictive.com Message-ID: Date: Wed, 11 Jul 2001 12:14:04 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.07a |May 14, 2001) at 07/11/2001 12:14:06 PM, Serialize complete at 07/11/2001 12:14:06 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk >Thomas had used that as an example, so I did too, but I don't see this as a >case where the fact that the address is RFC1918 vs. publicly routable has >any bearing. In the case of using dual zero+normal IP hosts as backdoors, it might. Spencer Giacalone, Predictive Systems --------------------------------------------------------------- "What is real? How do you define real?" -Morpheus Daniel Senie 07/11/01 11:11 AM To: Spencer.Giacalone@predictive.com cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt At 11:08 AM 7/11/01, Spencer.Giacalone@predictive.com wrote: >I noticed that the example uses a 1918 address. Do you only propose this >enhancement for hosts using 1918 on the same net as zero conf? Thomas had used that as an example, so I did too, but I don't see this as a case where the fact that the address is RFC1918 vs. publicly routable has any bearing. > >If a link-local device has only 169.254/16 in its admittedly small >routing > >table, won't it just look at the 10/8 address and decide there's no route > > >to that network? > >Sounds right to me, unless you mess with something else.. > >There's no default route, and no way for it to know that > >it should try to ARP for that 10/8 address. So, it still won't >communicate. > >Right. You'd need a router for this inter network communication, but... >Please refer to my next note. > > >We may like to dictate that Device B MUST implement link-local addresses, > >but the world doesn't work like that. If the vendor of Device B doesn't > >have the engineering resources to implement link-local addresses, then is > >it better for the user if the devices can talk safely, or not? > >This is starting to sound like the reasoning I used to propose gateway >discovery/NAT solutions for Zeroconf nets. At that time I presented the >idea that a "vendor of Device B doesn't have the engineering resources to >implement link-local addresses". As you no doubt remember, this logic was >rejected. > >To me, in addition to the fact that there are some relevant operational >issues (like ARP) this idea sounds either like A) a bad/confusing idea, or >B) a reason to re-open proposals for expanding zero conf functionality >(hint). Also, IMHO, this is adding fuel to the dynamic gateway discovery >argument. > >By the way, it's seems clear that hosts talking to both zero conf AND >normal IP on the same net has some security implications. Backdoor, >anyone? This was the core of the anti-NAT argument.. All good points. > >Alternatively (and I'm not in favor of this alternative), we could say >that > >a box which is running link-local-only should indeed treat 0/0 as link > >local, and ARP for any and all addresses. This would seem to be a very >bad > >idea. While it would allow a device in link-local-only mode to talk to a > >box with both link-local and another address to function, it would also > >allow a link-local-only box to talk to a box with only a configured > >address. This box with the configured address would not know to ARP for >the > >link-local address on the local wire, though, if it's only configured for > > >non-link-local. I think any change in this area would require touching >most > >hosts code to ensure compatability. > >Other ideas that dont sound too good- Router based proxy ARP? That'll open >up some issues. How about secondary IP addresses support on a host basis, >so host know what specific, but seperate ranges to ARP for? > >Or, perhaps, we could just use NAT and a gateway discovery protocol to >zero conf hosts talk to ""vendor of Device B doesn't have the engineering >resources to implement link-local addresses", and keep zero conf host on >their on little networks :-) Ick. Let's see if we can find a way to stay far from this territory... > >:-) Spence > > > > > > > >Daniel Senie >Sent by: owner-zeroconf@merit.edu >07/11/01 09:34 AM > > > To: Stuart Cheshire , "Jim Busse" > , >"Thomas Narten" , > cc: > Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt > > >At 03:31 AM 7/11/01, Stuart Cheshire wrote: > > >In my opinion, is no reason to change the wording to "should". I think >the > > >concept that the169/254/16 prefix packets are coming from a "friendly" > > >link-local network, the use of some other address may look like an > > >"intruder". I like the original wording best. Maybe Thomas could give >a > > >reason for the "too strong"? > > > >I think the reasoning is this: > > > >Say you have two devices on the same physical Ethernet. Device A > >implements link-local addresses, and has assigned itself one. Device B > >does not implement link-local addresses, but has a manually configured > >address of 10.0.0.1. > > > >These devices are on the same physical Ethernet. Is it useful for the > >link-local draft to prohibit them from talking to each other? > >If a link-local device has only 169.254/16 in its admittedly small routing > >table, won't it just look at the 10/8 address and decide there's no route >to that network? There's no default route, and no way for it to know that >it should try to ARP for that 10/8 address. So, it still won't >communicate. > > >We may like to dictate that Device B MUST implement link-local addresses, > >but the world doesn't work like that. If the vendor of Device B doesn't > >have the engineering resources to implement link-local addresses, then is > >it better for the user if the devices can talk safely, or not? > >My point here is that if the other device tries to answer with the >non-link-local address, a box working in link-local-only mode may have no >way to respond. If boxes are going to use multiple addresses, then we have > >to handle communicating with boxes which don't know how to reach any >addresses other than link-local. > >Alternatively (and I'm not in favor of this alternative), we could say >that >a box which is running link-local-only should indeed treat 0/0 as link >local, and ARP for any and all addresses. This would seem to be a very bad > >idea. While it would allow a device in link-local-only mode to talk to a >box with both link-local and another address to function, it would also >allow a link-local-only box to talk to a box with only a configured >address. This box with the configured address would not know to ARP for >the >link-local address on the local wire, though, if it's only configured for >non-link-local. I think any change in this area would require touching >most >hosts code to ensure compatability. > >----------------------------------------------------------------- >Daniel Senie dts@senie.com >Amaranth Networks Inc. http://www.amaranth.com ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 13:29:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12558 for ; Wed, 11 Jul 2001 13:29:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B66AE9125F; Wed, 11 Jul 2001 12:19:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862FA91260; Wed, 11 Jul 2001 12:19:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 987CD9125F for ; Wed, 11 Jul 2001 12:19:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 560945DDB1; Wed, 11 Jul 2001 12:20:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id F08E85DD93; Wed, 11 Jul 2001 12:20:58 -0400 (EDT) Received: from yarrow.senie.com (dialup-63.214.80.96.Dial1.Boston1.Level3.net [63.214.80.96]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6BGJfp07673 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 11 Jul 2001 12:19:44 -0400 Message-Id: <5.1.0.14.2.20010711121708.00a681e0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 12:19:40 -0400 To: Spencer.Giacalone@predictive.com From: Daniel Senie Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:14 PM 7/11/01, Spencer.Giacalone@predictive.com wrote: > >Thomas had used that as an example, so I did too, but I don't see this as >a > >case where the fact that the address is RFC1918 vs. publicly routable has > > >any bearing. > >In the case of using dual zero+normal IP hosts as backdoors, it might. The issue of backdoors with dual addressing applies regardless. Even with RFC1918 addresses, it can apply. Firewall boxes often include a feature to forward specific ports to specific addresses on the private network, which are usually in RFC 1918 space. As such, looking at whether an address is RFC 1918 or not is insufficient to determine whether the other host is to be trusted or not. We may be getting back to an argument that dual addressing is more trouble than it's worth, but we have to deal with the same issue in IPv6 deployments, so we might as well figure out how to deal with it in all cases. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 13:29:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12554 for ; Wed, 11 Jul 2001 13:29:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CE9691259; Wed, 11 Jul 2001 11:07:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 161BC9125A; Wed, 11 Jul 2001 11:07:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59B6C91259 for ; Wed, 11 Jul 2001 11:07:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEA6C5DDA9; Wed, 11 Jul 2001 11:09:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id A3A5C5DD93 for ; Wed, 11 Jul 2001 11:09:10 -0400 (EDT) Received: from yarrow.senie.com (dialup-63.214.80.96.Dial1.Boston1.Level3.net [63.214.80.96]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6BF7sp01357 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 11 Jul 2001 11:07:57 -0400 Message-Id: <5.1.0.14.2.20010711101731.03dff440@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 10:27:44 -0400 To: Thomas Narten From: Daniel Senie Subject: Re: draft-ietf-zeroconf-reqts-08.txt Cc: zeroconf@merit.edu In-Reply-To: <200107111327.f6BDRqi01681@hygro.adsl.duke.edu> References: <5.1.0.14.2.20010709150627.03df2430@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:27 AM 7/11/01, Thomas Narten wrote: >Daniel Senie writes: > > > At 02:04 PM 7/9/01, Thomas Narten wrote: > > > Link local addressing can't be routed per definitions in the other draft. > >My point was more on the "should not use broadcast". Per the >definition of link-local addressing, it *can't* be used -- routers >will drop the traffic, so this would seem to need to be stronger than >a "SHOULD NOT". > > > > > 2.2.1 Web Browsing > > > > > > > > An URL typically contains the name of a Web server. When a user > > > > enters an URL into a Web browser, the name must be translated to > > > > an IP address before any actual Web browsing occurs. Web servers > > > > often record log files of accesses, and wish to map the client's > > > > IP address back to a human-readable name for recording in the log > > > > file. Thus, a mechanism to translate the IP address to a name is > > > > required. > > > > > > > > Requirement: > > > > - MUST translate a name to an IP address. > > > > - MUST translate an IP address to a name. > > > > > >This text curiously doesn't mention the DNS. But, for the web server, > > >isn't the DNS reverse lookup specifically what is assumed/required? > > > Web servers as such are not dependent on DNS in any form. Implementations > > of web servers often have such dependencies, but reverse lookups are NOT > > required for proper operation of web servers. > >But the text in the document specifically says web servers do the reverse >mapping, and that drives the requirement that a reverse mapping be >doable. Existing web servers use the DNS for this. Are you saying that >in a zeroconf environment, Web servers can and/or should use something >other than DNS to do the reverse mapping? I think pointing to web servers in this case is a bad idea, as it's a bad example. The example is based on common practice, not operational necessity. Many embedded devices have web servers within them which have no reliance on DNS. It's exactly this sort of embedded device (or "appliance" as some call them) which is likely to occur on a link-local network (e.g. for controlling devices in a house). >The point I'm trying to amke is that it seems misleading at best to >suggest that a generic address to name mapping is needed, if what is >actually needed is one that applications can use just as they do today >with DNS. > > > >Seems like the reqirement is much more specific than just "translate > > >name to address" and vice versa, and involves integration with the > > >DNS. > > > Zeroconf is an environment without servers. How are you going to do a DNS > > lookup without a server? > >The web server example above says they will need to do the reverse >mapping. > > > > > 2.4 Service Discovery Scenarios > > > > > > > > Service discovery protocols allow users to select services and/or > > > > hosts by a name that is discovered dynamically, rather than > requiring > > > > that the user know the name in advance and type it in correctly. > > > > > >Can't an application find and select services without the user being > > >queried? E.g., isn't DNS a service? Should the user choose the DNS > > >server? > > > If there's no server serving DNS, it'll be hard to use it. > >Yes. The text suggests that service discovery requires user choose >from a menu of choices. Is that also true of services like the DNS? >Does the above exclude services that are generic and where it doesn't >matter who offers it? I'll let others comment on this. From other messages, it sounds like others have better answers on this subject than I do. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 13:40:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13013 for ; Wed, 11 Jul 2001 13:40:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 517E691263; Wed, 11 Jul 2001 13:41:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2351691262; Wed, 11 Jul 2001 13:41:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62C8E91263 for ; Wed, 11 Jul 2001 13:41:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32F185DDB6; Wed, 11 Jul 2001 13:42:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by segue.merit.edu (Postfix) with ESMTP id 9A79F5DD93 for ; Wed, 11 Jul 2001 13:42:31 -0400 (EDT) Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id f6BHebr15623; Wed, 11 Jul 2001 10:40:37 -0700 (PDT) Received: from galatica.pc.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id KAA08895; Wed, 11 Jul 2001 10:40:43 -0700 (PDT) Received: by GALATICA with Internet Mail Service (5.5.2448.0) id ; Wed, 11 Jul 2001 10:20:14 -0700 Message-ID: From: Jim Busse To: Erik Guttman Cc: Daniel Senie , zeroconf@merit.edu, Thomas Narten Subject: RE: draft-ietf-zeroconf-reqts-08.txt Date: Wed, 11 Jul 2001 10:20:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik: Wordsmithing: Should the text read "Service discovery protocols MUST allow users or software to discover instances" ?? Jim Busse -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] Sent: Wednesday, July 11, 2001 8:12 AM To: Thomas Narten Cc: Daniel Senie; zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-reqts-08.txt > > > > 2.2.1 Web Browsing > > > > Requirement: > > > > - MUST translate a name to an IP address. > > > > - MUST translate an IP address to a name. > > > > > >This text curiously doesn't mention the DNS. But, for the web server, > > >isn't the DNS reverse lookup specifically what is assumed/required? > > > Web servers as such are not dependent on DNS in any form. Implementations > > of web servers often have such dependencies, but reverse lookups are NOT > > required for proper operation of web servers. > > But the text in the document specifically says web servers do the reverse > mapping, and that drives the requirement that a reverse mapping be > doable. Existing web servers use the DNS for this. Are you saying that > in a zeroconf environment, Web servers can and/or should use something > other than DNS to do the reverse mapping? > > The point I'm trying to amke is that it seems misleading at best to > suggest that a generic address to name mapping is needed, if what is > actually needed is one that applications can use just as they do today > with DNS. Yes. What we want to say is that the upper layer support apps relying on RFC 1123 DNS interfaces will continue to be supported. We do not have to, nor should we, say in the reqts doc how this support is achieved. > > >Seems like the reqirement is much more specific than just "translate > > >name to address" and vice versa, and involves integration with the > > >DNS. > > > Zeroconf is an environment without servers. How are you going to do a DNS > > lookup without a server? > > The web server example above says they will need to do the reverse > mapping. The web server example is motivate and support the listed reqts for forward and reverse lookup. What we should really do, perhaps, is require support for RFC 1123, section 6.1. > > > > 2.4 Service Discovery Scenarios > > > > > > > > Service discovery protocols allow users to select services and/or > > > > hosts by a name that is discovered dynamically, rather than requiring > > > > that the user know the name in advance and type it in correctly. > > > > > >Can't an application find and select services without the user being > > >queried? E.g., isn't DNS a service? Should the user choose the DNS > > >server? > > > If there's no server serving DNS, it'll be hard to use it. > > Yes. The text suggests that service discovery requires user choose > from a menu of choices. Is that also true of services like the DNS? > Does the above exclude services that are generic and where it doesn't > matter who offers it? What we really want to say is that services can be discovered and selected, by users or by a computer program. That way the location of the server does not need to be known in advance for client-server software to function. We will quickly get into a rathole about DNS here. One can use mDNS to resolve DNS names when there is no DNS server. You can query DNS SRV RRs to request service instances by type. That type is a name. So, the essential thing is not that one doesn't know the name of the service in advance, but rather, one doesn't know the particular server instance yet. One uses a service discovery protocol to obtain these concrete service locations. In summary, I suggest that this text be changed to: 2.4 Service Discovery Scenarios Service discovery protocols allow users or software to discover instances and select among available services. This removes the requirement that the user or client software know a server's location in advance and in order for the client to communicate with the server. Erik From owner-zeroconf@merit.edu Wed Jul 11 14:18:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14415 for ; Wed, 11 Jul 2001 14:18:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F19D91241; Wed, 11 Jul 2001 14:18:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EFCB91242; Wed, 11 Jul 2001 14:18:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3704991241 for ; Wed, 11 Jul 2001 14:18:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 166C05DDBA; Wed, 11 Jul 2001 14:19:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from athena.predictive.com (athena.predictive.com [208.209.197.197]) by segue.merit.edu (Postfix) with ESMTP id CFA4C5DDB6; Wed, 11 Jul 2001 14:19:48 -0400 (EDT) To: Daniel Senie Cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: Spencer.Giacalone@predictive.com Message-ID: Date: Wed, 11 Jul 2001 14:21:20 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.07a |May 14, 2001) at 07/11/2001 02:21:22 PM, Serialize complete at 07/11/2001 02:21:22 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk >We may be getting back to an argument that dual addressing is more trouble >than it's worth, but we have to deal with the same issue in IPv6 >deployments, so we might as well figure out how to deal with it in all cases. Agreed- My point before was that these issues, to me, seem similar to the concerns which where rasied with the gateway/NAT draft. If my perspective is correct (which it may very well not be), it would seem logical that this proposal would be DOA. Spencer Giacalone, Predictive Systems --------------------------------------------------------------- "What is real? How do you define real?" -Morpheus Daniel Senie 07/11/01 12:19 PM To: Spencer.Giacalone@predictive.com cc: Stuart Cheshire , "Jim Busse" , "Thomas Narten" , owner-zeroconf@merit.edu, zeroconf@merit.edu Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt At 12:14 PM 7/11/01, Spencer.Giacalone@predictive.com wrote: > >Thomas had used that as an example, so I did too, but I don't see this as >a > >case where the fact that the address is RFC1918 vs. publicly routable has > > >any bearing. > >In the case of using dual zero+normal IP hosts as backdoors, it might. The issue of backdoors with dual addressing applies regardless. Even with RFC1918 addresses, it can apply. Firewall boxes often include a feature to forward specific ports to specific addresses on the private network, which are usually in RFC 1918 space. As such, looking at whether an address is RFC 1918 or not is insufficient to determine whether the other host is to be trusted or not. We may be getting back to an argument that dual addressing is more trouble than it's worth, but we have to deal with the same issue in IPv6 deployments, so we might as well figure out how to deal with it in all cases. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 15:29:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17143 for ; Wed, 11 Jul 2001 15:29:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79DD791242; Wed, 11 Jul 2001 15:29:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49A9B91243; Wed, 11 Jul 2001 15:29:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DB9591242 for ; Wed, 11 Jul 2001 15:29:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 558C45DDB9; Wed, 11 Jul 2001 15:30:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by segue.merit.edu (Postfix) with ESMTP id B9C605DD93 for ; Wed, 11 Jul 2001 15:30:52 -0400 (EDT) Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id f6BJT5r19974; Wed, 11 Jul 2001 12:29:05 -0700 (PDT) Received: from galatica.pc.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id MAA19678; Wed, 11 Jul 2001 12:29:09 -0700 (PDT) Received: by GALATICA with Internet Mail Service (5.5.2448.0) id ; Wed, 11 Jul 2001 12:08:40 -0700 Message-ID: From: Jim Busse To: Jim Busse , Stuart Cheshire Cc: zeroconf@merit.edu, Thomas Narten Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Wed, 11 Jul 2001 12:08:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Sturart and Thomas: Thanks for the clarification. I had thought about this several months ago, so let me explain my conclusions from that thinking. Device A could join Device B's network. In that case, the Device B could have the manually configured address 10.0.0.1, which would mean that Device B's network configuration is out of scope for Zero Configuration. (After re-re-reading the requirements doc, I can find no requirement for a Zeroconf device to join a manually configured network installation). Device B's network may still be Zeroconf, but I think that means that somehow a 10. configured DHCP server must have been available during the boot of all the other devices on this network, and/or every device on Device B's subnet is similarly manually configured. (Still open is the case where this DHCP server has died, after all the connections have been established, then we're into a timing thing). A work-around for Device A to be able to join Device B's network is provided in sect. 2.3.1, where an app could listen to traffic and make some scope choices available to the user of Device A Device B could join Device A's network. I would argue that in this case, Device B has to release it's IP address. This is as has been pointed out, not the way the world works, but the world hasn't been very friendly at providing easily configured networks, either. My argument is that since Device B has a manually configured address, it too is out-of-scope for Zeroconf. I don't have a work-around for this. I think to bring this DeviceA/DeviceB interoperation into scope would require a change in the requirements document to indicate any manually-configured device should (must?) be able to join a Zeroconf network. I think this isn't realistic. Thanks for listening. I still like the original wording Jim Busse -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Wednesday, July 11, 2001 6:28 AM To: Jim Busse Cc: Stuart Cheshire; zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt Jim Busse writes: > > If the destination address is in the 169.254/16 prefix (including the > > 169.254.255.255 broadcast address), the host MUST use its link-local > > source address. > > > >too strong? > In my opinion, is no reason to change the wording to "should". I think the > concept that the169/254/16 prefix packets are coming from a "friendly" > link-local network, the use of some other address may look like an > "intruder". I like the original wording best. Maybe Thomas could give a > reason for the "too strong"? Stuart captured my concern precisely. Namely, if two nodes are on the same link, and one uses a global address rather than a link local (it might not even have a link-local address!), I don't think you want to outlaw communication when there would seem to be no harm. So, actually, I'm mostly OK with the above wording, since it basically says if you can use a link-local address, you MUST. What I worry is too strong, is saying you MUST drop packets if the src/dst addresses are not both link-local. To make it absolutely clear, perhaps the text "(if it has one)" could be added to the above text., i.e.: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MUST use its link-local source address (if it has one). Thomas From owner-zeroconf@merit.edu Wed Jul 11 18:15:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22523 for ; Wed, 11 Jul 2001 18:15:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E02B91243; Wed, 11 Jul 2001 18:15:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DC4191244; Wed, 11 Jul 2001 18:15:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C42C91243 for ; Wed, 11 Jul 2001 18:15:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3C995DDD0; Wed, 11 Jul 2001 18:17:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 62EDC5DDB1 for ; Wed, 11 Jul 2001 18:17:25 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA05142 for ; Wed, 11 Jul 2001 15:16:20 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 11 Jul 2001 15:16:19 -0700 Received: from [206.111.147.149] (vpn-gh-1045.apple.com [17.254.140.20]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f6BMGIw29033 for ; Wed, 11 Jul 2001 15:16:18 -0700 (PDT) Message-Id: <200107112216.f6BMGIw29033@scv2.apple.com> Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Wed, 11 Jul 2001 15:16:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Doesn't the latter rule mean that devices that implement this >specification WILL NOT interoperate with existing devices that use >link-local addresses? I.e, for the stacks that already support >link-local addresses, do they always set the TTL to 255? I can attest that Mac OS certainly sets TTL=255 for all outgoing unicast packets. >What about the case where a node uses a link-local address, shuts >down, and then restarts. Per the document, it should try to use the >same address. Other devices could still be trying to communicate with >the device using its previous (and soon-to-be current) address. Good observation. If no one makes strong arguments to the contrary, I will change "any ARP packet" to "any ARP probe" as you suggested. >This would be better, but might still be a bit aggressive. In a large >environment with a bridged network, the traffic could be a problem. We >want this to follow the "do no harm" rule if a device gets plugged in >somewhere where the zeroconf stuff gets invoked, even though maybe it >shouldn't. I'm not sure what the right number should be. I think we're getting into slightly obscure cases here. We're talking about a large bridged network, with a DOS attack going on, and the administrators doing nothing to fix it, and one packet a minute from each machine being "too much traffic". >I agree the defend once handles the case of a newly booting >device. But what about a bridge network being connected together? Exactly the same, in the common case where one of our hosts in question broadcasts an ARP request in preparation for initiating some outgoing communication: 1. Host A sends an ARP 2. Host B sees A's ARP, B has no open connections, B politely defers. - OR - 1. Host A sends an ARP 2. Host B sees A's ARP, B has active connections on this address, so Host B defends once ("Hey, get lost, that's my address.") 3. Host A sees B's ARP, A has no open connections, A politely defers. - OR - 1. Host A sends an ARP 2. Host B sees A's ARP, B has active connections on this address, so Host B defends once ("Hey, get lost, that's my address.") 3. Host A sees B's ARP, A has active connections on this address, so Host A defends once ("You get lost, I'm using this address.") 4. Host B can't defend twice, so B politely defers. Finally, remember that these collisions are *rare* events. We're putting a lot of brain cycles into worrying about tuning something that almost never happens. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Jul 11 18:27:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22889 for ; Wed, 11 Jul 2001 18:27:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3869D91262; Wed, 11 Jul 2001 18:27:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 083DF91264; Wed, 11 Jul 2001 18:27:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CC0D91262 for ; Wed, 11 Jul 2001 18:27:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 693665DDDE; Wed, 11 Jul 2001 18:29:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 18AF75DDD0 for ; Wed, 11 Jul 2001 18:29:24 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA07361 for ; Wed, 11 Jul 2001 15:28:19 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 11 Jul 2001 15:26:33 +0100 Received: from [206.111.147.149] (vpn-gh-1045.apple.com [17.254.140.20]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id PAA13234 for ; Wed, 11 Jul 2001 15:28:18 -0700 (PDT) Message-Id: <200107112228.PAA13234@scv1.apple.com> Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Wed, 11 Jul 2001 15:28:14 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Device B could join Device A's network. I would argue that in this case, >Device B has to release it's IP address. This is as has been pointed out, >not the way the world works, but the world hasn't been very friendly at >providing easily configured networks, either. My argument is that since >Device B has a manually configured address, it too is out-of-scope for >Zeroconf. I don't have a work-around for this. This does in fact work today, and Apple uses it to allow configuration of AirPort base stations. If the Mac has an LL address, and the AirPort base station has some incorrect manually configured static address that some user typed in by mistake, then they can still communicate with each other, which lets the user reconfigure the base station back to a sensible configuration. This is extremely useful. The AirPort base station has no screen or keyboard, or serial port to connect a terminal. Without some kind of reliable always-working IP, a user might easily get it into a state where it is very hard to communicate with it to fix it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Jul 11 18:44:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23412 for ; Wed, 11 Jul 2001 18:44:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9914B91244; Wed, 11 Jul 2001 18:24:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66E2591262; Wed, 11 Jul 2001 18:24:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 895D191244 for ; Wed, 11 Jul 2001 18:24:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C4FD25DDD0; Wed, 11 Jul 2001 18:26:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 75EA55DDB1 for ; Wed, 11 Jul 2001 18:26:23 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA06652 for ; Wed, 11 Jul 2001 15:25:18 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 11 Jul 2001 15:25:18 -0700 Received: from [206.111.147.149] (vpn-gh-1045.apple.com [17.254.140.20]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f6BMPIw01514 for ; Wed, 11 Jul 2001 15:25:18 -0700 (PDT) Message-Id: <200107112225.f6BMPIw01514@scv2.apple.com> Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Wed, 11 Jul 2001 15:25:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >If a link-local device has only 169.254/16 in its admittedly >small routing table, won't it just look at the 10/8 address and >decide there's no route to that network? There's no default >route, and no way for it to know that it should try to ARP for >that 10/8 address. So, it still won't communicate. Or, hosts with only an LL address could run in "ARP for everything" mode. In fact, this is exactly what shipping Mac OS systems do today. >This box with the configured address would not know to ARP for >the link-local address on the local wire, though, if it's only >configured for non-link-local. I think any change in this area >would require touching most hosts code to ensure compatability. So you're saying that it might not work with some of today's hosts. Is that a reason to outlaw it from *ever* working? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Jul 11 19:30:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24683 for ; Wed, 11 Jul 2001 19:30:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EFC0B91264; Wed, 11 Jul 2001 19:30:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A731491265; Wed, 11 Jul 2001 19:30:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A730991264 for ; Wed, 11 Jul 2001 19:30:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3DC35DDFA; Wed, 11 Jul 2001 19:31:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 954C25DDB9 for ; Wed, 11 Jul 2001 19:31:52 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA17276 for ; Wed, 11 Jul 2001 16:30:48 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA27218 for ; Wed, 11 Jul 2001 16:30:46 -0700 (MST)] Received: from email.mot.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6BNUeU24878; Thu, 12 Jul 2001 09:30:41 +1000 (EST) Message-ID: <3B4CE1A0.EB415A6C@email.mot.com> Date: Thu, 12 Jul 2001 09:30:40 +1000 From: Aidan Williams Reply-To: Aidan.Williams@motorola.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-reqts-08.txt References: <200107091804.OAA25669@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > A zeroconf protocol is able to operate correctly in the absence > > of configured information from either a user or infrastructure > > services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, > > RFC 1035] servers. Zeroconf protocols may use configured > > information, when it is available, but do not rely on it being > > present. One possible exception is the use of MAC addresses > > (i.e. layer two addresses) as parameters in zeroconf protocols. > > I do not consider a MAC address to be configured information. It is > built-in as far as the end user is concerned. > > This may be a minor nit, but it may be worth pointing out that DHCP > *protocols* could be used in a zeroconf environment, so long as no > user configuration were needed. One can imagine a DHCP server figuring > out a lot of things on its own without being configured (and there has > been talk on the list about this). > Personally, I prefer the notion of "zeroconf protocols", rather than protocols being "zeroconf to the user". A zeroconf protocol being something that devices can engage in *without* the presence of some other box or service on the network to assist it. The "pre-configured" DHCP server along the lines of the mini-dhcp is quite a common approach which to my mind does *not* fit the bill of a "zeroconf protocol", but is "zeroconf to the user". This is because without the server, going through the motions of the protocol don't get you anywhere. I can imagine the co-existence of DHCP with IPv4LL: a DHCP server on the same network segment could fake up "leases" for addresses which are discovered to be in use via the receipt of ARP messages and dish out addresses via DHCP to devices which do not support IPv4LL. (Section 1.4 of the IPv4LL document frowns on this, and I am tempted to agree). I can also imagine co-existince of mDNS and "configured" DNS where proxying could happen from mDNS to DNS and vice versa. There could also be a link to dynamic DNS, and possibly DHCP if the device wanted to suggest a name for itself. Similar things could probably be said about SLP and ZMAAP. It is the nature of these protocols (that they are distributed, and reasonably stateless) that allows them to interoperate with non-zeroconf protocols. I think this is a distinction worth keeping. > > 1.5 Routable Protocol Requirement > > > > If a protocol is intended to span multiple IP subnets it SHOULD > > NOT use broadcasts or link-local addressing. > > define what link-local addressing is? i.e., self-configured addresses? > > I.e., this term is clearly defined in IPv6, but I don't believe its > defined for IPv4 in any document (and IMO, it should be). > The IPv4LL draft says (Section 1): "This document prescribes rules for how IPv4 link-local addresses MUST be treated by hosts and routers." And goes on to say things like: - (Section 1) addresses are allocated from 169.154.1.0 - 169.254.254.255 - (Section 2.5) packets with source and/or destination address in that range are never forwarded This seems like a reasonable definition to me, and so I think the document does define what link-local for IPv4 is. However, the text reads in a way that seems to assume the reader has an intuitive understanding of what link-local is beforehand. It could be clearer. It also seems to me that the mechanism for acquiring such an address doesn't have a great deal of relevance to the definition of link-local, but that isn't obvious from the document. [ I just noticed a typo too: Section 1. "With respects to hosts, it discusses .." ] Perhaps a positive statement could be made: "Zeroconf protocols operating across multiple IP subnets should use multicast and unicast address scopes other than link local." This is well defined for IPv6, and is defined for IPv4 multicast. Can we make a definition for IPv4 unicast address scopes?: a. "link local" as defined by IPv4LL b. "site scoped" defined as RFC1918 addressing c. "globally scoped" defined as everything else Is this document an appropriate place for such a definition? > > Requirement: > > - Protocols intended to span multiple IP subnets SHOULD NOT use > > broadcasts or link-local addressing. > > Why not? just stating something should or should not be done without > context isn't always very convincing. > A comment to the effect that broadcast and link-local traffic is never forwarded would justify the requirement for me. > > Topology changes or other events such as adding and removing hosts > > may cause conflicts and state changes within a protocol. Zeroconf > > protocols must be able to resolve conflicts and state changes caused > > by topology changes or other events. The scenario in the 2.1.2 Bridge > > Installed section is the only scenario that illustrates the need for > > this requirement, thus the below requirement is duplicated in section > > 2.1.2. However, this requirement applies to all protocol areas. > > Suggested rewording of the first part: > > Topology changes or other events such as adding and removing hosts > may cause changes to the overall system state, invalidate > assumptions made by some protocols, and lead to incorrect or > undesirable operating states. Zeroconf protocols must be able to > detect and resolve conflicts and state changes caused by topology > changes or other events in some cases. The scenario in the 2.1.2 > Bridge Installed section is the only scenario that illustrates the > need for this requirement, thus the below requirement is duplicated > in section 2.1.2. However, this requirement applies to all protocol > areas. > > > Requirement: > > - MUST respond to state changes and resolve conflicts in a timely > > manner. > > Note that his is really open ended, so I don't really know what "MUST" > means specifically. What conflicts need to be resolved? Indeed, what > is a "conflict"? My suspicion is that having a MUST here in a generic > sense is not appropriate. What you want is a MUST in specific > sitations that it is felt should or should not happen. > I agree. IIRC, the discussion relating to this requirement really focussed on unicast addressing and "routing" conflicts, where a MUST is probably appropriate. In general though a SHOULD ought to suffice, and the specific protocols (e.g. IPv4LL) can specify the MUST behaviour where it makes sense. > > Requirements: > > - MUST configure an appropriate netmask. > > - MUST have unique IP addresses within an IP subnet. > > - MUST have some routing information > > (for the internetwork scenario). > > On the last point, would it be more correct to say, needs the address > of one or more default routers? Or is there more to this? > I think the wording takes care to avoid the term "default router". Routing information may be a default route, but might not be. There was even discussion of hosts ARPing for every address and having the router do proxy ARP for destinations in different subnets. > > - MUST have unique IP subnets within an internetwork > > (only for the internetwork scenario). > > Do you need to scope this more? I.e., can't an "internetwork" consist > of the entire Internet (per the earlier definition?) > Perhaps "internetwork" should be a "zeroconf internetwork" in this section, where a "zeroconf internetwork" is the bunch of subnets connected to exactly one router. Zeroconfiguration of a single subnet, and zeroconfiguration of a set of subnets hanging off a single router should be allowed for (as per the charter). Communication with the global internet should not be precluded, and seems to be largely a matter of obtaining a default route, and a working DNS. Unique subnets can be allocated easily enough by a single router from a private(IPv4) or appropriately scoped(IPv6) address space but will require additional mechanisms (IPv6 SA, DHCP, ICMP addrmask, router discovery, etc) for this to be useful. I'm still confused about the whole single-router idea. It seems as if we have gone sufficiently far away from it now that it could be easily dropped entirely. The case of a single router seems to be adequately covered by the mini-dhcp draft and if you have a router, adding extra configuration services probably isn't going to hurt (if the router dies, you are probably stuffed anyway). Eventually, it could well become important to automatically configure multiple routers (and therefore subnets) in a zeroconf manner. Currently, this is not a topic for the working group, and I can't see how the single router topology moves us in that direction. > > Topology changes from the installation of a bridge or a router may > > create the following problems: multiple default routes that cause > > dial out lines to be used instead of broadband connections, > > duplicate IP addresses within an IP subnet, or duplicate IP > > subnets within an internetwork. > > I don't understand the comment (or implication) about multiple default > routes leading to dial-out lines being used. > No idea. > > Requirement: > > - MUST resolve conflicts and state changes in a timely manner. > > Can the document be more specific and say just what conflicts need to > be resolved? Or is the assumption that the previously discussed issues > is what needs to be addressed? > I read this as referring to section 2.1.1, where there are a set of uniqueness requirements, etc. Maybe it could do so explicitly. For me, this requirement adds an on-going consistency requirement for everything in 2.1.1. This is different to the similar statement earlier, which I take to be more general. > > 2.1.3 IPv6 Considerations > > > > IPv6 allows a host to select an appropriate IP address, netmask, > > and routing information, thus if a host is using IPv6, a zeroconf > > IP interface configuration solution already exists. > > Is this fully correct? Do routers automatically (without user > configuration) advertise themselves as default routers? > I don't quite follow your comment. Yes, some boxes might advertise themselves as default routers (some kind of IPv6 residential gateway springs to mind), but I don't see why that should be required. > Indeed, I'm a bit confused about whether this document assumes > multiple subnets are present. It seems to, but I thought the WG > decided that a single router was assumed. It would be good to state up > front what the assumptions are for the enivironment zeroconf is > operating in. Will there be just one router? Or multiple routers? Or > no routers? > Quite. I vote for no (zeroconf) routers at the moment. > > 2.2.1 Web Browsing > > > > An URL typically contains the name of a Web server. When a user > > enters an URL into a Web browser, the name must be translated to > > an IP address before any actual Web browsing occurs. Web servers > > often record log files of accesses, and wish to map the client's > > IP address back to a human-readable name for recording in the log > > file. Thus, a mechanism to translate the IP address to a name is > > required. > > > > Requirement: > > - MUST translate a name to an IP address. > > - MUST translate an IP address to a name. > > This text curiously doesn't mention the DNS. But, for the web server, > isn't the DNS reverse lookup specifically what is assumed/required? > Seems like the reqirement is much more specific than just "translate > name to address" and vice versa, and involves integration with the > DNS. > I see the DNS as just one implementation of name<->address mapping. For example, NetBIOS naming under windows 2000 lets me ping netbios names, web surf to netbios names, etc by trying the netbios name lookup before going to the DNS. If there is no DNS server around, the netbios stuff still works. A residential gateway could proxy name service requests to/from netbios and DNS to get integration. I think this could be what ends up being required for mDNS too if it were to be integrated as a zeroconf protocol into a non-zeroconf network (with a DNS server). > > 2.3.1 Scope Enumeration > > > > Applications that leave the choice of scope up to the user require > > the ability to enumerate what scopes the host is operating within. > > In addition, services that are assigned relative addresses require > > the ability to enumerate what scopes the host is within; only then > > will a host be able to apply the relative address to a scope. > > > > Requirements: > > - MUST list which of the scopes (local, link-local, or site-local) > > are available for hosts. > > - MUST list per-scope address ranges that may be allocated. > > I'm not clear what the requirement above is. That is, *who* is > responsbile for the MUST? The application? How is the application > supposed to determine this? Is the point that this information must > somehow be determinable? (General comment: This may all be an artifact > from the fact that the Requirements bullets are not using full > sentences.) > Yes, I think the point is that there should be a way for the application to find this information out. Incidentally, this doesn't seem to just be a zeroconf requirement, but is probably true of any networking with non-trivial multicast applications. > > 2.3.4 IPv6 Considerations > > > > To date, no range has been reserved for source-specific addresses > > in IPv6. Hence, until such a range is reserved, dynamic allocation > > of source-specific addresses applies only to IPv4. > > > > To date, no range has been reserved for dynamic allocation of > > Link-scoped addresses in IPv4. Hence, unless such a range is > > reserved, dynamic allocation of link-scoped addresses applies only > > to IPv6. > > Is there reason to think that the mechanisms in IPv4 and IPv6 might be > different? > Dunno. > > 2.4 Service Discovery Scenarios > > > > Service discovery protocols allow users to select services and/or > > hosts by a name that is discovered dynamically, rather than requiring > > that the user know the name in advance and type it in correctly. > > Can't an application find and select services without the user being > queried? E.g., isn't DNS a service? Should the user choose the DNS > server? > > Should the user always be prompted, or is there room for the user not > having to select at all, if there is only one choice? > Generally the user should only become involved when absolutely necessary. > > The IPv4 interface configuration protocol MAY omit security > > mechanisms if and only if that protocol is not used for IPv6 and > > cannot be extended to support IPv6. It is strongly recommended that > > it include security mechanisms, because many protocols are extended > > later in ways not anticipated by the original developer(s). > > Explain > > > use a printer that doesn't exist, no printed upon paper appears.) > > parsing > > On the security considerations. I'd like to run this by the Security > ADs before commenting specifically. So there may be some specific > comments on this point coming later. regards aidan ____ :wq! From owner-zeroconf@merit.edu Wed Jul 11 19:44:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25030 for ; Wed, 11 Jul 2001 19:44:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B586591267; Wed, 11 Jul 2001 19:44:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 834B191265; Wed, 11 Jul 2001 19:44:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58AC191267 for ; Wed, 11 Jul 2001 19:44:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F41385DE0D; Wed, 11 Jul 2001 19:46:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 597335DDB9 for ; Wed, 11 Jul 2001 19:46:02 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA23676; Wed, 11 Jul 2001 16:44:56 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA25572; Wed, 11 Jul 2001 16:44:53 -0700 (MST)] Received: from email.mot.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6BNilU25169; Thu, 12 Jul 2001 09:44:47 +1000 (EST) Message-ID: <3B4CE4EE.43DAF3AA@email.mot.com> Date: Thu, 12 Jul 2001 09:44:46 +1000 From: Aidan Williams Reply-To: Aidan.Williams@motorola.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-reqts-08.txt References: <5.1.0.14.2.20010709150627.03df2430@mail.amaranth.net> <5.1.0.14.2.20010711101731.03dff440@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Senie wrote: > > > > > 2.2.1 Web Browsing > > > > > > > > > > An URL typically contains the name of a Web server. When a user > > > > > enters an URL into a Web browser, the name must be translated to > > > > > an IP address before any actual Web browsing occurs. Web servers > > > > > often record log files of accesses, and wish to map the client's > > > > > IP address back to a human-readable name for recording in the log > > > > > file. Thus, a mechanism to translate the IP address to a name is > > > > > required. > > > > > > > > > > Requirement: > > > > > - MUST translate a name to an IP address. > > > > > - MUST translate an IP address to a name. > > > > > > > >This text curiously doesn't mention the DNS. But, for the web server, > > > >isn't the DNS reverse lookup specifically what is assumed/required? > > > > > Web servers as such are not dependent on DNS in any form. Implementations > > > of web servers often have such dependencies, but reverse lookups are NOT > > > required for proper operation of web servers. > > > >But the text in the document specifically says web servers do the reverse > >mapping, and that drives the requirement that a reverse mapping be > >doable. Existing web servers use the DNS for this. Are you saying that > >in a zeroconf environment, Web servers can and/or should use something > >other than DNS to do the reverse mapping? > > I think pointing to web servers in this case is a bad idea, as it's a bad > example. The example is based on common practice, not operational > necessity. Many embedded devices have web servers within them which have no > reliance on DNS. It's exactly this sort of embedded device (or "appliance" > as some call them) which is likely to occur on a link-local network (e.g. > for controlling devices in a house). > I can't off the top of my head think of a protocol which absolutely requires reverse lookup of names (if we had one, we should use it as an example). Slabs of the internet seem to function OK without reverse entries in the DNS. Perhaps the requirement is that a zeroconf name service *protocol* must support both forward and backward mapping. That avoids the necessity of specifying what a host/application needs to do in a given circumstance. DNS as it stands supports forward and backward mapping, but there are plenty of hosts for which the backward mapping fails. regards aidan ____ :wq! From owner-zeroconf@merit.edu Wed Jul 11 20:52:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26189 for ; Wed, 11 Jul 2001 20:52:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5AE3F91268; Wed, 11 Jul 2001 20:52:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CB0091269; Wed, 11 Jul 2001 20:52:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34D6791268 for ; Wed, 11 Jul 2001 20:52:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A0C985DE18; Wed, 11 Jul 2001 20:54:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 06AC75DDB1 for ; Wed, 11 Jul 2001 20:54:20 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA25901 for ; Wed, 11 Jul 2001 17:46:07 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA29920 for ; Wed, 11 Jul 2001 17:53:10 -0700 (MST)] Received: from email.mot.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6C0qxU26575 for ; Thu, 12 Jul 2001 10:53:04 +1000 (EST) Message-ID: <3B4CF4EB.434A2F2D@email.mot.com> Date: Thu, 12 Jul 2001 10:52:59 +1000 From: Aidan Williams Reply-To: Aidan.Williams@motorola.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt References: <200107112225.f6BMPIw01514@scv2.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stuart Cheshire wrote: > >If a link-local device has only 169.254/16 in its admittedly > >small routing table, won't it just look at the 10/8 address and > >decide there's no route to that network? There's no default > >route, and no way for it to know that it should try to ARP for > >that 10/8 address. So, it still won't communicate. > > Or, hosts with only an LL address could run in "ARP for everything" mode. > In fact, this is exactly what shipping Mac OS systems do today. > Very simple systems may not even need to ARP. Packets arriving will contain the relevant MAC address and could be turned around fairly simply in order to respond without ARPing, or even consulting routing tables. > >This box with the configured address would not know to ARP for > >the link-local address on the local wire, though, if it's only > >configured for non-link-local. I think any change in this area > >would require touching most hosts code to ensure compatability. > > So you're saying that it might not work with some of today's hosts. > Is that a reason to outlaw it from *ever* working? > Personally, I think not. It seems that the IPv4LL document as it currently stands encourages multiple IP addresses per interface (169.254/16 and "the other one"). Another host could choose to use IPv4LL only. In the event that the multihomed host selects the "wrong" source address when communicating with the IPv4LL host, the world doesn't have to stop and shouldn't be required to. regards aidan ____ :wq! From owner-zeroconf@merit.edu Wed Jul 11 22:12:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28079 for ; Wed, 11 Jul 2001 22:12:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0ACBD91269; Wed, 11 Jul 2001 22:13:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0D239126A; Wed, 11 Jul 2001 22:12:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6DAB91269 for ; Wed, 11 Jul 2001 22:12:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 616635DD8D; Wed, 11 Jul 2001 22:14:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 0DE2D5DD8C for ; Wed, 11 Jul 2001 22:14:30 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA28363 for ; Wed, 11 Jul 2001 19:13:25 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id TAA22744 for ; Wed, 11 Jul 2001 19:13:23 -0700 (MST)] Received: from email.mot.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6C2DLU27882 for ; Thu, 12 Jul 2001 12:13:21 +1000 (EST) Message-ID: <3B4D07C1.53CA3BCB@email.mot.com> Date: Thu, 12 Jul 2001 12:13:21 +1000 From: Aidan Williams Reply-To: Aidan.Williams@motorola.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Name resolution, dns and security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, The recent discussion of the requirements draft has made me reconsider the relationship between name resolution and the use of DNS in zeroconf networks. I agree that mDNS is a likely potential solution, however the security requirements sections seem to mandate something DNS-like as the solution (which bothers me a bit): 3.2 Name to Address Resolution [ other text ] A zeroconf name to address resolution protocol MUST be compatible with the use of DNSsec. Therefore it MUST be possible for a host running a zeroconf protocol to use DNS and DNSsec for authenticated name resolution if that host (or its administrator) chooses to do so. [RFC 2541] This paragraph could read as requiring the zeroconf protocol to be securable with DNSsec (i.e. thou shalt use DNS). Alternatively, you can ignore the whole issue and use whatever you like as long as the user can turn on and configure DNS/DNSsec (requiring an implmentation of DNS/DNSsec in each host). "MUST be possible" is wierd wording. It would be clearer to say that "zeroconf hosts MUST implement DNS/DNSsec" if that is what is meant. I would prefer this to read: A zeroconf name to address resolution protocol MUST support authentication of name resolution responses. (DNSsec doesn't authenticate requests, and we only need to be as good as DNSsec) One could then use mDNS+mDNSsec, IPSec+NetBIOS naming, SLP+auth, whatever and comply with the requirements without having to do DNS/DNSsec too. The "profile" document can mandate a particular mechanism (e.g. mDNS + mDNSSec) as required-to-implement. In general, I don't think DNS itself is the requirement for name to address resolution. Rather the requirements are: - supporting the API (as Erik suggested) - the protocol characteristics of DNS (forward and reverse mappings) The same could be said for the security requirements: - some API (I don't know of one) - the protocol characteristics of DNSsec (authentication of responses) regards aidan ____ :wq! From owner-zeroconf@merit.edu Wed Jul 11 22:48:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29606 for ; Wed, 11 Jul 2001 22:48:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D28F9126C; Wed, 11 Jul 2001 22:48:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58E589126D; Wed, 11 Jul 2001 22:48:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 734A49126C for ; Wed, 11 Jul 2001 22:48:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FAA65DD8D; Wed, 11 Jul 2001 22:49:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 981D45DD8C for ; Wed, 11 Jul 2001 22:49:52 -0400 (EDT) Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6C2mjp15494 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 11 Jul 2001 22:48:46 -0400 Message-Id: <5.1.0.14.2.20010711224437.03a15020@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 22:48:45 -0400 To: Stuart Cheshire , From: Daniel Senie Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt In-Reply-To: <200107112225.f6BMPIw01514@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 06:25 PM 7/11/01, Stuart Cheshire wrote: > >If a link-local device has only 169.254/16 in its admittedly > >small routing table, won't it just look at the 10/8 address and > >decide there's no route to that network? There's no default > >route, and no way for it to know that it should try to ARP for > >that 10/8 address. So, it still won't communicate. > >Or, hosts with only an LL address could run in "ARP for everything" mode. >In fact, this is exactly what shipping Mac OS systems do today. So the MAC runs with 169.254/16 addresses, but a /0 netmask so that it can arp everything? Interesting. Not a bad idea. Guess we should be asking whether the link-local draft should mention this as an option. My comments above were predicated on the belief that the netmask would be /16, as other systems seem to do (Windows, for example). Perhaps we should encourage the switch to /0? > >This box with the configured address would not know to ARP for > >the link-local address on the local wire, though, if it's only > >configured for non-link-local. I think any change in this area > >would require touching most hosts code to ensure compatability. > >So you're saying that it might not work with some of today's hosts. > >Is that a reason to outlaw it from *ever* working? Perhaps we should encourage it instead? I suspect we'd need to adjust the document a bit, though. If we're going to talk about 169.254/16, we tend to imply the netmask be set to /16. I'm willing to consider Apple may have a better idea here. Let's see what other folks think. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Jul 11 22:52:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29673 for ; Wed, 11 Jul 2001 22:52:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 973EF9126E; Wed, 11 Jul 2001 22:52:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B21C9126F; Wed, 11 Jul 2001 22:52:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 816F49126E for ; Wed, 11 Jul 2001 22:52:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E9275DD8D; Wed, 11 Jul 2001 22:54:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id A77095DD8C for ; Wed, 11 Jul 2001 22:54:23 -0400 (EDT) Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6C2r8p15650 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 11 Jul 2001 22:53:08 -0400 Message-Id: <5.1.0.14.2.20010711224949.009f6d80@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 22:53:08 -0400 To: Aidan.Williams@motorola.com From: Daniel Senie Subject: Re: draft-ietf-zeroconf-reqts-08.txt Cc: zeroconf@merit.edu In-Reply-To: <3B4CE4EE.43DAF3AA@email.mot.com> References: <5.1.0.14.2.20010709150627.03df2430@mail.amaranth.net> <5.1.0.14.2.20010711101731.03dff440@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:44 PM 7/11/01, Aidan Williams wrote: > > I think pointing to web servers in this case is a bad idea, as it's a bad > > example. The example is based on common practice, not operational > > necessity. Many embedded devices have web servers within them which have no > > reliance on DNS. It's exactly this sort of embedded device (or "appliance" > > as some call them) which is likely to occur on a link-local network (e.g. > > for controlling devices in a house). > > > >I can't off the top of my head think of a protocol which absolutely requires >reverse lookup of names (if we had one, we should use it as an example). >Slabs of the internet seem to function OK without reverse entries in the DNS. I'm about to submit the latest update to draft-ietf-dnsop-inaddr-required-??.txt. This document does cover what works and what doesn't with regards to INADDR and implementations which require it. The new version in the works goes on to recommend against using INADDR for any sort of "security" check. Much of this discussion probably should flow over to there (and hopefully a few folks who wouldn't otherwise read that WG's documents will get interested and provide some more feedback). >Perhaps the requirement is that a zeroconf name service *protocol* must >support both forward and backward mapping. That avoids the necessity of >specifying what a host/application needs to do in a given circumstance. >DNS as it stands supports forward and backward mapping, but there are >plenty of hosts for which the backward mapping fails. I agree with this. Avoiding mention of specific examples or protocols is probably the best bet in this case. Dan ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Thu Jul 12 06:59:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00608 for ; Thu, 12 Jul 2001 06:59:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B558D91283; Thu, 12 Jul 2001 06:59:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8507691284; Thu, 12 Jul 2001 06:59:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CD6691283 for ; Thu, 12 Jul 2001 06:59:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C0B25DE32; Thu, 12 Jul 2001 07:00:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A26575DE26 for ; Thu, 12 Jul 2001 07:00:36 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24291; Thu, 12 Jul 2001 04:59:27 -0600 (MDT) Received: from vayne (muc-isdn-9 [129.157.164.109]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id MAA26261; Thu, 12 Jul 2001 12:59:27 +0200 (MET DST) Date: Thu, 12 Jul 2001 13:11:30 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: draft-ietf-zeroconf-reqts-08.txt To: Aidan.Williams@motorola.com Cc: Daniel Senie , zeroconf@merit.edu In-Reply-To: "Your message with ID" <3B4CE4EE.43DAF3AA@email.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > I can't off the top of my head think of a protocol which absolutely requires > reverse lookup of names (if we had one, we should use it as an example). I think we should insist on requiring continued support for DNS app level interfaces, as described in RFC 1123, section 6.1. > DNS as it stands supports forward and backward mapping, but there are > plenty of hosts for which the backward mapping fails. The fact that reverse lookups fail in the real world points to operational problems, not a reason to give up on our attempt to correctly support desirable functionality. Erik From owner-zeroconf@merit.edu Thu Jul 12 10:29:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27924 for ; Thu, 12 Jul 2001 10:29:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 547279129B; Thu, 12 Jul 2001 10:27:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DFBF9129A; Thu, 12 Jul 2001 10:27:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A90E91299 for ; Thu, 12 Jul 2001 10:27:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 075C45DDB6; Thu, 12 Jul 2001 10:29:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 6B8A25DD93 for ; Thu, 12 Jul 2001 10:29:11 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id HAA08807 for ; Thu, 12 Jul 2001 07:28:05 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 12 Jul 2001 07:26:20 +0100 Received: from [206.111.147.149] (vpn-gh-1051.apple.com [17.254.140.26]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id HAA26446 for ; Thu, 12 Jul 2001 07:28:04 -0700 (PDT) Message-Id: <200107121428.HAA26446@scv3.apple.com> Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt Date: Thu, 12 Jul 2001 07:28:04 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >So the MAC runs with 169.254/16 addresses, but a /0 netmask so that it can >arp everything? Interesting. Not a bad idea. Guess we should be asking >whether the link-local draft should mention this as an option. My comments >above were predicated on the belief that the netmask would be /16, as other >systems seem to do (Windows, for example). Perhaps we should encourage the >switch to /0? Almost. The interface netmask is still /16, because we want the broadcast address to be 169.254.255.255. However, there is a *second* routing table entry that says "default (0/0) -> ARP" (instead of the usual "default (0/0) -> router"). Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Jul 12 13:29:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23701 for ; Thu, 12 Jul 2001 13:29:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B34991298; Thu, 12 Jul 2001 13:11:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE2F69129A; Thu, 12 Jul 2001 13:11:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C4B091298 for ; Thu, 12 Jul 2001 13:11:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCC685DE03; Thu, 12 Jul 2001 13:13:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 3E9DA5DDB6 for ; Thu, 12 Jul 2001 13:13:25 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07487 for ; Thu, 12 Jul 2001 11:12:17 -0600 (MDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id TAA22866; Thu, 12 Jul 2001 19:12:16 +0200 (MET DST) Date: Thu, 12 Jul 2001 19:24:19 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: please read: draft-ietf-zeroconf-host-prof-00.txt To: zeroconf@merit.edu Cc: erik.guttman@sun.com In-Reply-To: "Your message with ID" <200107121107.HAA01965@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I have submitted a new internet draft which is intended to (begin to) fulfill our last remaining unaddressed charter item. This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. ! The second, which follows the first, will detail a 'profile' ! specifying which standards specifically satisfy ZEROCONF ! requirements. Our goal is to submit this document by Aug 01. This is probably not reasonable, but please read the document and send your comments to the list soon. --=--=-- Title : Zeroconf Host Profile Filename : draft-ietf-zeroconf-host-prof-00.txt Requirements for Internet routers [RFC 1812] and hosts [RFC 1122] [RFC 1123] provide guidance to vendors and users of Internet communication software. They represent consensus arising from experience. This document similarly associates a set of protocols together for a particular purpose. In contrast to router and host requirements standards, the Zeroconf Host Profile does not arise out of experience, (though relevant experience is cited.) Instead, this comprises a set of protocols which complement each other when implemented together. --=--=-- Erik From owner-zeroconf@merit.edu Fri Jul 13 05:24:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06496 for ; Fri, 13 Jul 2001 05:24:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A962C912C2; Fri, 13 Jul 2001 05:25:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E03B912C5; Fri, 13 Jul 2001 05:25:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32278912C2 for ; Fri, 13 Jul 2001 05:25:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 207D05DDC5; Fri, 13 Jul 2001 05:26:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 756445DDA6 for ; Fri, 13 Jul 2001 05:26:40 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07472; Fri, 13 Jul 2001 02:25:31 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA16857; Fri, 13 Jul 2001 11:25:28 +0200 (MET DST) Date: Fri, 13 Jul 2001 11:37:31 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: default routers? (was: Re: draft-ietf-zeroconf-reqts-08.txt) To: Aidan.Williams@motorola.com Cc: Thomas Narten , zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Aidan, Thomas, > > draft-ietf-zeroconf-reqts-08.txt > > > Requirements: > > > - MUST configure an appropriate netmask. > > > - MUST have unique IP addresses within an IP subnet. > > > - MUST have some routing information > > > (for the internetwork scenario). > "Thomas Narten" wrote: > > > > On the last point, would it be more correct to say, needs the address > > of one or more default routers? Or is there more to this? > > Aidan William replied: > I think the wording takes care to avoid the term "default router". > Routing information may be a default route, but might not be. > There was even discussion of hosts ARPing for every address and > having the router do proxy ARP for destinations in different subnets. The background is that any mention of default router configuration implies that there are routers in the network, which may not be the case. Consider RFC 1122, section 3.3.1.1: The host IP layer MUST operate correctly in a minimal network environment, and in particular, when there are no gateways. For example, if the IP layer of a host insists on finding at least one gateway to initialize, the host will be unable to operate on a single isolated broadcast net. This clearly indicates that there is no requirement, in the link-local communication case, to know of any gateways. What we mean in the above case is that some routing information is needed, as stated in RFC 1122, section 3.3.1.2: The IP layer MUST support multiple default gateways. The ZEROCONF requirement is that routing state is available in the IP layer - which *may or may not* include a list of default gateways. In one plausible case, a LL-only device will use the 'arp for everything' forwarding policy, discussed by Stuart. In the case where DHCP configures an interface, default gateway(s) will be configured, while still allowing for delivery of datagrams to connected networks without the need for a gateway. We aimed at text which supported both possibilities, without requiring us to spell them out in detail. Erik From owner-zeroconf@merit.edu Fri Jul 13 05:25:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06566 for ; Fri, 13 Jul 2001 05:25:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29588912C5; Fri, 13 Jul 2001 05:25:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F32B0912C6; Fri, 13 Jul 2001 05:25:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEE99912C5 for ; Fri, 13 Jul 2001 05:25:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B80005DDC5; Fri, 13 Jul 2001 05:26:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 28C8B5DDA6 for ; Fri, 13 Jul 2001 05:26:47 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07499; Fri, 13 Jul 2001 02:25:39 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA16865; Fri, 13 Jul 2001 11:25:37 +0200 (MET DST) Date: Fri, 13 Jul 2001 11:37:40 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: scope enumeration? (was: Re: draft-ietf-zeroconf-reqts-08.txt) To: Aidan.Williams@motorola.com Cc: Thomas Narten , zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > draft-ietf-zeroconf-reqts-08.txt: > > > 2.3.1 Scope Enumeration > > > > > > Applications that leave the choice of scope up to the user require > > > the ability to enumerate what scopes the host is operating within. > > > In addition, services that are assigned relative addresses require > > > the ability to enumerate what scopes the host is within; only then > > > will a host be able to apply the relative address to a scope. > > > > > > Requirements: > > > - MUST list which of the scopes (local, link-local, or site-local) > > > are available for hosts. > > > - MUST list per-scope address ranges that may be allocated. > "Thomas Narten" wrote: > > I'm not clear what the requirement above is. That is, *who* is > > responsbile for the MUST? The application? How is the application > > supposed to determine this? Is the point that this information must > > somehow be determinable? (General comment: This may all be an artifact > > from the fact that the Requirements bullets are not using full > > sentences.) I agree the writing is not clear here. "Aidan Williams" replied: > Yes, I think the point is that there should be a way for the > application to find this information out. Incidentally, this doesn't > seem to just be a zeroconf requirement, but is probably true of any > networking with non-trivial multicast applications. Yes: This requirement is derived from MALLOC WG's requirements. The requirement here pertains to a zeroconf multicast address allocation protocol. This protocol has to expose its capabilities to applications. ZMAAP only works in a subset of the scopes listed above (link-local, unicast-prefix based and subnet-local). The ZMAAP API exposes this list to applications. A future version of ZMAAP capable of interoperation with MADCAP servers could support local, site-local or other scopes as well. Erik From owner-zeroconf@merit.edu Fri Jul 13 05:25:41 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06573 for ; Fri, 13 Jul 2001 05:25:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C4DE2912C3; Fri, 13 Jul 2001 05:25:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62B51912C5; Fri, 13 Jul 2001 05:25:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6742912C3 for ; Fri, 13 Jul 2001 05:25:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CECB85DE0D; Fri, 13 Jul 2001 05:26:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3AA385DDA6 for ; Fri, 13 Jul 2001 05:26:41 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07444; Fri, 13 Jul 2001 02:25:28 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA16853; Fri, 13 Jul 2001 11:25:26 +0200 (MET DST) Date: Fri, 13 Jul 2001 11:37:29 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: IPv4 scoped architecture? (was: Re: draft-ietf-zeroconf-reqts-08.txt) To: Aidan.Williams@motorola.com Cc: Thomas Narten , zeroconf@merit.edu In-Reply-To: "Your message with ID" <3B4CE1A0.EB415A6C@email.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Aidan, > Can we make a definition for IPv4 unicast address scopes?: > > a. "link local" as defined by IPv4LL > b. "site scoped" defined as RFC1918 addressing > c. "globally scoped" defined as everything else This is an interesting starting point for an IPv4 scoped architecture. > Is this document an appropriate place for such a definition? No. We are concluding work on this doc, not adding more (very contentious) topics for consideration. Erik From owner-zeroconf@merit.edu Fri Jul 13 05:25:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06627 for ; Fri, 13 Jul 2001 05:25:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95E41912C6; Fri, 13 Jul 2001 05:25:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF038912C7; Fri, 13 Jul 2001 05:25:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85B22912C6 for ; Fri, 13 Jul 2001 05:25:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91A8A5DDC5; Fri, 13 Jul 2001 05:26:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 15BAB5DDA6 for ; Fri, 13 Jul 2001 05:26:52 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01502; Fri, 13 Jul 2001 03:25:42 -0600 (MDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA16870; Fri, 13 Jul 2001 11:25:42 +0200 (MET DST) Date: Fri, 13 Jul 2001 11:37:46 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: v6 malloc considerations? (was: Re: draft-ietf-zeroconf-reqts-08.txt) To: Thomas Narten Cc: zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > draft-ietf-zeroconf-reqts-08.txt: > > 2.3.4 IPv6 Considerations > > > > To date, no range has been reserved for source-specific addresses > > in IPv6. Hence, until such a range is reserved, dynamic allocation > > of source-specific addresses applies only to IPv4. > > > > To date, no range has been reserved for dynamic allocation of > > Link-scoped addresses in IPv4. Hence, unless such a range is > > reserved, dynamic allocation of link-scoped addresses applies only > > to IPv6. "Thomas Narten" wrote: > Is there reason to think that the mechanisms in IPv4 and IPv6 might be > different? The difference lies in the current state of IANA reservation and standardization, not in what we think the protocols need to do or how they'll do it. Erik From owner-zeroconf@merit.edu Fri Jul 13 05:25:53 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06638 for ; Fri, 13 Jul 2001 05:25:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0FF2912C4; Fri, 13 Jul 2001 05:25:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D026912C6; Fri, 13 Jul 2001 05:25:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B0BF912C4 for ; Fri, 13 Jul 2001 05:25:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F29F85DDA6; Fri, 13 Jul 2001 05:26:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 77B3B5DDC5 for ; Fri, 13 Jul 2001 05:26:41 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01430; Fri, 13 Jul 2001 03:25:31 -0600 (MDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA16861; Fri, 13 Jul 2001 11:25:31 +0200 (MET DST) Date: Fri, 13 Jul 2001 11:37:34 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: multiple routers in ZC? (was: Re: draft-ietf-zeroconf-reqts-08.txt) To: Aidan.Williams@motorola.com Cc: Thomas Narten , zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > draft-ietf-zeroconf-reqts-08.txt: > > > - MUST have unique IP subnets within an internetwork > > > (only for the internetwork scenario). > "Thomas Narten" wrote: > > Do you need to scope this more? I.e., can't an "internetwork" consist > > of the entire Internet (per the earlier definition?) Aidan William replied: > Perhaps "internetwork" should be a "zeroconf internetwork" in this > section, where a "zeroconf internetwork" is the bunch of subnets > connected to exactly one router. The text above is sufficiently general that it leaves room for multiple router zeroconf interface autoconfiguration to be standardized in the future. We did not preclude multiple routers from our charter because we thought it was a bad idea. Rather, we did not think we could standardize multi-router zeroconf protocols in a timely manner. The requirements document does not need to echo our charter humility, restricting future (perhaps immanent) standardization efforts. > Zeroconfiguration of a single subnet, and zeroconfiguration of a set > of subnets hanging off a single router should be allowed for (as per > the charter). It is allowed for. > Communication with the global internet should not be > precluded, and seems to be largely a matter of obtaining a default > route, and a working DNS. I do not believe stateless addrconf of global IPv4 addresses will ever be standardized. Stateful addrconf (DHCP) for IPv4 is the mechanism by which devices can obtain dynamic configuration and communicate with the global internet. There are interesting questions which we do not address, and should not in the requirements document. These are questions we could take up in the ZEROCONF WG, if we were to expand on our charter: - What do you do on a network with multiple routers but no administration? Such a network would not necessarily be zeroconf from the hosts' perspective, but could be from the routers'. - Should there be some standard way to attach a mini-dhcp to a configured network and 'inject' global configuration? (see figure below). zero-admin network ----------[mini-DHCP] -> --------[DHCP]------ local-conf global-conf network > > Indeed, I'm a bit confused about whether this document assumes > > multiple subnets are present. It seems to, but I thought the WG > > decided that a single router was assumed. It would be good to state up > > front what the assumptions are for the enivironment zeroconf is > > operating in. Will there be just one router? Or multiple routers? Or > > no routers? Why do we have to make that decision? As long as the requirements fit those different cases, aren't we OK? Clearly we want to support zero routers. One router is an important case, where we have very different link layers (802, firewire, PPP) tied together, each link of which configured by a mini-DHCP server. These links could all use mDNS, SLP, ZMAAP, etc. Erik From owner-zeroconf@merit.edu Fri Jul 13 05:27:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06863 for ; Fri, 13 Jul 2001 05:27:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5FCB912C7; Fri, 13 Jul 2001 05:27:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81792912C8; Fri, 13 Jul 2001 05:27:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9810B912C7 for ; Fri, 13 Jul 2001 05:27:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CFD35DDC5; Fri, 13 Jul 2001 05:29:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0CACE5DDA6 for ; Fri, 13 Jul 2001 05:29:29 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08144; Fri, 13 Jul 2001 02:28:20 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA16911; Fri, 13 Jul 2001 11:28:19 +0200 (MET DST) Date: Fri, 13 Jul 2001 11:40:22 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: draft-ietf-zeroconf-reqts-08.txt To: Aidan.Williams@motorola.com Cc: Thomas Narten , zeroconf@merit.edu In-Reply-To: "Your message with ID" <3B4CE1A0.EB415A6C@email.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > draft-ietf-zeroconf-reqts-08.txt: > > > Topology changes from the installation of a bridge or a router may > > > create the following problems: multiple default routes that cause > > > dial out lines to be used instead of broadband connections, > > > duplicate IP addresses within an IP subnet, or duplicate IP > > > subnets within an internetwork. > "Thomas Narten" wrote: > > I don't understand the comment (or implication) about multiple default > > routes leading to dial-out lines being used. This is supposed to mean that if one indiscriminately dropped routers or bridges into a network, inappropriate topologies may result leading to dumb forwarding paths. How this could happen, given that routers need to be configured, I don't know. I think this paragraph should be dropped. Erik From owner-zeroconf@merit.edu Thu Jul 19 04:32:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00197 for ; Thu, 19 Jul 2001 04:32:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E7D59126F; Thu, 19 Jul 2001 04:32:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C64E291270; Thu, 19 Jul 2001 04:32:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D06729126F for ; Thu, 19 Jul 2001 04:32:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BFE65DDA9; Thu, 19 Jul 2001 04:34:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B7FDE5DDA5 for ; Thu, 19 Jul 2001 04:34:40 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14584; Thu, 19 Jul 2001 01:33:24 -0700 (PDT) Received: from vayne (muc-isdn-11 [129.157.164.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id KAA03790; Thu, 19 Jul 2001 10:33:22 +0200 (MET DST) Date: Thu, 19 Jul 2001 10:45:27 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: ZEROCONF WG agenda for IETF 51 To: agenda@ietf.org Cc: erik.guttman@sun.com, cheshire@apple.com, zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Zero Configuration Networking Working Group (zeroconf) Thursday, August 09 at 15:30-17:30 ================================== CHAIRS: Erik Guttman Stuart Cheshire AGENDA: 1) Agenda discussion & finalization 5 minutes Stuart and Erik 2) Wrap up of requirements doc 5 minutes draft-ietf-zeroconf-reqts-08.txt GOAL: Agree work on this document is complete. Erik 3) Wrap up of IPv4 link-local doc 5 minutes draft-ietf-zeroconf-ipv4-linklocal-03.txt GOAL: Agree work on this document is complete. Stuart 4) ZMAAP - Status, issues, next? 30 minutes draft-ietf-zeroconf-zmaap-01.txt draft-ietf-zeroconf-zmaap-api-00.txt GOAL: Settle technical issues. Agree to disposition of the document (standards track or experimental?) What remains to do before WG last call? Erik 5) Multicast Address Allocation using 10 minutes IPv4 Link-local Address draft-hong-autoconf-multicast-ipv4-00.txt GOAL: Determine if this document has contribution to make to continuing effort to standardize mc address allocation in the zeroconf group. If so, come up with a plan. Yong-Geun Hong 6) Zeroconf Host Profile 30 minutes draft-ietf-zeroconf-host-prof-00.txt GOAL: Kick off this work. Get as far as we can on it. Various questions about document structure to answer. Erik 7) Where to - charter discussion kick off 5 minutes GOAL: Determine whether to take on more work. Stuart & Erik 8) Mini-DHCP 10 minutes draft-aboba-dhc-mini-03.txt Bernard Aboba 9) Operational Zeroconf questions 10 minutes Peter van der Stok 10) Others: 5 minutes Easy Security Configuration & Router Zeroconf 11) Wrap up on the ZEROCONF charter remaining GOAL: WG meeting consensus on charter direction. From owner-zeroconf@merit.edu Fri Jul 20 10:13:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13995 for ; Fri, 20 Jul 2001 10:13:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3E72912C7; Fri, 20 Jul 2001 10:13:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF3BE912C8; Fri, 20 Jul 2001 10:13:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD5AF912C7 for ; Fri, 20 Jul 2001 10:13:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5559C5DDB7; Fri, 20 Jul 2001 10:15:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B39845DDB2 for ; Fri, 20 Jul 2001 10:15:13 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11288; Fri, 20 Jul 2001 07:13:53 -0700 (PDT) Received: from vayne (muc-isdn-2 [129.157.164.102]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA00579; Fri, 20 Jul 2001 16:13:49 +0200 (MET DST) Date: Fri, 20 Jul 2001 16:25:06 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: summary of discussion on draft-ietf-zeroconf-reqts-08.txt To: Thomas Narten , zeroconf@merit.edu Cc: erik.guttman@sun.com, cheshire@apple.com, Erik Nordmark Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, This email constitutes a WG action: It summarizes comments and their results. It is not a call for further discussion unless it is to take issue with the statements below or conclude an unresolved point. This document has already gone through WG last call _twice_. Action: Open = more discussion needed No change = no action to be taken, keep text Change = take suggested change In each case where there is an open topic, I make a suggestion in order to advance discussion. Thomas, as you raised most of these issues, please see if you are satisfied by the suggestions and actions below. --------------------------------------------------------------------- 08.01. New title "Thomas Narten" wrote: > How about a more descriptive title than "zeroconf requirements" Suggestion: Zeroconf IP Host Requirements This makes it clear that we are discussing hosts not routers. Action: Open --------------------------------------------------------------------- 08.02 MAC addr as config info "Thomas Narten" wrote: > > A zeroconf protocol is able to operate correctly in the absence > > of configured information from either a user or infrastructure > > services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, > > RFC 1035] servers. Zeroconf protocols may use configured > > information, when it is available, but do not rely on it being > > present. One possible exception is the use of MAC addresses > > (i.e. layer two addresses) as parameters in zeroconf protocols. > > I do not consider a MAC address to be configured information. It is > built-in as far as the end user is concerned. While this is strictly true, in some cases it is configurable. (Solaris for instance allows this, as do many PC NIC drivers.) A second consideration was whether ANY parameters could be used in zeroconf protocols, built-in or otherwise. We wanted to emphasize that MAC addresses were OK for use. Action: No change. --------------------------------------------------------------------- 08.03 DHCP used as ZC protocol? "Thomas Narten" wrote: > This may be a minor nit, but it may be worth pointing out that DHCP > *protocols* could be used in a zeroconf environment, so long as no > user configuration were needed. One can imagine a DHCP server figuring > out a lot of things on its own without being configured (and there has > been talk on the list about this). Dan Senie wrote: > There was a lot of debate about this. As I recall, the concern is > that Zeroconf can't rely on there being a server. No server means > no DHCP. Stuart Cheshire wrote: > No, the focus of Zeroconf is, "IP should work even if there *isn't* a > DHCP server on the network." "Thomas Narten" wrote: > So I see. :-) I'm OK leaving the text as is then. Action: No change. --------------------------------------------------------------------- 08.04 terminology "Thomas Narten" wrote: > > 1.5 Routable Protocol Requirement > > > > If a protocol is intended to span multiple IP subnets it SHOULD > > NOT use broadcasts or link-local addressing. > > define what link-local addressing is? i.e., self-configured addresses? Dan Senie wrote: > yes. See the link local draft... "Thomas Narten" wrote: > Ah, yes, that makes sense. Action: No change. --------------------------------------------------------------------- 08.05 why not allow MC and BC for protocols spanning multiple subnets? "Thomas Narten" wrote: > > Requirement: > > - Protocols intended to span multiple IP subnets SHOULD NOT use > > broadcasts or link-local addressing. > > Why not? just stating something should or should not be done without > context isn't always very convincing. Dan Senie wrote: > Link local addressing can't be routed per definitions in the > other draft. "Thomas Narten" wrote: > My point was more on the "should not use broadcast". Per the > definition of link-local addressing, it *can't* be used -- routers > will drop the traffic, so this would seem to need to be stronger than > a "SHOULD NOT". Note that DHCP and a few other protocols use broadcast and span multiple subnets. But in order to do this, the protocol requires special router assist. In general this is a bad idea as it requires router software changes. Action: Change text to "MUST NOT" --------------------------------------------------------------------- 08.06 topology change text problems "Thomas Narten" wrote: > > Topology changes or other events such as adding and removing hosts > > may cause conflicts and state changes within a protocol. Zeroconf > > protocols must be able to resolve conflicts and state changes caused > > by topology changes or other events. The scenario in the 2.1.2 Bridge > > Installed section is the only scenario that illustrates the need for > > this requirement, thus the below requirement is duplicated in section > > 2.1.2. However, this requirement applies to all protocol areas. > > Suggested rewording of the first part: > > Topology changes or other events such as adding and removing hosts > may cause changes to the overall system state, invalidate > assumptions made by some protocols, and lead to incorrect or > undesirable operating states. Zeroconf protocols must be able to > detect and resolve conflicts and state changes caused by topology > changes or other events in some cases. The scenario in the 2.1.2 > Bridge Installed section is the only scenario that illustrates the > need for this requirement, thus the below requirement is duplicated > in section 2.1.2. However, this requirement applies to all protocol > areas. Action: Change text as suggested. --------------------------------------------------------------------- 08.07 open ended text "Thomas Narten" wrote: > > Requirement: > > - MUST respond to state changes and resolve conflicts in a timely > > manner. > > Note that his is really open ended, so I don't really know what "MUST" > means specifically. What conflicts need to be resolved? Indeed, what > is a "conflict"? My suspicion is that having a MUST here in a generic > sense is not appropriate. What you want is a MUST in specific > sitations that it is felt should or should not happen.t Suggestion: Spell this out for each protocol area: address autoconfiguration - detect and eliminate duplicate addresses. name resolution - allow resolution of names which could not previously be resolved. In particular, if a host wishes to resolve its own name to determine if it is unique, it will be able to detect this conflict and resolve it in a timely manner. service discovery - allow discovery of previously undiscovered services. multicast address allocation protocol - detect and eliminate duplicate addresses. Action: Open --------------------------------------------------------------------- 08.08 say some more about routing information "Thomas Narten" wrote: > > Requirements: > > - MUST configure an appropriate netmask. > > - MUST have unique IP addresses within an IP subnet. > > - MUST have some routing information > > (for the internetwork scenario). > > On the last point, would it be more correct to say, needs the address > of one or more default routers? Or is there more to this? Aidan William replied: > I think the wording takes care to avoid the term "default router". > Routing information may be a default route, but might not be. > There was even discussion of hosts ARPing for every address and > having the router do proxy ARP for destinations in different subnets. "Erik Guttman" wrote: > The background is that any mention of default router configuration > implies that there are routers in the network, which may not be the > case. Consider RFC 1122, section 3.3.1.1: > > The host IP layer MUST operate correctly in a minimal > network environment, and in particular, when there are no > gateways. For example, if the IP layer of a host insists on > finding at least one gateway to initialize, the host will be > unable to operate on a single isolated broadcast net. > > This clearly indicates that there is no requirement, in the link-local > communication case, to know of any gateways. > > What we mean in the above case is that some routing information is > needed, as stated in RFC 1122, section 3.3.1.2: > > The IP layer MUST support multiple default gateways. > > The ZEROCONF requirement is that routing state is available in the > IP layer - which *may or may not* include a list of default gateways. > In one plausible case, a LL-only device will use the 'arp for everything' > forwarding policy, discussed by Stuart. In the case where DHCP configures > an interface, default gateway(s) will be configured, while still allowing > for delivery of datagrams to connected networks without the need for a > gateway. > > We aimed at text which supported both possibilities, without requiring > us to spell them out in detail. Action: change text to clarify zc may or may not include a list of gateways. --------------------------------------------------------------------- 08.09 scoping "Thomas Narten" wrote: > > - MUST have unique IP subnets within an internetwork > > (only for the internetwork scenario). > > Do you need to scope this more? I.e., can't an "internetwork" consist > of the entire Internet (per the earlier definition?) Aidan William replied: > Perhaps "internetwork" should be a "zeroconf internetwork" in this > section, where a "zeroconf internetwork" is the bunch of subnets > connected to exactly one router. Erik Guttman wrote: > The text above is sufficiently general that it leaves room for multiple > router zeroconf interface autoconfiguration to be standardized in the > future. > > We did not preclude multiple routers from our charter because we thought > it was a bad idea. Rather, we did not think we could standardize > multi-router zeroconf protocols in a timely manner. The requirements > document does not need to echo our charter humility, restricting future > (perhaps immanent) standardization efforts. Suggestion: clarify that this is currently only specified on a single link or a network with routers whose configuration is out of scope for this spec. Action: Open --------------------------------------------------------------------- 08.10 cannot understand text "Thomas Narten" wrote: > > Topology changes from the installation of a bridge or a router may > > create the following problems: multiple default routes that cause > > dial out lines to be used instead of broadband connections, > > duplicate IP addresses within an IP subnet, or duplicate IP > > subnets within an internetwork. > > I don't understand the comment (or implication) about multiple default > routes leading to dial-out lines being used. Erik Guttman wrote: > This is supposed to mean that if one indiscriminately dropped > routers or bridges into a network, inappropriate topologies may > result leading to dumb forwarding paths. How this could happen, > given that routers need to be configured, I don't know. I think > this paragraph should be dropped. Action: Change - Drop paragraph --------------------------------------------------------------------- 08.11 resolve conflicts - should be more specific "Thomas Narten" wrote: > > Requirement: > > - MUST resolve conflicts and state changes in a timely manner. > > Can the document be more specific and say just what conflicts need to > be resolved? Or is the assumption that the previously discussed issues > is what needs to be addressed? Aidan.Williams@motorola.com wrote: > I read this as referring to section 2.1.1, where there are a set of > uniqueness requirements, etc. Maybe it could do so explicitly. > For me, this requirement adds an on-going consistency requirement for > everything in 2.1.1. Suggestion: Isn't this addressed by 08.07 above? Action: Open --------------------------------------------------------------------- 08.12 IPv6 considerations for interface configuration "Thomas Narten" wrote: > > 2.1.3 IPv6 Considerations > > > > IPv6 allows a host to select an appropriate IP address, netmask, > > and routing information, thus if a host is using IPv6, a zeroconf > > IP interface configuration solution already exists. > > > Is this fully correct? Do routers automatically (without user > configuration) advertise themselves as default routers? > > Indeed, I'm a bit confused about whether this document assumes > multiple subnets are present. It seems to, but I thought the WG > decided that a single router was assumed. It would be good to state up > front what the assumptions are for the enivironment zeroconf is > operating in. Will there be just one router? Or multiple routers? Or > no routers? Suggestion: We have to support 0 routers. We can support 1+ router. Folks want to consider how 1 router can be auto configuring, but this is tangential to the requirements in this document. We have nothing to say about how routers are configured. Let's make it clear the ZC requirements concern only host configuration not router configuration. Action: Open --------------------------------------------------------------------- 08.13 bad example "Thomas Narten" wrote: > > 2.2.1 Web Browsing > > > > An URL typically contains the name of a Web server. When a user > > enters an URL into a Web browser, the name must be translated to > > an IP address before any actual Web browsing occurs. Web servers > > often record log files of accesses, and wish to map the client's > > IP address back to a human-readable name for recording in the log > > file. Thus, a mechanism to translate the IP address to a name is > > required. > > > > Requirement: > > - MUST translate a name to an IP address. > > - MUST translate an IP address to a name. > > This text curiously doesn't mention the DNS. But, for the web server, > isn't the DNS reverse lookup specifically what is assumed/required? > Seems like the reqirement is much more specific than just "translate > name to address" and vice versa, and involves integration with the > DNS. Stuart Cheshire writes: > In practice, we believe that Multicast DNS will be the answer. However, > from a strict requirements standpoint, the web server calls an OS or > library API routine to map an address to a name -- whether that's done > using DNS packets, or mDNS, or NetBIOS, is of no concern to the web > server software. "Thomas Narten" wrote: > Is there any sort of requirement that whatever is developed is > transparent to existing applications? I.e., looks like DNS to (most) > applications? > > I would think that requiring applications to be aware that they are on > a zeroconf network and then behave differently sets a pretty high bar. Erik Guttman wrote: > Yes. What we want to say is that the upper layer support apps relying > on RFC 1123 DNS interfaces will continue to be supported. We do not > have to, nor should we, say in the reqts doc how this support is achieved. Erik Guttman wrote: > The web server example is motivate and support the listed reqts > for forward and reverse lookup. What we should really do, perhaps, > is require support for RFC 1123, section 6.1. > In summary, I suggest that this text be changed to: > > 2.4 Service Discovery Scenarios > > Service discovery protocols MUST allow users or software to > discover instances and select among available services. This > removes the requirement that the user or client software know > a server's location in advance and in order for the client > to communicate with the server. Aidan williams <> wrote: > I can't off the top of my head think of a protocol which absolutely requires > reverse lookup of names (if we had one, we should use it as an example). Erik Guttman wrote: > I think we should insist on requiring continued support for DNS app level > interfaces, as described in RFC 1123, section 6.1. Action: Change text. --------------------------------------------------------------------- 08.14 unclear requirement "Thomas Narten" wrote: > > 2.3.1 Scope Enumeration > > > > Applications that leave the choice of scope up to the user require > > the ability to enumerate what scopes the host is operating within. > > In addition, services that are assigned relative addresses require > > the ability to enumerate what scopes the host is within; only then > > will a host be able to apply the relative address to a scope. > > > > Requirements: > > - MUST list which of the scopes (local, link-local, or site-local) > > are available for hosts. > > - MUST list per-scope address ranges that may be allocated. > > I'm not clear what the requirement above is. That is, *who* is > responsbile for the MUST? The application? How is the application > supposed to determine this? Is the point that this information must > somehow be determinable? (General comment: This may all be an artifact > from the fact that the Requirements bullets are not using full > sentences.) Erik Guttman wrote: > I agree the writing is not clear here. "Aidan Williams" replied: > Yes, I think the point is that there should be a way for the > application to find this information out. Incidentally, this doesn't > seem to just be a zeroconf requirement, but is probably true of any > networking with non-trivial multicast applications. Erik Guttman wrote: > Yes: This requirement is derived from MALLOC WG's requirements. > The requirement here pertains to a zeroconf multicast address allocation > protocol. This protocol has to expose its capabilities to applications. > > ZMAAP only works in a subset of the scopes listed above (link-local, > unicast-prefix based and subnet-local). The ZMAAP API exposes this > list to applications. A future version of ZMAAP capable of interoperation > with MADCAP servers could support local, site-local or other scopes > as well. Suggestion: MUST -> Application support software used to autoconfigure multicast addresses MUST Action: Open --------------------------------------------------------------------- 08.15 IPv4 vs IPv6 wrt. multicast address autoconf "Thomas Narten" wrote: > > 2.3.4 IPv6 Considerations > > > > To date, no range has been reserved for source-specific addresses > > in IPv6. Hence, until such a range is reserved, dynamic allocation > > of source-specific addresses applies only to IPv4. > > > > To date, no range has been reserved for dynamic allocation of > > Link-scoped addresses in IPv4. Hence, unless such a range is > > reserved, dynamic allocation of link-scoped addresses applies only > > to IPv6. > > Is there reason to think that the mechanisms in IPv4 and IPv6 might be > different? Erik Guttman wrote: > The difference lies in the current state of IANA reservation and > standardization, not in what we think the protocols need to do or > how they'll do it. Action: Closed --------------------------------------------------------------------- 08.16 user specific language in service discovery "Thomas Narten" wrote: > > 2.4 Service Discovery Scenarios > > > > Service discovery protocols allow users to select services and/or > > hosts by a name that is discovered dynamically, rather than requiring > > that the user know the name in advance and type it in correctly. > > Can't an application find and select services without the user being > queried? E.g., isn't DNS a service? Should the user choose the DNS > server? > > Should the user always be prompted, or is there room for the user not > having to select at all, if there is only one choice? Dan Senie wrote: > If there's no server serving DNS, it'll be hard to use it. Erik Guttman wrote: > What we really want to say is that services can be discovered and selected, > by users or by a computer program. That way the location of the server > does not need to be known in advance for client-server software to function. > > We will quickly get into a rathole about DNS here. > I suggest that this text be changed to: > Service discovery protocols allow users or software to discover > and select among available services. This removes the requirement > that the user or client software know a server's location in > advance in order for the cleint to communicate with the server. Action: Change text. --------------------------------------------------------------------- 08.17 explain security requirements text better, for IPv4 "Thomas Narten" wrote: > > > The IPv4 interface configuration protocol MAY omit security > > mechanisms if and only if that protocol is not used for IPv6 and > > cannot be extended to support IPv6. It is strongly recommended that > > it include security mechanisms, because many protocols are extended > > later in ways not anticipated by the original developer(s). > > Explain This tangled formation came from (a) simple text from me saying since ARP is insecure, IPv4 autoconf MAY be too, (b) Ran noting that IPv6 may be implemented over IPv4 so more care would be needed in the formulation and (c) Stuart's polishing the text for clarity while trying to preserve as much as possible so as to not force a new last call (which happened anyway). What it means is: IPv4 autoconf MAY be insecure to configure IPv4 interface parameters (as ARP is insecure). If the IPv4 autoconf mechanism is used to support IPv6, it had better be secured (at some level - say the IPv6 in IPv4 packets may include IPsec AH for the ND messages). Ran wanted to make sure that even though we may omit security (we do in IPv4 LL autoconf) there's some text indicating its a Bad Thing. Suggestion: Leave it alone. Action: Open --------------------------------------------------------------------- 08.18 broken syntax "Thomas Narten" wrote: > > use a printer that doesn't exist, no printed upon paper appears.) > > parsing Action: Change text. --------------------------------------------------------------------- 08.19 "Aidan Williams" > [ I just noticed a typo too: > Section 1. "With respects to hosts, it discusses .." ] Action: Change text. --------------------------------------------------------------------- Erik Guttman ZEROCONF WG cochair From owner-zeroconf@merit.edu Fri Jul 20 10:32:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19855 for ; Fri, 20 Jul 2001 10:32:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAD02912C9; Fri, 20 Jul 2001 10:31:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 356D5912CB; Fri, 20 Jul 2001 10:31:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4547912C9 for ; Fri, 20 Jul 2001 10:31:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C520E5DDB5; Fri, 20 Jul 2001 10:33:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 72EC85DDB2 for ; Fri, 20 Jul 2001 10:33:01 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17449 for ; Fri, 20 Jul 2001 07:31:44 -0700 (PDT) Received: from vayne (muc-isdn-2 [129.157.164.102]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA00931; Fri, 20 Jul 2001 16:31:41 +0200 (MET DST) Date: Fri, 20 Jul 2001 16:43:46 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: zeroconf host profile as Applicability Statement To: zeroconf@merit.edu Cc: erik.guttman@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, RFC 2026, section 3.2 defines an applicability statement as a standards track document which can - group together standards track technical specifications - define requiremnt levels for these - define a domain of applicability My proposal is to issue the host profile document (when it is done) as a standards track applicability statement. The only changes needed to the 00 doc are to change the following: Title Zeroconf Host Profile Applicability Statement Abstract This document specifies a set of Zero Configuration Protocols which combined support the Zero Configuration domain of applicability. This host profile supports the same upper layer feature set as defined in STD 3 [RFC 1123] by hosts lacking any prior configuration, though in a restricted domain. New section: Zero Configuration Domain of Applicability x. The Zero Configuration Domain of Applicability Hosts which lack any specific configuration have zero configuration. The zero configuration domain of applicability concerns hosts with zero configuration for specific functions x.1. Zero configuration is not all or nothing A host may be configured with regard to some functions and have zero configuration for others. For example, a host may lack IP interface configuration (described in Section 4.1) but have naming configuration (described in Section 4.2) In this case, zero configuration IP interface autoconfiguration will be used by a host adhering to the Zeroconf Host Profile. x.2. Configured vs. Zero Configuration Protocol behavior Zero configuration behavior in each area is well defined. The specific behavior of a host when it becomes configured varies. Each protocol which supports the zero configuration protocol requirements varies in this respect. IPv4 Link-local IP Interace Configuration [7] and IPv6 address autoconfiguration, [RFC 2461] and ZMAAP [12] are used whether an interface is configued or not. Link-local Multicast DNS [10] by default is only used when a host has no configured DNS server, unless specifically configure to enable link-local Multicast behavior. SLPv2 [RFC 2608] always operates in a zero configuration mode, transitions in behavior and reconfiguration occur automatically. (SLPv2 agents may also be configured manually, but that does this does not reduce or change their automatic functions.) x.3. Scalability and network configuration The zero configuration domain of applicability includes any IP network which supports multicast (though only broadcast is needed for IPv4 link-local interface configuration). Some protocols described in this applicability statement are defined to only operate using link-local addressing and link-local scope multicast. This is not an inherant limitation of this domain of applicability - for example, SLPv2 [RFC 2608] is defined to operate at admin local scope [RFC 2365] for IPv4 and site local scope for IPv6. [RFC 3111] In any case, the zero configuration domain of applicability is a network under a single common administration, and in some cases only a single network link. Erik ----------------------------------------------------------------------- To see the changes folded in please see: http://www.neato.org/~femur/draft-ietf-zeroconf-host-prof-01.txt As I posted draft-ietf-zeroconf-host-prof-00.txt last week, the 01 revision will probably not get in before the deadline. Thus, the 00 doc is really the one we need to discuss for IETF 51. From owner-zeroconf@merit.edu Fri Jul 20 20:07:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21937 for ; Fri, 20 Jul 2001 20:07:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 280009121C; Fri, 20 Jul 2001 20:07:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE2169121D; Fri, 20 Jul 2001 20:07:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1021B9121C for ; Fri, 20 Jul 2001 20:07:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7A6F5DDB2; Fri, 20 Jul 2001 20:09:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 3B6AA5DDA9 for ; Fri, 20 Jul 2001 20:09:34 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id RAA01441 for ; Fri, 20 Jul 2001 17:08:17 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 20 Jul 2001 17:06:31 +0100 Received: from [206.111.147.149] (vpn-gh-62.apple.com [17.254.136.61]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id RAA27114 for ; Fri, 20 Jul 2001 17:08:16 -0700 (PDT) Message-Id: <200107210008.RAA27114@scv1.apple.com> Subject: draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Fri, 20 Jul 2001 17:08:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk "Dynamic Configuration of IPv4 Link-Local Addresses" has been revised, as a result of Working Group Consensus on the good suggestions received from our Area Director. The new draft has been submitted to the Internet-Drafts directory. It can also be fetched via http from: Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Jul 20 20:08:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22136 for ; Fri, 20 Jul 2001 20:08:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6621A9121D; Fri, 20 Jul 2001 20:08:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3206591220; Fri, 20 Jul 2001 20:08:12 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E49E9121D for ; Fri, 20 Jul 2001 20:08:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F37595DDA8; Fri, 20 Jul 2001 20:09:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 982B65DDA6 for ; Fri, 20 Jul 2001 20:09:59 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id RAA01501 for ; Fri, 20 Jul 2001 17:08:43 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 20 Jul 2001 17:06:55 +0100 Received: from [206.111.147.149] (vpn-gh-62.apple.com [17.254.136.61]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id RAA27169 for ; Fri, 20 Jul 2001 17:08:40 -0700 (PDT) Message-Id: <200107210008.RAA27169@scv1.apple.com> Subject: Comments on zmaap-01.txt Date: Fri, 20 Jul 2001 17:08:37 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk General Comment: I fear we have to 'bite the bullet' and face that because of the shared nature of multicast addresses, we need an atomic "claim and name" operation. That means that claiming and naming have to be the same protocol, in the Zeroconf case. The problem is simply this: A client says, "Join group FOO. Oh, group FOO doesn't exist. Create group FOO." What if two clients do it at the same time? Standard test-and-set race condition. Specific comments on the draft: Pet Peeve: References are supposed to be an addition to written prose, not a substitute for it. References are there so that when an inexperienced reader doesn't understand a statement you make, they know where to look for more information. References are there so that when an *experienced* reader doesn't *agree* with a statement you make, they can find upon what prior work you are basing your questionable assertion. You should be able to delete the references from a piece of text and have it still make sense to an experienced reader. Put another way, the reader shouldn't have to keep flipping to the back of the document to understand what a sentence is saying. There are several places in the draft that fail this test: > This document uses the following terms: > > Multicast > IP Multicast, as defined in [10] and [11]. > > Multicast Address > An IP multicast address or group address, as defined in [10] > and [3]. An identifier for a group of nodes. > > Multicast Scope > A range of multicast addresses configured so that traffic > sent to these addresses is limited to some subset of the > internetwork. See [6] and [3]. Without the list of references to hand, this makes little sense. You can fix this two ways: 1. Delete spurious words: > This document uses the following terms: > > Multicast > IP Multicast [10] [11]. > > Multicast Address > An IP multicast address or group address [3] [10]. > An identifier for a group of nodes. > > Multicast Scope > A range of multicast addresses configured so that traffic > sent to these addresses is limited to some subset of the > internetwork [3] [6]. 2. Write complete prose: > This document uses the following terms: > > Multicast > IP Multicast, as defined in "Host Extensions for IP Multicasting" > [10] and "Internet Protocol, Version 6 (IPv6) Specification" [11]. > > Multicast Address > An IP multicast address or group address, as defined in "IP > Version 6 Addressing Architecture" [3] and "Host Extensions > for IP Multicasting" [10]. An identifier for a group of nodes. > > Multicast Scope > A range of multicast addresses configured so that traffic > sent to these addresses is limited to some subset of the > internetwork. See "IP Version 6 Addressing Architecture" [3] > and "Administratively Scoped IP Multicast" [6]. I also prefer to use semidescriptive references instead of numeric references so an experienced reader can recogise the reference in context, instead of having to flip to the back of the document to find out what "[10]" means: > This document uses the following terms: > > Multicast > IP Multicast [RFC 1112] [RFC 2460]. > > Multicast Address > An IP multicast address or group address [RFC 1112] [RFC 2373]. > An identifier for a group of nodes. > > Multicast Scope > A range of multicast addresses configured so that traffic > sent to these addresses is limited to some subset of the > internetwork [RFC 2365] [RFC 2373]. To give credit where it is due, the draft does also contain some examples of proper use of references: > Servers and network administration staff are not available in all > environments. Home networks and ad-hoc networks, for example, need to > rely entirely on zero-configuration protocols [14]. > Hosts may also use MADCAP [2] for these features. --- More comments: > Home networks and ad-hoc networks, for example, need to > rely entirely on zero-configuration protocols [14]. Hard to defend this statement as written. How about: "Many networks without administrative support need to rely..." > As described in [5], a host provides two main services to its > multicast applications through some API. First, it must allow > applications to enumerate the set of available multicast scopes. This draft talks in several places about "enumerating the set of available multicast scopes", but doesn't begin to discuss how this should be done on a zeroconf network with no servers. I think that needs to be explained. > A mini-MAAS send AIU messages for the addresses that it currently has > allocated, before their allocation lifetime expires. This sounds like periodic messages to me. Not good. I know you want to detect conflicts, but what is a multicast conflict? A multicast conflict is an application getting packets it doesn't want. If no application is getting packets it doesn't want, is there really a conflict? If an application is getting packets it doesn't want, perhaps it should call some routine like "ZMAAP_Resolve_Conflict()" to tell ZMAAP there's a problem. > The mini-MAAS issues this message repeatedly. How many times? What interval? If details are going to be given later, the draft should say so. > To obtain a multicast address allocation, an application requests a > range of addresses > The ZMAAP messages have the following common format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Message Type | Address Family | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lease descriptor 1 (variable) / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lease descriptor N (variable) / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > The lease descriptor for IPv4 addresses has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Initial address in the range | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Final address in the range | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lease Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lease Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft contains no evidence to support the notion that allocating more than one address at a time is worth the extra protocol complexity. I know that people often talk about things like layered codecs, but in practice, how often are they really used? What is the requirement that layered codecs have multicast addresses that are numerically consecutive? What is the mean number of multicast addresses allocated by today's multicast applications? I expect the mean is somewhere between 1 and 2. I generally favour the simplest possible solution to any problem. To convince me otherwise, you would have to show that the overall cost of the more complicated solution is less than the cost of *not* doing the more complicated solution. By allocating numerically consecutive chunks of multicast address space you get fragmentation (just like a memory heap). You might end up in the situation where there are enough addresses available overall for your application in the ZMAAP address range, just not enough in any one consecutive block. Is that a failure? > Value Address Family > ----- -------------- > 1 IPv4 > 2 IPv6 I think you should reference the namespace you're using here (you're not inventing a new namespace). > The Lease Identifier is used to distinguish allocations of the same > address range made by different mini-MAASs. It is assigned by the > allocator mini-MAAS, using an implementation dependent method. For > example, it can be computed as a hash of the allocator's address and > the allocation time (and UDP transmission port in case more than one > mini-MAAS resides on the same host). If Lease Identifiers need to be unique, you should wpecify the algorithm, not say "implementation dependent". If the algorithm is implementation-dependent, then uniqueness is not assured. (One Mac OS API specified that applications provide a unique identifier, e.g. their process ID, or their assigned creator code, or the base address of their heap in shared memory, etc. Any one of these alone would have worked, because each is a unique namespace, but by forcing the developer to choose which namespace to use, you get collisions when application A uses its heap address and application B uses its assigned creator code, and just by chance they happen to be the same binary value.) Also, "The Lease Identifier is used to distinguish *unrelated* allocations of the same address range." If two applications are coordinating to share a multicast address, then that's not a conflict, and they would use the same Lease Identifier, right, even though two different mini-MAASs are involved? > If a mini-MAAS receives an ACLM with the same Lease Identifier as an > allocation in its allocation record, it MUST respond with an AIU > message, immediately. This AIU message MUST contain the Lease > Descriptor present in the allocation record. Why? If the Lease Identifier is the same, doesn't that indicate a non-conflict? > Care must be taken to ensure that the range of addresses specified in > the AIU does not overlap the range of any other allocation in the > allocation record. If it does, this is an allocation conflict and > the mini-MAAS MUST send an AIU containing the Lease Descriptor of the > allocation with which the ACLM is in conflict. A mini-MAASs sends an AIU to advertise the addresses it's using. How can one range of addresses it's using be in conflict with another range of addresses it's using? > If any ranges in the AIU message overlap with recorded allocations > but the lease descriptors do not match (different address ranges or > lease identifier), then an allocation conflict exists. The mini-MAAS > MUST remove the allocation from its allocation record. The mini-MAAS > will inform any local applications registered for the canceled > allocation, if it has implemented this functionality (see Appendix > A). Is there no tie-breaker here so that one allocation can remain undisturbed? >6. Security Considerations > > In the interest of simplicity, this draft does not prescribe a means > of securing the multicast auto-configuration mechanism. Thus it is > possible that hosts will allocate conflicting multicast addresses for > a period of time, or that non-conforming hosts will attempt to deny > service to other hosts by allocating the same multicast addresses. I don't think this will fly. Zeroconf Requirements says, "Zeroconf protocols MUST NOT be any less secure than related current IETF-Standard protocols." For link-only IPv4-only protocols, this means they *may* be no more secure than ARP. Multicast crosses routers, so this special dispensation does not apply. Or is ZMAAP *only* for allocating link-local multicast addresses? >Appendix B Session Management Implications > [...] > An application which receives a session announcement with this > attribute may use it to form a Lease Descriptor and request the ZMAAP > API to either defend the allocation or for notification if there is > an address allocation conflict. See Appendix B. Appendix B says, "See Appendix B"? > [14] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf- > reqts-06.txt, November 2000. Work in progress. Should be draft-08. > [15] Cheshire, S., "Dynamic Configuration of IPv4 link-local > addresses", draft-ietf-zeroconf-ipv4-linklocal-01.txt, November > 2000. Work in progress. Should be draft-04. --- That's it for now. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Jul 21 03:54:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21356 for ; Sat, 21 Jul 2001 03:54:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DE229122A; Sat, 21 Jul 2001 03:54:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DD079122B; Sat, 21 Jul 2001 03:54:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15D1B9122A for ; Sat, 21 Jul 2001 03:54:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FEA75DDB0; Sat, 21 Jul 2001 03:56:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EB8E55DDAB for ; Sat, 21 Jul 2001 03:56:04 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12224; Sat, 21 Jul 2001 01:54:45 -0600 (MDT) Received: from vayne (muc-isdn-4 [129.157.164.104]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id JAA11647; Sat, 21 Jul 2001 09:54:44 +0200 (MET DST) Date: Sat, 21 Jul 2001 10:06:49 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Comments on zmaap-01.txt To: Stuart Cheshire , dthaler@microsoft.com Cc: zeroconf@merit.edu In-Reply-To: "Your message with ID" <200107210008.RAA27169@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, I respond to your substantive points. > General Comment: I fear we have to 'bite the bullet' and face that > because of the shared nature of multicast addresses, we need an atomic > "claim and name" operation. That means that claiming and naming have to > be the same protocol I suggested the same - basicly carry SDP in ZMAAP. Dave Thaler emphatically rejected this: Keep session discovery and address allocation separate, he said. Having never written such software nor deployed it, I defer to him. Dave? > > As described in [5], a host provides two main services to its > > multicast applications through some API. First, it must allow > > applications to enumerate the set of available multicast scopes. > > This draft talks in several places about "enumerating the set of > available multicast scopes", but doesn't begin to discuss how this should > be done on a zeroconf network with no servers. I think that needs to be > explained. This simply means that a zmaap support api has to enumerate the scopes the underlying implementation can allocate addresses in. > > A mini-MAAS send AIU messages for the addresses that it currently has > > allocated, before their allocation lifetime expires. > > This sounds like periodic messages to me. Not good. I know you want to > detect conflicts, but what is a multicast conflict? A multicast conflict > is an application getting packets it doesn't want. If no application is > getting packets it doesn't want, is there really a conflict? If an > application is getting packets it doesn't want, perhaps it should call > some routine like "ZMAAP_Resolve_Conflict()" to tell ZMAAP there's a > problem. The idea is that zeroconf protocols do not require rewrites of existing applications. Your suggestion would require rewriting multicast applications. The ZMAAP API could be evoked before a MC app, even by a separate utility which supplied the allocated address as initialization parameters. > > The mini-MAAS issues this message repeatedly. > > How many times? What interval? If details are going to be given later, > the draft should say so. Agreed. > The draft contains no evidence to support the notion that allocating more > than one address at a time is worth the extra protocol complexity. This is the api support required, specified by RFC 2771 and RFC 2908. > By allocating numerically consecutive chunks of multicast address space > you get fragmentation (just like a memory heap). You might end up in the > situation where there are enough addresses available overall for your > application in the ZMAAP address range, just not enough in any one > consecutive block. Is that a failure? Yes, it is a failure, as per RFC 2771. RFC 2730 and AAP work this way. > > Value Address Family > > ----- -------------- > > 1 IPv4 > > 2 IPv6 > > I think you should reference the namespace you're using here (you're not > inventing a new namespace). This is done in the preceding parapraph where we cite [12], which points to http://www.isi.edu/in-notes/iana/assignments/address-family-numbers > > The Lease Identifier is used to distinguish allocations of the same > > address range made by different mini-MAASs. It is assigned by the > > allocator mini-MAAS, using an implementation dependent method. For > > example, it can be computed as a hash of the allocator's address and > > the allocation time (and UDP transmission port in case more than one > > mini-MAAS resides on the same host). > > If Lease Identifiers need to be unique, you should wpecify the algorithm, > not say "implementation dependent" OK. Could you suggest something? > Also, "The Lease Identifier is used to distinguish *unrelated* > allocations of the same address range." If two applications are > coordinating to share a multicast address, then that's not a conflict, > and they would use the same Lease Identifier, right, even though two > different mini-MAASs are involved? Right. > > If a mini-MAAS receives an ACLM with the same Lease Identifier as an > > allocation in its allocation record, it MUST respond with an AIU > > message, immediately. This AIU message MUST contain the Lease > > Descriptor present in the allocation record. > > Why? If the Lease Identifier is the same, doesn't that indicate a > non-conflict? Yes, this is a non-conflict. But it is important in some cases to be able to verify a lease is supported. That's what Section 4.4.3 talks about. > > Care must be taken to ensure that the range of addresses specified in > > the AIU does not overlap the range of any other allocation in the > > allocation record. If it does, this is an allocation conflict and > > the mini-MAAS MUST send an AIU containing the Lease Descriptor of the > > allocation with which the ACLM is in conflict. > > A mini-MAASs sends an AIU to advertise the addresses it's using. How can > one range of addresses it's using be in conflict with another range of > addresses it's using? Allocation record entries include also cached allocations of other mini-MAASs. > > If any ranges in the AIU message overlap with recorded allocations > > but the lease descriptors do not match (different address ranges or > > lease identifier), then an allocation conflict exists. The mini-MAAS > > MUST remove the allocation from its allocation record. The mini-MAAS > > will inform any local applications registered for the canceled > > allocation, if it has implemented this functionality (see Appendix > > A). > > Is there no tie-breaker here so that one allocation can remain > undisturbed? Not currently. Got any suggestions? > >6. Security Considerations > > > > In the interest of simplicity, this draft does not prescribe a means > > of securing the multicast auto-configuration mechanism. Thus it is > > possible that hosts will allocate conflicting multicast addresses for > > a period of time, or that non-conforming hosts will attempt to deny > > service to other hosts by allocating the same multicast addresses. > > I don't think this will fly. Zeroconf Requirements says, "Zeroconf > protocols MUST NOT be any less secure than related current IETF-Standard > protocols." For link-only IPv4-only protocols, this means they *may* be > no more secure than ARP. Multicast crosses routers, so this special > dispensation does not apply. Or is ZMAAP *only* for allocating link-local > multicast addresses? You're right. We already support LL, subnet-local and prefix-based MC address allocation. This needs work. Any suggestions? > >Appendix B Session Management Implications > > [...] > > An application which receives a session announcement with this > > attribute may use it to form a Lease Descriptor and request the ZMAAP > > API to either defend the allocation or for notification if there is > > an address allocation conflict. See Appendix B. Should say 'see draft-ietf-zeroconf-zmaap-api-00.txt.' Erik From owner-zeroconf@merit.edu Sun Jul 22 23:20:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18503 for ; Sun, 22 Jul 2001 23:20:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB30A9122D; Sun, 22 Jul 2001 23:20:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A72E891233; Sun, 22 Jul 2001 23:20:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B20F9122D for ; Sun, 22 Jul 2001 23:20:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF5325DDD1; Sun, 22 Jul 2001 23:22:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 545545DDA7 for ; Sun, 22 Jul 2001 23:22:47 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id UAA18175; Sun, 22 Jul 2001 20:21:18 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id UAA23304; Sun, 22 Jul 2001 20:21:15 -0700 (MST)] Received: from email.mot.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6N3L6s01975; Mon, 23 Jul 2001 13:21:06 +1000 (EST) Message-ID: <3B5B9822.446957C0@email.mot.com> Date: Mon, 23 Jul 2001 13:21:06 +1000 From: Aidan Williams Reply-To: Aidan.Williams@motorola.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman Cc: Thomas Narten , zeroconf@merit.edu, cheshire@apple.com, Erik Nordmark Subject: Re: summary of discussion on draft-ietf-zeroconf-reqts-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, I've trimmed out everything that isn't an "Open" issue. Erik Guttman wrote: > --------------------------------------------------------------------- > 08.01. New title > > "Thomas Narten" wrote: > > How about a more descriptive title than "zeroconf requirements" > > Suggestion: Zeroconf IP Host Requirements > > This makes it clear that we are discussing hosts not > routers. > > Action: Open > I'm happy with this title. Three of the remaining Open issues relate to this, and benifit from a tighter focus. > --------------------------------------------------------------------- > 08.07 open ended text > > "Thomas Narten" wrote: > > > Requirement: > > > - MUST respond to state changes and resolve conflicts in a timely > > > manner. > > > > Note that his is really open ended, so I don't really know what "MUST" > > means specifically. What conflicts need to be resolved? Indeed, what > > is a "conflict"? My suspicion is that having a MUST here in a generic > > sense is not appropriate. What you want is a MUST in specific > > sitations that it is felt should or should not happen.t > > Suggestion: Spell this out for each protocol area: > > address autoconfiguration - detect and eliminate duplicate addresses. > name resolution - allow resolution of names which could not > previously be resolved. In particular, if a host wishes to > resolve its own name to determine if it is unique, it will > be able to detect this conflict and resolve it in a timely > manner. > service discovery - allow discovery of previously undiscovered > services. > multicast address allocation protocol - detect and eliminate duplicate > addresses. > > Action: Open What is happening to the MUSTs and SHOULDs here? Even though I would be comfortable with MUSTs for the first three, it seems like we could get away with a SHOULD for the last one (multicast). In general though a SHOULD ought to suffice, and the specific protocols (e.g. IPv4LL) can specify the MUST behaviour where it makes sense. I'm wary of pulling up detailed protocol requirements into this document, although I do think those above are useful and sensible examples. A different way of stating the requirement is that all protocols MUST be able to cope with the merging of two zeroconf networks. I think that the adding and removal of *hosts* isn't the important thing, nor is topological change in the network. The real issues arise from merging two islands which have each successfully engaged in a zeroconf protocol to produce consistent addresses/names/whatever. The act of merging potentially destroys the consistency that the protocol has worked to build, and the protocol must be able to cope with this. > --------------------------------------------------------------------- > 08.09 scoping > > "Thomas Narten" wrote: > > > - MUST have unique IP subnets within an internetwork > > > (only for the internetwork scenario). > > > > Do you need to scope this more? I.e., can't an "internetwork" consist > > of the entire Internet (per the earlier definition?) > > Aidan William replied: > > Perhaps "internetwork" should be a "zeroconf internetwork" in this > > section, where a "zeroconf internetwork" is the bunch of subnets > > connected to exactly one router. > > Erik Guttman wrote: > > The text above is sufficiently general that it leaves room for multiple > > router zeroconf interface autoconfiguration to be standardized in the > > future. > > > > We did not preclude multiple routers from our charter because we thought > > it was a bad idea. Rather, we did not think we could standardize > > multi-router zeroconf protocols in a timely manner. The requirements > > document does not need to echo our charter humility, restricting future > > (perhaps immanent) standardization efforts. > > Suggestion: clarify that this is currently only specified on a > single link or a network with routers whose configuration > is out of scope for this spec. > > Action: Open I'm happy with a pragmatic focus on a single link. I thought the title Erik suggested went a long way in this direction: > Suggestion: Zeroconf IP Host Requirements > This makes it clear that we are discussing hosts not > routers. Routers presumably configure themselves as "hosts" for the purposes of zeroconf protocols covered by this spec. > --------------------------------------------------------------------- > 08.11 resolve conflicts - should be more specific > > "Thomas Narten" wrote: > > > Requirement: > > > - MUST resolve conflicts and state changes in a timely manner. > > > > Can the document be more specific and say just what conflicts need to > > be resolved? Or is the assumption that the previously discussed issues > > is what needs to be addressed? > > Aidan.Williams@motorola.com wrote: > > I read this as referring to section 2.1.1, where there are a set of > > uniqueness requirements, etc. Maybe it could do so explicitly. > > For me, this requirement adds an on-going consistency requirement for > > everything in 2.1.1. > > Suggestion: Isn't this addressed by 08.07 above? > > Action: Open Yes, probably. Same comment about coping with merging. > --------------------------------------------------------------------- > 08.12 IPv6 considerations for interface configuration > > "Thomas Narten" wrote: > > > 2.1.3 IPv6 Considerations > > > > > > IPv6 allows a host to select an appropriate IP address, netmask, > > > and routing information, thus if a host is using IPv6, a zeroconf > > > IP interface configuration solution already exists. > > > > > > Is this fully correct? Do routers automatically (without user > > configuration) advertise themselves as default routers? > > > > Indeed, I'm a bit confused about whether this document assumes > > multiple subnets are present. It seems to, but I thought the WG > > decided that a single router was assumed. It would be good to state up > > front what the assumptions are for the enivironment zeroconf is > > operating in. Will there be just one router? Or multiple routers? Or > > no routers? > > Suggestion: We have to support 0 routers. We can support 1+ router. > Folks want to consider how 1 router can be auto configuring, but > this is tangential to the requirements in this document. > We have nothing to say about how routers are configured. Let's > make it clear the ZC requirements concern only host configuration > not router configuration. > > Action: Open I'm happy with that. Zeroconf router configuration is future work. Mini-dhcp is to my way of thinking not strictly zeroconf. > --------------------------------------------------------------------- > 08.14 unclear requirement > > "Thomas Narten" wrote: > > > 2.3.1 Scope Enumeration > > > > > > Applications that leave the choice of scope up to the user require > > > the ability to enumerate what scopes the host is operating within. > > > In addition, services that are assigned relative addresses require > > > the ability to enumerate what scopes the host is within; only then > > > will a host be able to apply the relative address to a scope. > > > > > > Requirements: > > > - MUST list which of the scopes (local, link-local, or site-local) > > > are available for hosts. > > > - MUST list per-scope address ranges that may be allocated. > > > > I'm not clear what the requirement above is. That is, *who* is > > responsbile for the MUST? The application? How is the application > > supposed to determine this? Is the point that this information must > > somehow be determinable? (General comment: This may all be an artifact > > from the fact that the Requirements bullets are not using full > > sentences.) > [snip] > Erik Guttman wrote: > > ZMAAP only works in a subset of the scopes listed above (link-local, > > unicast-prefix based and subnet-local). The ZMAAP API exposes this > > list to applications. A future version of ZMAAP capable of interoperation > > with MADCAP servers could support local, site-local or other scopes > > as well. > > Suggestion: > MUST -> Application support software used to autoconfigure > multicast addresses MUST > > Action: Open Looks fine to me. > --------------------------------------------------------------------- > 08.17 explain security requirements text better, for IPv4 > > "Thomas Narten" wrote: > > > > > The IPv4 interface configuration protocol MAY omit security > > > mechanisms if and only if that protocol is not used for IPv6 and > > > cannot be extended to support IPv6. It is strongly recommended that > > > it include security mechanisms, because many protocols are extended > > > later in ways not anticipated by the original developer(s). > > > > Explain > > This tangled formation came from (a) simple text from me saying > since ARP is insecure, IPv4 autoconf MAY be too, (b) Ran noting that > IPv6 may be implemented over IPv4 so more care would be needed in > the formulation and (c) Stuart's polishing the text for clarity > while trying to preserve as much as possible so as to not force > a new last call (which happened anyway). > > What it means is: > > IPv4 autoconf MAY be insecure to configure IPv4 interface parameters > (as ARP is insecure). > > If the IPv4 autoconf mechanism is used to support IPv6, it had better > be secured (at some level - say the IPv6 in IPv4 packets may include > IPsec AH for the ND messages). > > Ran wanted to make sure that even though we may omit security (we > do in IPv4 LL autoconf) there's some text indicating its a Bad Thing. > > Suggestion: Leave it alone. > > Action: Open Perhaps we could use your expanded text on what the paragraph meant? Can we include an example given for IPv6 over IPv4 which highlighted the issue? Of the v6 over v4 mechanisms I am aware of: - some are IPv6 tunneled in unicast IPv4 packets (e.g. 6to4) - one uses IPv4 multicast as a link layer for IPv6 (6over4). I cannot see how a tunneling scheme over unicast IPv4 could avoid being being vulnerable to ARP attacks (DoS in particular), and an example would clear that up. 6over4 is less problematic from a security point of view because it does not need to solicit a destination mac address using ARP (all frames are sent to multicast destinations, and the address is computed by hashing the v6 destination address). Reducing our scope to one link could avoid the need to talk about things like 6to4 entirely. regards aidan ____ :wq! From owner-zeroconf@merit.edu Mon Jul 23 05:02:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07747 for ; Mon, 23 Jul 2001 05:02:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 029199121E; Mon, 23 Jul 2001 05:02:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B04F091234; Mon, 23 Jul 2001 05:02:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91B259121E for ; Mon, 23 Jul 2001 05:02:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFF195DDA7; Mon, 23 Jul 2001 05:04:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 46D0F5DD9B for ; Mon, 23 Jul 2001 05:04:40 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13169; Mon, 23 Jul 2001 03:03:13 -0600 (MDT) Received: from vayne (muc-isdn-6 [129.157.164.106]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA10794; Mon, 23 Jul 2001 11:03:11 +0200 (MET DST) Date: Mon, 23 Jul 2001 09:15:04 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Open issue 08.07: reqts-08 discussion To: Aidan.Williams@motorola.com Cc: Erik Guttman , Thomas Narten , zeroconf@merit.edu, cheshire@apple.com In-Reply-To: "Your message with ID" <3B5B9822.446957C0@email.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Aidan, > > --------------------------------------------------------------------- > > 08.07 open ended text > > > > "Thomas Narten" wrote: > > > > Requirement: > > > > - MUST respond to state changes and resolve conflicts in a timely > > > > manner. > > > > > > Note that his is really open ended, so I don't really know what "MUST" > > > means specifically. What conflicts need to be resolved? Indeed, what > > > is a "conflict"? My suspicion is that having a MUST here in a generic > > > sense is not appropriate. What you want is a MUST in specific > > > sitations that it is felt should or should not happen.t > > > > Suggestion: Spell this out for each protocol area: > > > > address autoconfiguration - detect and eliminate duplicate addresses. > > name resolution - allow resolution of names which could not > > previously be resolved. In particular, if a host wishes to > > resolve its own name to determine if it is unique, it will > > be able to detect this conflict and resolve it in a timely > > manner. > > service discovery - allow discovery of previously undiscovered > > services. > > multicast address allocation protocol - detect and eliminate duplicate > > addresses. > > > > Action: Open > > What is happening to the MUSTs and SHOULDs here? Even though I would > be comfortable with MUSTs for the first three, it seems like we could > get away with a SHOULD for the last one (multicast). I agree. One thing we don't consider here or in the ZMAAP spec is the consequence of a multicast address conflict. If two applications use the same MC address at different port #s, there's non-optimal use of the network (if the MC scope is greater than 1) and the link layer (the other app's datagram is filtered at the network instead of by the NIC). But this will not lead to the *failure* of either application. > In general though a SHOULD ought to suffice, and the specific protocols > (e.g. IPv4LL) can specify the MUST behaviour where it makes sense. > I'm wary of pulling up detailed protocol requirements into this > document, although I do think those above are useful and sensible examples. > > A different way of stating the requirement is that all protocols MUST > be able to cope with the merging of two zeroconf networks. I think > that the adding and removal of *hosts* isn't the important thing, nor > is topological change in the network. The real issues arise from > merging two islands which have each successfully engaged in a zeroconf > protocol to produce consistent addresses/names/whatever. The act of > merging potentially destroys the consistency that the protocol has > worked to build, and the protocol must be able to cope with this. I agree this is the issue - which is the point of the section from which this text comes. The problem, as Thomas pointed out, is that it is not specific in what the MUST implies. The real question before us is - does this section need more text? Should we list what the undesirable conflicts are which must be resolved in the case of each protocol area? Erik From owner-zeroconf@merit.edu Mon Jul 23 21:39:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07595 for ; Mon, 23 Jul 2001 21:39:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 937659123C; Mon, 23 Jul 2001 21:40:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 616BA91254; Mon, 23 Jul 2001 21:40:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B5B79123C for ; Mon, 23 Jul 2001 21:40:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 085CE5DD9F; Mon, 23 Jul 2001 21:42:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 2E4495DD9D for ; Mon, 23 Jul 2001 21:41:59 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id SAA21262; Mon, 23 Jul 2001 18:40:38 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id SAA15008; Mon, 23 Jul 2001 18:40:33 -0700 (MST)] Received: from email.mot.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6O1ePs25762; Tue, 24 Jul 2001 11:40:26 +1000 (EST) Message-ID: <3B5CD209.3C6345C9@email.mot.com> Date: Tue, 24 Jul 2001 11:40:25 +1000 From: Aidan Williams Reply-To: Aidan.Williams@motorola.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman Cc: Thomas Narten , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Open issue 08.07: reqts-08 discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik Guttman wrote: > I agree this is the issue - which is the point of the section from > which this text comes. The problem, as Thomas pointed out, is that > it is not specific in what the MUST implies. > > The real question before us is - does this section need more text? > Should we list what the undesirable conflicts are which must be > resolved in the case of each protocol area? > I think it could be clearer, perhaps as follows (which is a combination of more focus on merging, and your suggestions per-protocol). regards aidan ____ :wq! 1.6 Conflicts and State Changes Requirement Zeroconf protocols are designed to consistently manage network resources (e.g. unicast and multicast addresses, host names). Consistency must be maintained when new hosts and networks are added or removed. In addition, consistency must be restored when two independant zeroconf networks are connected together, as illustrated in Section 2.1.2 Bridge Installed. Requirements: - Zeroconf protocols MUST detect inconsistencies in a timely manner. - Zeroconf protocols MUST restore consistency in a timely manner. These result in the following requirements for each protocol area: Address autoconfiguration MUST detect and eliminate duplicate addresses. Name resolution MUST allow resolution of names which could not previously be resolved. In particular, if a host wishes to resolve its own name to determine if it is unique, it will be able to detect this conflict and resolve it in a timely manner. Service discovery MUST allow discovery of previously undiscovered services. Multicast address allocation protocol SHOULD detect and eliminate duplicate addresses. From owner-zeroconf@merit.edu Tue Jul 24 02:44:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02323 for ; Tue, 24 Jul 2001 02:44:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A32CE91259; Tue, 24 Jul 2001 02:32:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62DA39125A; Tue, 24 Jul 2001 02:32:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ECB1691259 for ; Tue, 24 Jul 2001 02:32:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE86A5DD9D; Tue, 24 Jul 2001 02:34:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by segue.merit.edu (Postfix) with ESMTP id 3055F5DD93 for ; Tue, 24 Jul 2001 02:34:08 -0400 (EDT) Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id IAA12385 for ; Tue, 24 Jul 2001 08:32:47 +0200 (MEST) (envelope-from peter.van.der.stok@philips.com) From: peter.van.der.stok@philips.com Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl4.philips.com via mwrap (4.0a) id xma012383; Tue, 24 Jul 01 08:32:47 +0200 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA13649 for ; Tue, 24 Jul 2001 08:32:44 +0200 (MET DST) Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA26196 for ; Tue, 24 Jul 2001 08:32:44 +0200 (MET DST) Received: from EHAUO01.diamond.philips.com (ehauo01sv1.diamond.philips.com [130.139.54.215]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA00540 for ; Tue, 24 Jul 2001 08:31:58 +0200 (MET DST) Subject: zeroconf issues To: zeroconf@merit.edu Date: Tue, 24 Jul 2001 08:29:06 +0200 Message-ID: X-MIMETrack: Serialize by Router on EHAUO01/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 24/07/2001 08:53:22 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256A9300237C048f9e8a93df938690918cC1256A9300237C04" Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk --0__=C1256A9300237C048f9e8a93df938690918cC1256A9300237C04 Content-type: text/plain; charset=us-ascii Dear all, Attached you will find an internet draft that serves as input for a discussion on the ZeroConf charter to be held during the IETF meeting in August. Unfortunately, I was too late for posting it as a draft because of forced holidays and removal from one buidling to another. Peter (See attached file: issues.txt) Peter van der Stok Philips Research Laboratories Eindhoven Bldg: WL P 311 Prof. Holstlaan 4 Phone: +31 40 2742649 5656 AA Eindhoven Fax: +31 40 274 The Netherlands Mailto: Peter.van.der.Stok@ philips.com --0__=C1256A9300237C048f9e8a93df938690918cC1256A9300237C04 Content-type: text/plain; name="issues.txt" Content-Transfer-Encoding: base64 CgpJbnRlcm5ldCBFZ2luZWVyaW5nIFRhc2sgZm9yY2UgICAgICAgICAgICAgICAgICAgICAgICBQ ZXRlciB2YW4gZGVyIFN0b2sKSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBQaGlsaXBzIFJlc2VhcmNoCjYgSnVseSAyMDAxCkV4cGlyZXMgaW4g NiBtb250aHMKCiAgICAgICAgICAgICAgICAgICBJc3N1ZXMgZm9yIFplcm9Db25mIFdvcmtpbmcg Z3JvdXAKICAgICAgICAgICAgICAgIGRyYWZ0LXZhbmRlcnN0b2stemVyb2NvbmYtaXNzdWVzLTAw LnR4dAoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBkb2N1bWVudCBpcyBhbiBpbmRpdmlk dWFsIGNvbnRyaWJ1dGlvbiB0byB0aGUgSW50ZXJuZXQKICAgRW5naW5lZXJpbmcgVGFzayBGb3Jj ZSAoSUVURikuICBDb21tZW50cyBzaG91bGQgYmUgc3VibWl0dGVkIHRvIHRoZQogICBzcnZsb2NA c3J2bG9jLm9yZyBtYWlsaW5nIGxpc3QuCgogICBEaXN0cmlidXRpb24gb2YgdGhpcyBtZW1vIGlz IHVubGltaXRlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlz IGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aAogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEw IG9mIFJGQzIwMjYuICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcKICAgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLAog ICBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4KCiAg IEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0 ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBv ZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0CgogICBUaGUgbGlzdCBvZiBJbnRlcm5l dC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgoKICAgVGFibGUgb2YgQ29udGVudHMKCiAgIDEuIElu dHJvZHVjdGlvbi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyCiAgIDIuIE5hbWluZy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyCiAgIDMuIFdpcmVsZXNzIG5ldHdvcmtzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgIDQuIFNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgIDUu IFJlZmVyZW5jZXMuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA0CiAgIDYuIEF1dGhvcidzIGFkZHJlc3MuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgIDcuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1CgoKQWJzdHJhY3QgVGhpcyBu b3RlIGNvbnNpZGVycyBzb21lIGlzc3VlcyBmb3J0aGNvbWluZyBmcm9tIGluLWhvbWUKICAgbmV0 d29ya3MgdGhhdCB1c2UgdGhlIFplcm9Db25maWd1cmF0aW9uIHByb3RvY29scyBhcyBuZXR3b3Jr IGxheWVyLgoKCgoKCgoKdmFuIGRlciBTdG9rLCBQZXRlciAgICAgRXhwaXJlczogMjMgSmFudWFy eSAyMDAyICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQgRHJhZnQgICAgICAgICAg ICAgIFplcm9Db25mIGlzc3VlcyAgICAgICAgICAgICAgICAgICBKdWx5IDIwMDEKCgoxLiBJbnRy b2R1Y3Rpb24KCiAgIFRoZSBaZXJvY29uZiByZXF1aXJlbWVudHMgW0lEWlJdIGFuZCB0aGUgbGlu ay1sb2NhbCBwcm90b2NvbCBbSURMTF0KICAgYXJlIGEgZ29vZCBiYXNpcyBmb3IgdGhlIGFsbG9j YXRpb24gb2YgbmV0d29yayBhZGRyZXNzZXMgdG8gdGhlIGhvc3RzCiAgIGluIGEgaG9tZSBuZXR3 b3JrLiAgQm90aCBkb2N1bWVudHMgY29uc2lkZXIgbmV0d29ya3Mgd2hlcmUgbm8KICAgbWFuYWdl bWVudCBieSB0aGUgdXNlciBpcyBuZWVkZWQuIFRoZSBuZXR3b3JrIGNhbiByYW5nZSBmcm9tIGFu IGFkLQogICBob2MgbmV0d29yayBvZiB0d28gaG9zdHMgdG8gYSBsYXJnZXIgc3RhbmQtYWxvbmUg bmV0d29yayBjb21wcmlzaW5nCiAgIHNldmVyYWwgYnJpZGdlZCBuZXR3b3JrcyB3aXRob3V0IERI Q1Agc2VydmVyIFtSRkMyMTMxXSB0byBhIG5ldHdvcmsKICAgY29ubmVjdGVkIHRvIHRoZSBpbnRl cm5ldCB3aXRoIGFkbWluaXN0cmF0aW9uIGJ5IGEgREhDUCBzZXJ2ZXIuIFRoZQogICBESENQIHNl cnZlciBpcyBwb3NzaWJseSBjb25maWd1cmVkIGJ5IHRoZSBpbnRlcm5ldCBzZXJ2aWNlcyBwcm92 aWRlcgogICB3aXRob3V0IGludGVydmVudGlvbiBieSB0aGUgb3duZXIgb3IgdXNlciBvZiB0aGUg aG9tZSBuZXR3b3JrLgoKICAgVGhpcyBub3RlIGNvbnNpZGVycyBhIHplcm8gY29uZmlndXJhdGlv biBuZXR3b3JrIGZvciB0aGUgaG9tZS4gQQogICBudW1iZXIgb2YgY29uc3VtZXIgZWxlY3Ryb25p YyBhcHBsaWFuY2VzIGFyZSBpbnRlcmNvbm5lY3RlZCwgcG9zc2libHkKICAgYWxzbyBjb25uZWN0 ZWQgdG8gb25lIG9yIG1vcmUgZ2VuZXJhbCBwdXJwb3NlIGNvbXB1dGVycy4gVHdvIHNwZWNpZmlj CiAgIGFzcGVjdHMgb2YgdGhlc2UgbmV0d29ya3MgaGF2ZSBjb25zZXF1ZW5jZXMgZm9yIHRoZSBa ZXJvQ29uZiB3b3JraW5nCiAgIGdyb3VwOiAoMSkgbmFtaW5nIG9mIGFwcGxpYW5jZXMgYW5kICgy KSByb2FtaW5nIG9mIGFwcGxpYW5jZXMgaW4KICAgd2lyZWxlc3MgbmV0d29ya3MuCgoyLiBOYW1p bmcKCiAgIFVzZXJzIG9mIHRoZSBuZXR3b3JrIHdpbGwgbGlrZSB0byBuYW1lIHRoZWlyIGFwcGxp YW5jZXMgKGUuZy4gTXlUViBvcgogICB0dW5lci5pbi50aGUuYmVkcm9vbSkgdG8gYWRkcmVzcyB0 aGVtIGJ5IG5hbWUgZm9yIHRoZSBleGVjdXRpb24gb2YKICAgY29tbWFuZHMgb3IgdGhlIGV4Y2hh bmdlIG9mIEF1ZGlvL1ZpZGVvIChBL1YpIHN0cmVhbXMuIFRyYWRpdGlvbmFsbHksCiAgIERvbWFp biBOYW1lIFN5c3RlbSAoRE5TKSBbUkZDIDEwMzRdW1JGQyAxMDM1XSBzdG9yZXMgdGhlc2UgbmFt ZXMsCiAgIGFzc29jaWF0ZXMgYSBuYW1lIHdpdGggYW4gSVAgYWRkcmVzcyBhbmQgcmV0dXJucyBh biBJUCBhZGRyZXNzIGZvciBhCiAgIGdpdmVuIG5hbWUuIEEgbXVsdGljYXN0IEROUyBbSURtRE5T XSBpcyBmb3Jlc2VlbiBmb3Igc21hbGwgaG9tZQogICBuZXR3b3JrcyB0byBvcGVyYXRlIHdpdGhv dXQgYSBETlMgc2VydmVyLiBJbiB0aGUgRE5TIHByb3RvY29sIGl0IGlzCiAgIGZvcmVzZWVuIHRo YXQKCiAgIC0gZG9tYWluIG5hbWVzIGFyZSBwcm92aWRlZCwgcG9zc2libHkgc3RydWN0dXJlZCBh bmQgYXNzb2NpYXRlZCB3aXRoIGEgem9uZSwKICAgLSBhIHNwZWNpZmllZCBzZXJ2ZXIgaXMgYXV0 aG9yYXRpdmUgZm9yIGEgc2V0IG9mIHpvbmVzLgoKICAgVGhlIHByb3RvY29sIGZvcmVzZWVzIGR5 bmFtaWMgdXBkYXRlcyBvZiB0aGUgZW50cmllcyBpbiB0aGUgc2VydmVyIGJ5CiAgIGF1dGhvcmlz ZWQgc291cmNlcyBbUkZDIDIxMzZdW1JGQyAzMDA3XS4gVGhpcyBzZWN0aW9uIGNvbnNpZGVycyB0 aGUKICAgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgbWFuYWdlbWVudCBvZiB0aGUgbmFtZSBz ZXJ2ZXIocykuCgogICBBIGhvbWUgbmV0d29yayBjYW4gYmUgaW4gdHdvIHBvc3NpYmxlIHN0YXRl czoKICAgKDEpIHN0YW5kIGFsb25lIHdpdGggbm8gY29ubmVjdGlvbiB0byBpbnRlcm5ldAogICAo MikgY29ubmVjdGVkIHRvIHRoZSBpbnRlcm5ldAoKICAgQSBjb25uZWN0aW9uIHRvIHRoZSBpbnRl cm5ldCBjYW4gYmUgcHJvdmlkZWQgdGhyb3VnaCBhIHJlc2lkZW50aWFsCiAgIGdhdGV3YXkgdmlh IGEgY2FibGUgbmV0d29yayBvciB2aWEgdGhlIHRlbGVwaG9uZSBjb25uZWN0ZWQgdG8gYW4KICAg SW50ZXJuZXQgcHJvdmlkZXIuICBJbiB0aGUgZmlyc3QgY2FzZSBhIERIQ1Agc2VydmVyIG1heSBi ZSBwcmVzZW50CiAgIGFuZCBpbiB0aGUgc2Vjb25kIGNhc2UgYSBESENQIHNlcnZlciBpcyBwcmVz ZW50LiBBIGhvbWUgbmV0d29yayBtYXkKICAgcGFzcyBmcm9tIHN0YXRlIDEgd2l0aG91dCBESENQ IHNlcnZlciB0byBzdGF0ZSAyIHdpdGggREhDUCBzZXJ2ZXIKICAgYmVjYXVzZSB0aGUgdXNlciBz dGFydHMgYSBjb25uZWN0aW9uIHdpdGggSW50ZXJuZXQgZnJvbSBvbmUgb2YgdGhlCiAgIGNvbm5l Y3RlZCBhcHBsaWFuY2VzLgoKICAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHF1ZXN0aW9ucyB0aGF0 IG5lZWQgdG8gYmUgY29uc2lkZXJlZCBpbiB0aGUKICAgY2FzZSBvZiBhIHN0YW5kIGFsb25lIGhv bWUgbmV0d29yayB3aXRob3V0IERIQ1Agc2VydmVyLiBBIGJvdW5kYXJ5CgoKdmFuIGRlciBTdG9r LCBQZXRlciAgICAgRXhwaXJlczogMjMgSmFudWFyeSAyMDAyICAgICAgICAgICAgICAgIFtQYWdl IDJdCgwKSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgIFplcm9Db25mIGlzc3VlcyAgICAgICAg ICAgICAgICAgICBKdWx5IDIwMDEKCgogICBjb25kaXRpb24gaXMgdGhhdCB1c2VycyBzaG91bGQg bm90IGJlIGJvdGhlcmVkIHRvIHNwZWNpZnkgYSBzZXJ2ZXIgb3IKICAgdGhlIHNlcnZlciBjb250 ZW50cy4KCiAgIGEpIHdoYXQgZG9lcyB0aGUgbmFtZSBzcGFjZSBzdHJ1Y3R1cmUgbG9vayBsaWtl LiBJcyB0aGVyZSBhIGZpeGVkIHJvb3QgbmFtZQogICAgICBsaWtlIC5sb2NhbC5hcnBhPwogICBi KSBIb3cgbWFueSB6b25lcyB3aWxsIHRoZXJlIGJlIGFuZCB3aGljaCBob3N0IGlzIHRoZSBhdXRo b3JpdGF0aXZlCiAgICAgIHNlcnZlciBmb3IgYW55IHpvbmUuCiAgIGMpIERvIHdlIG5lZWQgYW4g YXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgYXQgYWxsPwogICBkKSBXaGVuIHRoZXJlIGFyZSBzZXZlcmFs IGNhbmRpZGF0ZSBzZXJ2ZXJzIHdoaWNoIG9uZSB3aWxsIGJlIHRoZQogICAgICBhdXRob3JpdGF0 aXZlIG9uZT8KICAgZSkgV2hhdCB3aWxsIGhhcHBlbiBpZiB0aGVyZSBhcmUgbm8gY2FuZGlkYXRl IHNlcnZlcnM/CiAgIGYpIEFyZSBtdWx0aXBsZSBuYW1lcyBwb3NzaWJsZSBmb3IgYSBzaW5nbGUg SVAgYWRkcmVzcz8KICAgZykgV2hhdCB0byBkbyBpbiBjYXNlIG9mIG5hbWUgY2xhc2hlcz8KCiAg IFdoZW4gdGhlIG5ldHdvcmsgc3dpdGNoZXMgZnJvbSBzdGFuZC1hbG9uZSB0byBjb25uZWN0ZWQg YSBudW1iZXIgb2YKICAgb3RoZXIgcXVlc3Rpb25zIG5lZWQgdG8gYmUgYWRkcmVzc2VkLiBXaXRo aW4gdGhlIGNvbnRleHQgb2YgdGhlIFNJUAogICBwcm90b2NvbCBbUkZDIDI1NDNdIHRoZXJlIGhh dmUgYmVlbiBlZmZvcnRzIHRvIHNldHVwIGFuIGFkZHJlc3NpbmcKICAgc2NoZW1lIGZyb20gdGhl IGludGVybmV0IHRvIHRoZSBob21lIG5ldHdvcmsgW0lEU0lQXS4gVGhlIGZvbGxvd2luZwogICBh ZGRpdGlvbmFsIHF1ZXN0aW9ucyBjYW4gYmUgYXNrZWQ6CgogICBoKSBXaGljaCBvZiB0aGUgbmFt ZWQgYXBwbGlhbmNlcyBhcmUgdmlzaWJsZSB0byB0aGUgd2hvbGUgaW50ZXJuZXQ/CiAgIGkpIERv IHRoZSBuYW1lcyBvZiB0aGUgRE5TIHNlcnZlciBtZW50aW9uZWQgaW4gdGhlIERIQ1Agc2VydmVy IHJlcGxhY2UKICAgICAgdGhlIGV4aXN0aW5nIG9uZXM/CiAgIGopIERvIG11bHRpcGxlIG5hbWVz IGV4aXN0IGFuZCB3aGF0IGlzIHRoZWlyIHZpc2liaWxpdHk/CiAgIGspIFdoYXQgaGFwcGVucyBp ZiB0aGVyZSBhcmUgY2xhc2hlcyBiZXR3ZWVuIGV4dGVybmFsIG5hbWVzIGFuZCBsb2NhbCBuYW1l cz8KICAgbCkgV2hhdCBpcyB0aGUgcmVsYXRpb24gb2YgdGhlIGxvY2FsIGRvbWFpbiBuYW1lIHN0 cnVjdHVyZSwgbG9jYWwgZG9tYWluCiAgICAgIG5hbWUgYW5kIGxvY2FsIHpvbmUgdG8gdGhlIG9u ZXMgb2YgdGhlIGV4dGVybmFsIHNlcnZlci4KCjMuIFdpcmVsZXNzIG5ldHdvcmtzCgogICBUaGUg bW9zdCBjaGFsbGVuZ2luZyBwYXJ0IG9mIHdpcmVsZXNzIG5ldHdvcmtzIGFyZSB0aGUgbW9iaWxp dHkgb2YKICAgdGhlIGhvc3RzIGFuZCB0aGUgc2Vuc2l0aXZpdHkgb2YgdGhlIG5ldHdvcmsgY29u ZmlndXJhdGlvbiB0bwogICBkaXN0YW5jZSBhbmQgYmFycmllcnMgYmV0d2VlbiBpbmRpdmlkdWFs IGhvc3RzLiBUaGlzIG1lYW5zIHRoYXQgYnkKICAgbW92aW5nIGEgd2lyZWxlc3MgZGV2aWNlIChl LmcuIFBEQSkgYXJvdW5kIGl0IG1heSBiZWNvbWUgdmlzaWJsZSB0bwogICBtdWx0aXBsZSBob21l IG5ldHdvcmtzLiAgU3VjaCBhIGRldmljZSBtYXkgYmUgcGFydCBvZiBhIGhvbWUgbmV0d29yawog ICBBIGFuZCBieSBtb3ZpbmcgaXQgdG8gdGhlIG5laWdoYm91ciByZW1haW5zIHBhcnQgb2YgaG9t ZSBuZXR3b3JrIEEsCiAgIGJlY29tZXMgdmlzaWJsZSB0byBob21lIG5ldHdvcmsgQiBvZiB0aGUg bmVpZ2hib3VyIGFuZCBjYW4gYmUKICAgZGVjbGFyZWQgYSBtZW1iZXIgb2YgbmV0d29yayBCLgoK ICAgRnJvbSB0aGF0IG1vbWVudCBvbiBuZXR3b3JrcyBBIGFuZCBCIGJlY29tZSBvbmUgbmV0d29y ayBhbmQgcHJvdmlkZQogICB1bmlxdWUgbGluay1sb2NhbCBhZGRyZXNzZXMgb3ZlciBib3RoIG5l dHdvcmtzLiBIb3dldmVyLCBob3cgd2lsbAogICBuYW1lIHNwYWNlcyBiZSBvcmdhbmlzZWQ/IFRo ZSBhYm92ZSBxdWVzdGlvbnMgYS1sIGhhdmUgdG8gYmUgYW5zd2VyZWQKICAgZm9yIHRoaXMgY2Fz ZSBhcyB3ZWxsLgoKICAgV2lyZWxlc3MgbmV0d29ya3MgYXJlIG1vcmUgc2Vuc2l0aXZlIHRvIGRp c3R1cmJhbmNlcy4gQ29uc2VxdWVudGx5LAogICBob3N0cyBtYXkgYmVjb21lIGRpc2Nvbm5lY3Rl ZCBhbmQgcmVjb25uZWN0IHRvIHRoZSBuZXR3b3JrIHdpdGggYQogICBoaWdoIGZyZXF1ZW5jeS4g VGhlc2UgKGRpcyljb25uZWN0aW9ucyBoYXZlIGFuIGltcGFjdCBvbiB0aGUgbnVtYmVyCiAgIG9m IEFSUCBtZXNzYWdlcyB0aGF0IGFyZSBzZW50LiBJdCBtYXkgYmUgd29ydGh3aGlsZSB0byBwdWJs aXNoCiAgIHJlY29tbWVuZGF0aW9ucyBpbiBjYXNlIG9mIGZyZXF1ZW50IChkaXMpY29ubmVjdGlv bnMgdG8gcmVkdWNlIHRoZQogICBhbW91bnQgb2YgbmV0d29yayB0cmFmZmljIGFuZCBtb2RpZmlj YXRpb25zIHRvIHRoZSBjb250ZW50cyBvZiB0aGUKICAgc2VydmVyLgoKCnZhbiBkZXIgU3Rvaywg UGV0ZXIgICAgIEV4cGlyZXM6IDIzIEphbnVhcnkgMjAwMiAgICAgICAgICAgICAgICBbUGFnZSAz XQoMCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICBaZXJvQ29uZiBpc3N1ZXMgICAgICAgICAg ICAgICAgICAgSnVseSAyMDAxCgoKNC4gU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMKCiAgIEl0IGlz IGVhc3kgZm9yIGFueSBwYXNzaW5nIGRldmljZSB0byBsaXN0ZW4gdG8gYSBjbG9zZSB3aXJlbGVz cwogICBuZXR3b3JrIHVubGVzcyBzcGVjaWFsIHByZWNhdXRpb25zIGFyZSB0YWtlbi4gSXQgY2Fu IGJlIGFzc3VtZWQgdGhhdAogICBtb3N0IE1BQyBwcm90b2NvbHMgZm9yIHdpcmVsZXNzIGNvbm5l Y3Rpb25zIGFkZHJlc3MgdGhpcyBzdWJqZWN0LiBBCiAgIHJlY29tbWVuZGF0aW9uIHRoYXQgZW5j cnlwdGlvbiBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSB3aXJlbGVzcwogICBuZXR3b3JrIGlzIHBy b2JhYmx5IHVuZGVyc3Rvb2QuIE1lY2hhbmlzbXMgZm9yIGFuIGFkZXF1YXRlIHByb3RlY3Rpb24K ICAgYXJlIGFzc3VtZWQgdG8gYmUgcHJvdmlkZWQgc3VjaCB0aGF0IHVua25vd24gcGVyc29ucyBj YW5ub3QgaW50ZXJwcmV0CiAgIHRoZSBkYXRhc3RyZWFtIG9yIGpvaW4gdGhlIG5ldHdvcmsuIEl0 IGlzIHVwIHRvIHRoZSB1c2VyIHRvIGV4cGxvaXQKICAgdGhlc2UgbWVjaGFuaXNtcy4gVGhpcyBp cyBzaW1pbGFyIHRvIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMKICAgcHJvdmlkZWQgZm9yIHlv dXIgd2lyZWxlc3MgREVDVCBuZXR3b3JrIGF0IGhvbWUuCgogICBIb3dldmVyLCB0aGVyZSBhcmUg YSBmZXcgc2VjdXJpdHkgYXNwZWN0cyB0aGF0IG5lZWQgZnVydGhlciBhdHRlbnRpb24KICAgaW4g dGhlIGNvbnRleHQgb2YgbmFtZSBzZXJ2ZXJzLiBJbiBbUkZDIDMwMDddIGFscmVhZHkgYSBmZXcK ICAgcmVjb21tZW5kYXRpb25zIGhhdmUgYmVlbiBkb25lLiBJdCBpcyBuZWNlc3NhcnkgdG8gZGlz dGluZ3Vpc2ggYQogICBzdGFuZCBhbG9uZSBuZXR3b3JrIGFuZCBhIGNvbm5lY3RlZCBob21lIG5l dHdvcmsuIEluIHRoZSBzdGFuZC1hbG9uZQogICBuZXR3b3JrLCBzZWN1cml0eSBpcyBsZXNzIGFu IGlzc3VlIHRoYW4gaW4gdGhlIGNhc2Ugb2YgYSBjb25uZWN0ZWQKICAgbmV0d29yayAoZXhjZXB0 ZWQgdGhlIHdpcmVsZXNzIGNhc2UgZXhwbGFpbmVkIGFib3ZlKS4gSW4gYm90aCBzdGF0ZXMKICAg b2YgdGhlIG5ldHdvcmsgYSBmZXcgaXNzdWVzIG5lZWQgdG8gYmUgYWRkcmVzc2VkOgoKICAgbSkg V2hvIGhhcyBhdXRob3JpdHkgdG8gYWxsb2NhdGUgYSBuYW1lIHRvIGFuIElQIGFkZHJlc3M/CiAg IG4pIFdoYXQgaXMgYSB0cnVzdGVkIHBlcnNvbiBvciBob3N0PwogICBuKSBDYW4gYSB0cnVzdGVk IHBlcnNvbiBhbHdheXMgYWRkL2RlbGV0ZSBuYW1lcyB0byB0aGUgbmFtZSBzcGFjZT8KICAgbykg V2hvIGhhcyBhdXRob3JpdHkgdG8gYWxsb2NhdGUgYSBuYW1lIHRvIGFuIElQIGFkZHJlc3M/CiAg IHApIFdoZW4gdHdvIG5ldHdvcmtzIGpvaW4sIGFyZSBhbGwgbmFtZXMgdmlzaWJsZSB0byBib3Ro IG5ldHdvcmtzPwogICBxKSBDYW4gYSBuZXcgbmFtZWQgZGV2aWNlIHRoYXQgZW50ZXJlZCB0aGUg bmV0d29yayBhdXRvbWF0aWNhbGx5IGJlCiAgICAgIGFkZGVkIHRvIHRoZSBuYW1lIHNwYWNlIHdp dGggaXRzIElQIGFkZHJlc3MsIHByb3ZpZGVkIHRoZXJlIGFyZSBubyBuYW1lCiAgICAgIGNsYXNo ZXM/Cgo1IFJlZmVyZW5jZXMKCiAgIFtJRFpSXSAgICAgSC4gSGF0dGlnLiAiWmVyb2NvbmYgUmVx dWlyZW1lbnRzIiwgSW50ZXJuZXQgRHJhZnQsIFdvcmsKICAgICAgICAgICAgICBpbiBwcm9ncmVz cywgTWF5IDIwMDEuCgogICBbSURMTF0gICAgIFMuIENoZXNoaXJlIGFuZCBCLiBBYm9iYS4gIkR5 bmFtaWMgQ29uZmlndXJhdGlvbiBvZiBJUHY0CiAgICAgICAgICAgICAgTGluay1Mb2NhbCBBZGRy ZXNzZXMiLCBJbnRlcm5ldCBEcmFmdCwgV29yayBpbiBQcm9ncmVzcywKICAgICAgICAgICAgICBK dW5lIDIwMDEuCgogICBbUkZDIDIxMzFdIFIuIERyb21zLiAiRHluYW1pYyBIb3N0IENvbmZpZ3Vy YXRpb24gUHJvdG9jb2wiLCBSRkMgMjEzMSwKICAgICAgICAgICAgICBNYXJjaCAxOTk3LgoKICAg W1JGQyAxMDM0XSBQLiBNb2NhcGV0cmlzLiAiRG9tYWluIG5hbWVzIC0gQ29uY2VwdHMgYW5kIGZh Y2lsaXRpZXMiLAogICAgICAgICAgICAgIFJGQyAxMDM0LCBOb3ZlbWJlciAxOTg3LgoKCiAgIFtS RkMgMTAzNV0gUC4gTW9jYXBldHJpcy4gIkRvbWFpbiBuYW1lcyAtIEltcGxlbWVudGF0aW9uIGFu ZAogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMgMTAzNSwgTm92ZW1iZXIgMTk4Ny4K CiAgIFtJRG1ETlNdICAgTC4gRXNpYm92IGV0IGFsLiAiTXVsdGljYXN0IEROUyIsIEludGVybmV0 IERyYWZ0LCBXb3JrIGluCiAgICAgICAgICAgICAgUHJvZ3Jlc3MsIEp1bHkgMjAwMS4KCgoKdmFu IGRlciBTdG9rLCBQZXRlciAgICAgRXhwaXJlczogMjMgSmFudWFyeSAyMDAyICAgICAgICAgICAg ICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgIFplcm9Db25mIGlzc3Vl cyAgICAgICAgICAgICAgICAgICBKdWx5IDIwMDEKCgogICBbUkZDIDIxMzZdIFAgVml4aWUgZXQg YWwuICJEeW5hbWljIFVwZGF0ZXMgaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbXMKICAgICAgICAg ICAgICAoRE5TIFVQREFURSkiLCBSRkMgMjEzNiwgQXByaWwgMTk5Ny4KCgogICBbUkZDIDMwMDdd IEIuIFdlbGxpbmd0b24uICJTZWN1cmUgRG9tYWluIG5hbWUgU3lzdGVtIChETlMpIER5bmFtaWMK ICAgICAgICAgICAgICBVcGRhdGUiLCBSRkMgMzAwNywgTm92ZW1iZXIgMjAwMC4KCiAgIFtSRkMg MjU0M10gTS4gSGFuZGxleSBhbmQgYWwuICJTSVA6IFNlc3Npb24gSW5pdGlhdGlvbiBwcm90b2Nv bCIsIFJGQwogICAgICAgICAgICAgIDI1NDMsIE1hcmNoIDE5OTkuCgogICBbSURTSVBdIFMuIE15 ZXIgZXQgYWwuICJTSVAgZm9yIEJ1bGJzIiwgSW50ZXJuZXQgRHJhZnQsIFdvcmsgaW4KICAgICAg ICAgICAgICBwcm9ncmVzcywgQXVndXN0IDIwMDAuCgo2LiBBdXRob3IncyBDb250YWN0IEluZm9y bWF0aW9uCgogICBQZXRlciB2YW4gZGVyIFN0b2sKICAgUGhpbGlwcyBSZXNlYXJjaAogICBQcm9m LiBIb2xzdGxhYW4gNAogICBCbGRnIFdMIFAgMy4xMQogICA1NjU2IEFBIEVpbmRob3ZlbgogICBU aGUgTmV0aGVybGFuZHMKCiAgIFBob25lOiAgKzMxIDQwIDI3LjQyNjQ5CgogICBFbWFpbDogIFBl dGVyLnZhbi5kZXIuU3Rva0BwaGlsaXBzLmNvbQoKCgo3LiBGdWxsIENvcHlyaWdodCBTdGF0ZW1l bnQKCkNvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDE5OTkpLiAgQWxsIFJpZ2h0 cyBSZXNlcnZlZC4KClRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUg Y29waWVkIGFuZCBmdXJuaXNoZWQgdG8Kb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQKb3IgYXNzaXN0IGluIGl0cyBpbXBs ZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkCmFuZCBkaXN0cmli dXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkKa2lu ZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJh Z3JhcGgKYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jr cy4gIEhvd2V2ZXIsCnRoaXMgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4g YW55IHdheSwgc3VjaCBhcyBieQpyZW1vdmluZyB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZl cmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5Cm9yIG90aGVyIEludGVybmV0IG9yZ2FuaXph dGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlCm9mIGRldmVsb3BpbmcgSW50 ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMKZm9yIGNvcHlyaWdo dHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQpmb2xs b3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVy IHRoYW4KRW5nbGlzaC4KClRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJl IHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUKcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0 eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25zLgoKVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4KIkFTIElTIiBiYXNp cyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORwoK CnZhbiBkZXIgU3RvaywgUGV0ZXIgICAgIEV4cGlyZXM6IDIzIEphbnVhcnkgMjAwMiAgICAgICAg ICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICBaZXJvQ29uZiBp c3N1ZXMgICAgICAgICAgICAgICAgICAgSnVseSAyMDAxCgoKVEFTSyBGT1JDRSBESVNDTEFJTVMg QUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HCkJVVCBOT1QgTElN SVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTgpIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVT IE9GCk1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4i CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgp2YW4gZGVy IFN0b2ssIFBldGVyICAgICBFeHBpcmVzOiAyMyBKYW51YXJ5IDIwMDIgICAgICAgICAgICAgICAg W1BhZ2UgNl0K --0__=C1256A9300237C048f9e8a93df938690918cC1256A9300237C04-- From owner-zeroconf@merit.edu Wed Jul 25 21:50:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01564 for ; Wed, 25 Jul 2001 21:50:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5D56912FF; Wed, 25 Jul 2001 21:48:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2F9691301; Wed, 25 Jul 2001 21:48:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E542F912FF for ; Wed, 25 Jul 2001 21:45:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FCBB5DD9E; Wed, 25 Jul 2001 21:47:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by segue.merit.edu (Postfix) with ESMTP id 0D1645DD98 for ; Wed, 25 Jul 2001 21:47:58 -0400 (EDT) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f6Q279106318; Wed, 25 Jul 2001 22:07:09 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010725214152.0277dd28@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 25 Jul 2001 21:47:40 -0400 To: iesg@ietf.org, ietf@ietf.org From: Marc Blanchet Subject: Re: Last Call: Dynamic Configuration of IPv4 link-local addresses to Proposed Standard Cc: zeroconf@merit.edu, rfc@stuartcheshire.org, bernarda@microsoft.com In-Reply-To: <200107251937.PAA27955@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit I was looking a month ago for a reference on arp-self (i.e. the DAD in IPv6) that many ipv4 implementations do. The author of this draft (Stuart) kindly responded to me that the draft includes info on this. Since self-arp is ipv4 generic and not necessarily associated with zeroconf, as noted in the draft, I would recommend to: - extract all data related to arp-self (essentially section 2.2 and beginning section 2) from this draft and make another draft. - from ipv4-linklocal, reference the new draft for self-arp - push the 2 as RFC. this will enable an implementor to reference the arp-self document without necessarily supporting the ipv4-linklocal draft. A suggestion. Marc. At/À 15:37 2001-07-25 -0400, The IESG you wrote/vous écriviez: >The IESG has received a request from the Zero Configuration Networking >Working Group to consider Dynamic Configuration of IPv4 link-local >addresses as a Proposed >Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2001. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-04.txt From owner-zeroconf@merit.edu Fri Jul 27 08:26:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11807 for ; Fri, 27 Jul 2001 08:26:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70B009129D; Fri, 27 Jul 2001 08:27:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4466291332; Fri, 27 Jul 2001 08:27:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 019AA9129D for ; Fri, 27 Jul 2001 08:27:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D8495DDB2; Fri, 27 Jul 2001 08:29:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id 37D5F5DD9E for ; Fri, 27 Jul 2001 08:28:59 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6RCPTP05112; Fri, 27 Jul 2001 08:25:29 -0400 Message-Id: <200107271225.f6RCPTP05112@hygro.adsl.duke.edu> To: Erik Guttman Cc: zeroconf@merit.edu, cheshire@apple.com, Erik Nordmark Subject: Re: summary of discussion on draft-ietf-zeroconf-reqts-08.txt In-Reply-To: Message from Erik Guttman of "Fri, 20 Jul 2001 16:25:06 +0200." Date: Fri, 27 Jul 2001 08:25:29 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Only commenting where I disagree. > > How about a more descriptive title than "zeroconf requirements" > Suggestion: Zeroconf IP Host Requirements > This makes it clear that we are discussing hosts not > routers. This is better, but can we do even better?. My overall concern is that many (most?) folks (i.e, those not in the WG) won't have any idea what the term "zeroconf" means. So if that term could be expanded out somehow... > Action: Open > --------------------------------------------------------------------- > 08.02 MAC addr as config info > "Thomas Narten" wrote: > > > A zeroconf protocol is able to operate correctly in the absence > > > of configured information from either a user or infrastructure > > > services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, > > > RFC 1035] servers. Zeroconf protocols may use configured > > > information, when it is available, but do not rely on it being > > > present. One possible exception is the use of MAC addresses > > > (i.e. layer two addresses) as parameters in zeroconf protocols. > > > > I do not consider a MAC address to be configured information. It is > > built-in as far as the end user is concerned. > While this is strictly true, in some cases it is configurable. > (Solaris for instance allows this, as do many PC NIC drivers.) Yes, but in those cases the need for configuration is necessary for some other reason. I.e, home users won't be dealing with this. And it is an option to configure this, not a requirement in most cases. > A second consideration was whether ANY parameters could be used > in zeroconf protocols, built-in or otherwise. We wanted to > emphasize that MAC addresses were OK for use. The last sentence saying "mac addresses are an exception" I find misleading. They are not configured (in the sense an end user will configure them), yet the sentence reads as if their use is an exception to the rule that configured information can be used when present, but must not be relied upon. How about changing the last sentence to: The use of MAC addresses (i.e. layer two addresses) as parameters in zeroconf protocols is generally acceptable because they are globally unique and readily available on most devices of interest. But this is a minor wording issue in the overall scheme of things. > 08.07 open ended text > "Thomas Narten" wrote: > > > Requirement: > > > - MUST respond to state changes and resolve conflicts in a timely > > > manner. > > > > Note that his is really open ended, so I don't really know what "MUST" > > means specifically. What conflicts need to be resolved? Indeed, what > > is a "conflict"? My suspicion is that having a MUST here in a generic > > sense is not appropriate. What you want is a MUST in specific > > sitations that it is felt should or should not happen.t > Suggestion: Spell this out for each protocol area: > address autoconfiguration - detect and eliminate duplicate addresses. > name resolution - allow resolution of names which could not > previously be resolved. In particular, if a host wishes to > resolve its own name to determine if it is unique, it will > be able to detect this conflict and resolve it in a timely > manner. > service discovery - allow discovery of previously undiscovered > services. > multicast address allocation protocol - detect and eliminate duplicate > addresses. This works for me. > --------------------------------------------------------------------- > 08.08 say some more about routing information > "Thomas Narten" wrote: > > > Requirements: > > > - MUST configure an appropriate netmask. > > > - MUST have unique IP addresses within an IP subnet. > > > - MUST have some routing information > > > (for the internetwork scenario). > > > > On the last point, would it be more correct to say, needs the address > > of one or more default routers? Or is there more to this? > Aidan William replied: > > I think the wording takes care to avoid the term "default router". > > Routing information may be a default route, but might not be. > > There was even discussion of hosts ARPing for every address and > > having the router do proxy ARP for destinations in different subnets. > "Erik Guttman" wrote: > > The background is that any mention of default router configuration > > implies that there are routers in the network, which may not be the > > case. Consider RFC 1122, section 3.3.1.1: > > > > The host IP layer MUST operate correctly in a minimal > > network environment, and in particular, when there are no > > gateways. For example, if the IP layer of a host insists on > > finding at least one gateway to initialize, the host will be > > unable to operate on a single isolated broadcast net. > > > > This clearly indicates that there is no requirement, in the link-local > > communication case, to know of any gateways. > > > > What we mean in the above case is that some routing information is > > needed, as stated in RFC 1122, section 3.3.1.2: > > > > The IP layer MUST support multiple default gateways. > > > > The ZEROCONF requirement is that routing state is available in the > > IP layer - which *may or may not* include a list of default gateways. > > In one plausible case, a LL-only device will use the 'arp for everything' > > forwarding policy, discussed by Stuart. In the case where DHCP configures > > an interface, default gateway(s) will be configured, while still allowing > > for delivery of datagrams to connected networks without the need for a > > gateway. > > > > We aimed at text which supported both possibilities, without requiring > > us to spell them out in detail. > Action: change text to clarify zc may or may not include a list of > gateways. Works for me. My intitial reaction came from the terminology "must have routing information" which seemed open ended to me, and could be implied to read needs to have more than just a pointer to a default router. But if one considers the netmask of the attached link to be part of "rouring information" the statement makes more sense. > --------------------------------------------------------------------- > 08.09 scoping > "Thomas Narten" wrote: > > > - MUST have unique IP subnets within an internetwork > > > (only for the internetwork scenario). > > > > Do you need to scope this more? I.e., can't an "internetwork" consist > > of the entire Internet (per the earlier definition?) > Aidan William replied: > > Perhaps "internetwork" should be a "zeroconf internetwork" in this > > section, where a "zeroconf internetwork" is the bunch of subnets > > connected to exactly one router. > Erik Guttman wrote: > > The text above is sufficiently general that it leaves room for multiple > > router zeroconf interface autoconfiguration to be standardized in the > > future. > > > > We did not preclude multiple routers from our charter because we thought > > it was a bad idea. Rather, we did not think we could standardize > > multi-router zeroconf protocols in a timely manner. The requirements > > document does not need to echo our charter humility, restricting future > > (perhaps immanent) standardization efforts. > Suggestion: clarify that this is currently only specified on a > single link or a network with routers whose configuration > is out of scope for this spec. The original wording as can be read to imply IP subnets MUST be numbered uniquely within an internetwork. If "internetwork" includes the entire Internet (my read of the definition is that this is true), then this requirement would appear to be unachievable. > --------------------------------------------------------------------- > 08.11 resolve conflicts - should be more specific > "Thomas Narten" wrote: > > > Requirement: > > > - MUST resolve conflicts and state changes in a timely manner. > > > > Can the document be more specific and say just what conflicts need to > > be resolved? Or is the assumption that the previously discussed issues > > is what needs to be addressed? > Aidan.Williams@motorola.com wrote: > > I read this as referring to section 2.1.1, where there are a set of > > uniqueness requirements, etc. Maybe it could do so explicitly. > > For me, this requirement adds an on-going consistency requirement for > > everything in 2.1.1. > Suggestion: Isn't this addressed by 08.07 above? I think so. > Action: Open > --------------------------------------------------------------------- > 08.12 IPv6 considerations for interface configuration > "Thomas Narten" wrote: > > > 2.1.3 IPv6 Considerations > > > > > > IPv6 allows a host to select an appropriate IP address, netmask, > > > and routing information, thus if a host is using IPv6, a zeroconf > > > IP interface configuration solution already exists. > > > > > > Is this fully correct? Do routers automatically (without user > > configuration) advertise themselves as default routers? > > > > Indeed, I'm a bit confused about whether this document assumes > > multiple subnets are present. It seems to, but I thought the WG > > decided that a single router was assumed. It would be good to state up > > front what the assumptions are for the enivironment zeroconf is > > operating in. Will there be just one router? Or multiple routers? Or > > no routers? > Suggestion: We have to support 0 routers. We can support 1+ router. > Folks want to consider how 1 router can be auto configuring, but > this is tangential to the requirements in this document. > We have nothing to say about how routers are configured. Let's > make it clear the ZC requirements concern only host configuration > not router configuration. I'm OK with leaving the text as is. > --------------------------------------------------------------------- > 08.14 unclear requirement > "Thomas Narten" wrote: > > > 2.3.1 Scope Enumeration > > > > > > Applications that leave the choice of scope up to the user require > > > the ability to enumerate what scopes the host is operating within. > > > In addition, services that are assigned relative addresses require > > > the ability to enumerate what scopes the host is within; only then > > > will a host be able to apply the relative address to a scope. > > > > > > Requirements: > > > - MUST list which of the scopes (local, link-local, or site-local) > > > are available for hosts. > > > - MUST list per-scope address ranges that may be allocated. > > > > I'm not clear what the requirement above is. That is, *who* is > > responsbile for the MUST? The application? How is the application > > supposed to determine this? Is the point that this information must > > somehow be determinable? (General comment: This may all be an artifact > > from the fact that the Requirements bullets are not using full > > sentences.) > Erik Guttman wrote: > > I agree the writing is not clear here. > "Aidan Williams" replied: > > Yes, I think the point is that there should be a way for the > > application to find this information out. Incidentally, this doesn't > > seem to just be a zeroconf requirement, but is probably true of any > > networking with non-trivial multicast applications. > Erik Guttman wrote: > > Yes: This requirement is derived from MALLOC WG's requirements. > > The requirement here pertains to a zeroconf multicast address allocation > > protocol. This protocol has to expose its capabilities to applications. > > > > ZMAAP only works in a subset of the scopes listed above (link-local, > > unicast-prefix based and subnet-local). The ZMAAP API exposes this > > list to applications. A future version of ZMAAP capable of interoperation > > with MADCAP servers could support local, site-local or other scopes > > as well. > Suggestion: > MUST -> Application support software used to autoconfigure > multicast addresses MUST Not sure what the proposal here is. > Action: Open > --------------------------------------------------------------------- > 08.17 explain security requirements text better, for IPv4 > "Thomas Narten" wrote: > > > > > The IPv4 interface configuration protocol MAY omit security > > > mechanisms if and only if that protocol is not used for IPv6 and > > > cannot be extended to support IPv6. It is strongly recommended that > > > it include security mechanisms, because many protocols are extended > > > later in ways not anticipated by the original developer(s). > > > > Explain > This tangled formation came from (a) simple text from me saying > since ARP is insecure, IPv4 autoconf MAY be too, (b) Ran noting that > IPv6 may be implemented over IPv4 so more care would be needed in > the formulation and (c) Stuart's polishing the text for clarity > while trying to preserve as much as possible so as to not force > a new last call (which happened anyway). > What it means is: > IPv4 autoconf MAY be insecure to configure IPv4 interface parameters > (as ARP is insecure). > If the IPv4 autoconf mechanism is used to support IPv6, it had better > be secured (at some level - say the IPv6 in IPv4 packets may include > IPsec AH for the ND messages). > Ran wanted to make sure that even though we may omit security (we > do in IPv4 LL autoconf) there's some text indicating its a Bad Thing. > Suggestion: Leave it alone. The current text doesn't (to me) communicate the message you explained. Thomas