From owner-zeroconf@merit.edu Thu Sep 6 02:25: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 ESMTP id CAA16228 for ; Thu, 6 Sep 2001 02:25:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9F4D912A4; Thu, 6 Sep 2001 02:26:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1BAB912A5; Thu, 6 Sep 2001 02:26:23 -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 AFE31912A4 for ; Thu, 6 Sep 2001 02:26:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77F945DDA1; Thu, 6 Sep 2001 02:26:22 -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 D0FE55DD92 for ; Thu, 6 Sep 2001 02:26:21 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id XAA16455; Wed, 5 Sep 2001 23:26:17 -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 XAA03768; Wed, 5 Sep 2001 23:26:13 -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 f866Q5A17899; Thu, 6 Sep 2001 16:26:06 +1000 (EST) Message-ID: <3B9716FD.6CEB4B6@email.mot.com> Date: Thu, 06 Sep 2001 16:26:05 +1000 From: Aidan Williams X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Erik Nordmark , Stuart Cheshire , Erik Guttman , zeroconf@merit.edu Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In contrast, if I leave the door to my house open, I can only be robbed by > people who happen to be in the vicinity at the time. To rob my house, the > criminal has to be in that physical location, and will leave evidence of > his/her presence (fingerprinters, DNA, etc.). It can be argued that moving > from the "Internet crime" paradigm to the "local criminal" paradigm > reduces the risk of theft by orders of magnitude -- bringing us back to > the "antique" model of criminality that existed prior to the Internet. > It's only value is restricting the source to someone within some > reasonable proximity of the destination. Even with 802.11 networks, home > phone & powerline networks, etc. we are talking about fairly small > proximity. Right -- you make a good point. One case which still bothers me is the possibility of "casing" or gaining an inventory of a home network via a wireless or powerline network. Powerline and 802.11 are close proximity networks, but they don't require entry to exploit. regards aidan ____ :wq! Communications and Networks Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://cnlab.arc.corp.mot.com/ From owner-zeroconf@merit.edu Thu Sep 6 04:06: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 ESMTP id EAA17313 for ; Thu, 6 Sep 2001 04:06:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EEAB912A7; Thu, 6 Sep 2001 04:07:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E4C3912A9; Thu, 6 Sep 2001 04:07: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 5291D912A7 for ; Thu, 6 Sep 2001 04:07:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3601B5DD9B; Thu, 6 Sep 2001 04:07:35 -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 876415DD92 for ; Thu, 6 Sep 2001 04:07:34 -0400 (EDT) Received: from mailgate2.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 BAA09982 for ; Thu, 6 Sep 2001 01:07:33 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 6 Sep 2001 01:07:32 -0700 Received: from [206.111.147.149] (vpn-gh-1060.apple.com [17.254.140.35]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f8687Vw25457; Thu, 6 Sep 2001 01:07:31 -0700 (PDT) Message-Id: <200109060807.f8687Vw25457@scv2.apple.com> Subject: IETF 51 ZEROCONF Minutes Date: Thu, 6 Sep 2001 01:07:32 -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 The following minutes will be sent to ---------------------------------------------------------------------- Minutes for the ZEROCONF Meeting 3:30pm - 5:30pm, Thursday, 9th August 2001 51st IETF Meeting, London, England, 5th - 10th August 2001 Chairs: Erik Guttman Stuart Cheshire Thanks to Aidan Williams for taking notes for these minutes. By request the previously published agenda was rearranged to move ZMAAP discussion earlier. Revised Agenda: 1) Agenda discussion & finalization 5 minutes Stuart and Erik 2) ZMAAP - Status, issues, next? 30 minutes draft-ietf-zeroconf-zmaap-01.txt draft-ietf-zeroconf-zmaap-api-00.txt Erik GOAL: Settle technical issues. Agree to disposition of the document (standards track or experimental?) What remains to do before WG last call? 3) Wrap up of requirements doc 5 minutes draft-ietf-zeroconf-reqts-08.txt Erik GOAL: Agree work on this document is complete. 4) Wrap up of IPv4 link-local doc 5 minutes draft-ietf-zeroconf-ipv4-linklocal-03.txt Stuart GOAL: Agree work on this document is complete. 5) Multicast Address Allocation using 10 minutes IPv4 Link-local Address draft-hong-autoconf-multicast-ipv4-00.txt Yong-Geun Hong 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. 6) Zeroconf Host Profile 30 minutes draft-ietf-zeroconf-host-prof-00.txt Erik GOAL: Kick off this work. Get as far as we can on it. Various questions about document structure to answer. 7) Where to - charter discussion 5 minutes Stuart & Erik GOAL: Determine whether to take on more work. 8) Operational Zeroconf questions 10 minutes Peter van der Stok ---------------------------------------------------------------------- 2) 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 Guttman - discussion of zmaap requirements * new requirement: Enumerate supported scopes (requirement from RFC 2771) * new requirement: Notification of a conflict - description of protocol (see draft) - IPv4 link local multicast address space is scarce, therefore listen to learn of existing allocations Dave Thaler: This is not required for IPv6 because the address space is not scarce - Should we prevent races? - Timely detection of conflict. Two ways: * poll (not good -- wastes bandwidth) * advertise (current approach) There's no general mechanism that would allow you to tell whether an address collision has occurred, in the general case, purely by listening to the multicast traffic. Only the applications involved know what constitutes a collision. For this reason, either (a) the multicast allocation protocol has to use periodic polling, or (b) there needs to be an API for the application to inform ZMAAP when the application detects what it deems to be a conflict. No such API currently exists. However, unlike unicast address allocation, multicast address collisions are not disastrous. Robust multicast applications need to be resilient to collisions anyway, so immediate detection of collisions is not essential. Steve Hanna: There is no mention of advertising in the current (-01) ZMAAP draft Erik Guttman: There has been discussion on the mailing list of adding periodic messages, to detect conflicts and allow address caches to be built up. Steve Hanna: Collisions are unlikely to be noticed at the application level, because unless the applications are using the same UDP port number, conflicting packets will be discarded in the kernel before the application sees them. (This is a general problem for multicast, because the existence of UDP port numbers within the packet gives an extra layer of filtering that's outside the control of whatever multicast address allocation protocol is being used). However, for link-local multicast, perhaps we don't even care that there are undetected conflicts at the multicast address level, if filtering by UDP port number is giving applications behaviour that's adequate for their needs. Dave Thaler agreed; we can safely ignore conflict detection Summary: No periodic messages to actively seek out conflicts, but if a conflict is detected when AUIs are sent for other reasons, then that conflict should be dealt with. - Rather than allocating blocks of addresses, could we simplify the protocol by allocating single addresses instead? Dave Thaler: Especially on IPv6 where addresses are plentiful, there are applications that want to allocate large ranges and use them sparsely. It is common to allocate a large range where the size is a power of two so and hash within that range. Summary: No. Some applications need to allocate large contiguous ranges, and the protocol should support that directly. - Should there be a deterministic tie-breaker algorithm? Steve Hanna: What's the harm? Michael Patton: Watch out for DoS If the tie-breaker is based on highest host IP address, it gives hosts an incentive to always want the highest IP address they can get. Mark Handley: 3rd party defense is a problem Even if the tie-breaker algorithm is deterministic, it's not guaranteed to generate the same result everywhere if some hosts do not receive all the packets. Some participants may realize they were forced to choose a new address while other members of the group do not. Summary: We don't need to do this, if we were going to we would have to be very careful so the tie-breaker algorithm does not encourage bad behaviour. Take it to the list. - Session Discovery Problem: When a single address is desired, and a race happens during formation, multiple groups could be inadvertently created. Suggestion: Discover duplicate session creations and collapse them into one? Dave Thaler: How do they know they should be part of the same group? Erik Guttman: The devices know they are looking for a multicast session with some particular name. When they find no multicast session with that name exists, the device(s) then proceed to allocate a multicast address and give it that name. If a whole network of devices are powered on at the same time, they could all do this simultaneously, resulting in the creation of multiple groups instead of one. Erik: Suggestions: Include a minimal session description in AIUs? Combined allocation/session discovery. Could define a ZSAP separate protocol. Steve Hanna: Could Service Location Protocol do this? Stuart Cheshire: Perhaps. The issue is that the operation of looking up a session name, and creating the session if it doesn't already exist, needs to be an atomic operation. Steve Hanna: It is the insertion of the session into the "directory" which needs to be atomic. Stuart Cheshire: Agreed. Furthermore, consider this line of reasoning: If your session naming protocol has the ability to generate conflict indications when the same name appears in the namespace more than once (as it must), then it can also easily have the ability to generate conflict indications when the same multicast address appears more than once. Now you don't need a separate multicast address allocation protocol. Instead of picking a random address and using ZMAAP to test if the address is already in use, you can just pick a random address and try to register it using the session naming protocol, and if that address (or range) is already in use, then your session naming protocol will inform you of the conflict. The end result is that we've combined multicast address allocation and session naming into a single protocol, which I believe is the correct solution. Erik: Should we enrich the existing ZMAAP proposal to do naming as well? Dave Thaler: Multicast DNS is a naming protocol which already has the capability to do conflict detection. If you could express the the multicast address allocation in the form of a DNS name, then Multicast DNS solves this problem. Steve Hanna: Lets do this in an existing protocol, unless we absolutely need something new. Third comment: Lets try to do this with Multicast DNS if we can. - API Erik: The API currently conforms to RFC 2771. Abstract API, plus specific APIs for C and Java Do we pass on conflict detection? We don't want to burden the network with lots of traffic to support conflict detection if it's not needed. However, if we do notice a conflict, do we want to have an API where we can inform the application of that fact? Michael Patton: Yes, we should have that API Collision is probably going to happen often (in v4 at least) Stuart Cheshire: Question: Is this notification from the OS to the application a message of the form, "A collision happened, what should we do?", or is it a message of the form, "A collision happened, and your multicast address range has been forcibly revoked." If it is the latter, this may be an aspect of application software that does not get tested very well, just like many applications today that don't cope well if the machine's unicast address changes while they're running. Erik: The message indicates a forcible revocation Steve Hanna: There are two issues here: 1. ZMAAP notifies application of detected collision 2. Application notifies ZMAAP of a detected collision Also, recommending that applications put a magic number at the start of every packet helps detect accidental collisions Michael Patton: That's just the UDP port number. Consensus: Include collision detection notification API (both directions) API document will be advanced to Informational RFC Michael Patton: If we are expecting to have only 16 link-local IPv4 multicast addresses available for dynamic allocation, we will have to live with collisions. If there are more than 16 applications on the network needing a multicast address, some are going to have to share. Again, demultiplexing based on UDP port number may be the answer. Erik: OK, we'll look at this Dave Thaler: This is once again another good reason to be using IPv6. Mark Handley: We could perhaps get more IPv4 link-local multicast addresses allocated if we need them Erik: But there are only 256 IPv4 link-local multicast addresses in total. Dave Thaler: 1. We can't get a new range allocated for dynamic link-local addresses because existing routers won't filter them, so they won't be link-local. 2. ZMAAP can also allocate global addresses, so it is not as constrained as we might think. 3. Forget v4 and go straight to IPv6 Mark Handley: Agreed, but if we anticipate needing more IPv4 link-local multicast addresses, we should start working on that sooner rather than later Erik: Lets ask IANA for a block of 16 or 32 addresses out of the existing 224.0.0/24 link-local multicast range. Dave Thaler: Ask for 128 addresses. They can always say no and give fewer if they choose. ---------------------------------------------------------------------- 3) Wrap up of requirements doc 5 minutes draft-ietf-zeroconf-reqts-08.txt Erik GOAL: Agree work on this document is complete. No disagreements. ---------------------------------------------------------------------- 4) Wrap up of IPv4 link-local doc 5 minutes draft-ietf-zeroconf-ipv4-linklocal-03.txt Stuart GOAL: Agree work on this document is complete. This is in IETF last call. - Move comments re general checking of uniqueness of IPv4 addrs to a new document - We have a long list of comments from Keith Moore * Security (link-local != no security needed) However, we're not going to move to an all-IP world if we tell USB printer vendors that they're not allowed to make link-local IP printers unless they have IPSEC in them. * Guideline for max number of hosts? Protocol should not enforce limit, but document should indicate applicability. * Self-assignment necessarily implies lower reliability? Not necessarily. Appletalk uses self-assignment and does not have significant problems with it. * Keith asserts that link-local packets *will* be routed But: Not if TTL checks work, routers are implemented properly Narten: How does this interoperate with Windows 98 for example? (Windows sends a 128 TTL) Stuart: The specification should state what we believe is the right thing to do, and implementations should strive to converge towards that. Mac OS didn't send all link-local packets with TTL=255 either, but I thought that TTL=255 was a good suggestion and the right thing to do, so we changed Mac OS and shipped a software update. Erik: MUST drop => not backward compatible. Document should perhaps say "SHOULD drop if a host wants to ensure that it's not receiving off-link packets." Narten: WG consensus needed. Dave Thaler: Supports TTL=255. Indeed, mDNS draft says the same thing. The draft should say that this check is specifically for devices that care about this aspect of security, not mandatory for all devices. Also, note that default TTL is a configurable option in Windows. Erik: Note: TTL=255 for mDNS is not without issues itself -- it breaks compatibilty some existing resolvers. Need to discuss this on the list. * Keith asserts: Random addresses are no use. But: they are if you have service discovery or some other name-to-address mapping mechanism. Does the draft need to state this? Will discuss this on the list. * Keith asserts: Current applications don't cope with address changes But: This varies with operating system. Most Mac OS networking applications do cope with address changes. On other operating systems it is less common for application software to handle address changes properly. Erik: This is a very interesting issue; one that I have discussed with Patrik Faltstrom. It would be helpful to gather a list of issues emerging from new developments in the Internet Area, and hold a BOF to discuss how these impact the Applications Area. Stuart: Agreed. The goal of Zeroconf is to make applications work as well as possible without changes; that doesn't mean they can't work better if they are aware of Zeroconf issues. * Keith points out the problem of synchronized ARPs. Having a small random delay before the first ARP is a good suggestion. * Keith questions whether it is in the scope of this document to say: 169.254/16 packets MUST NOT be forwarded. Narten: This WG appears to have decided that 169.254/16 is link-local, so that is the decision. Erik: We could create a separate router requirements doc for ZC Narten: Just make it a separate section under its own heading in the current document. ---------------------------------------------------------------------- 5) Multicast Address Allocation using 10 minutes IPv4 Link-local Address draft-hong-autoconf-multicast-ipv4-00.txt Yong-Geun Hong 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. Erik: Please address: * How this relates to ZMAAP; why do we need two proposals? [Presentation] - IPv4: map two lower octets of 169.254/16 -> 239.255/16 to form multicast address - IPv6: map IPv6 interface ID into IPv6 multicast Overlaps the TLA/SLA and host portion - Goal is to radically simplify multicast address allocation protocol Erik: If an IPv4 host needs more than one multicast address, how does it get one? Yong-Geun Hong: Applications need to use different UDP port numbers. Michael Patton: Deja vu, already discussed. Doesn't cope with the requirement to share a multicast address between several hosts. Doesn't support the case where a multicast group persists longer than the life of the host that originated the group. Dave Thaler: In IPv4, some applications require more than one multicast address. However, in IPv6, this may have real use, similar to unicast- prefix-based-address assignment. Mark Handley: Forcing applications to share group addresses may result in hosts getting swamped with more traffic than they can handle. Erik: We want to support more than just link-local networks, eventually. In this case, a host may not have a 169.254/16 address. Also, to run two instances of an application on one host, using that application's well-known port number, would require two multicast addresses. The only way to do that with this proposal is to have two link-local addresses. Stuart: The general theme here is that we can trade off reduced complexity (and fewer on-the-wire packets) in the multicast address allocation protocol in exchange for a higher degree of multicast address sharing by applications. Taking this theme to its logical conclusion, we could mandate that all Zeroconf multicast applications use 224.0.0.1. In this case the allocation protocol is trivial (just a hard-coded constant in every host, with no on-the-wire packets at all) in exchange for the most extreme case of sharing, where everything shares one address. We need to decide where on that spectrum we want to be. Dave Thaler: Suggest you move this to IPNGWG, pursue it. Erik: This is a proper subset of ZMAAP's functionality. I haven't heard any compelling argument why it is better than ZMAPP. Yong-Geun Hong: I'll take this up with IPNGWG. Erik: Is there interest in pursuing this proposal in this WG? Consensus: No. Erik thanked Yong-Geun Hong for his work, and encouraged him to pursue it in IPNGWG. Thaler: Works for a particular scope (e.g. link-local for IPv6) and as such may be a valid zeroconf solution for IPv6. Stuart: Clarification: What Erik is saying is NOT that this is a bad proposal. What Erik is saying is that the charter of this working group is primarily to define requirements, and only to define protocols where no adequate protocol already exists, and no other appropriate working group exists to develop the protocol. If this work is appropriate for IPNGWG, then it is NOT appropriate for this working group to take on a protocol that properly belongs in that working group's charter. ---------------------------------------------------------------------- 6) Zeroconf Host Profile 30 minutes draft-ietf-zeroconf-host-prof-00.txt Erik GOAL: Kick off this work. Get as far as we can on it. Various questions about document structure to answer. -00 draft is currently in the Internet Drafts directory. -01 revision of document has been submitted and will be available shortly. What kind of RFC should the "Host Profile" be? Bob Braden suggests "Applicability Statement" -- in the sense defined in RFC 2026 "The Internet Standards Process". According to RFC 2026 these can be Standards Track documents. [Narten: These documents are usually Informational or BCP, not Standards Track.] - New title: Zero Configuration Host Requirements Applicability Statement - Document Structure taken from RFC 1122 (Host Requirements) - Include implementation notes? - Protocol Requirement Levels: * v4/v6 address autoconfiguration: Required * mDNS: Required * ZMAAP: Elective * SLPv2 and mDNS + RRs: Recommended Thaler: mDNS only required for those hosts which participate in name resolution. Patton: No, mDNS is required. Randomly generated IP addresses are effectively useless without it. - Try to get agreement on this soon, even if other documents are not finished. Patton: WG doesn't even have to wait, document can just sit in the RFC editors queue Narten: Deal with this when we need to. In any case, the WG can't go away until every last RFC in the queue is issued. Please comment. ---------------------------------------------------------------------- 7) Where to - charter discussion 5 minutes Stuart & Erik GOAL: Determine whether to take on more work. Four items: - Submit Requirements for Zero Configuration Networking to be considered as an Informational RFC. (Done) - Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. (Done) - Submit Multicast Address Allocation Protocol for Zeroconf networks to be considered as a Standards Track RFC. (In progress) - Submit Host Profile for Zero Configuration Networking as an Informational RFC. (In progress) The Zeroconf Working group will not tackle the following: - Zeroconf routers - Zeroconf edge servers - Secure remote access ---------------------------------------------------------------------- 8) Operational Zeroconf questions 10 minutes Peter van der Stok - Home networks - Devices entering the home might have conflicting names Want protection from this - Want mDNS to work at the *same* time as uDNS - Connection of two ZC networks in homes needs policies? Issues: * Multiple dns servers * Connection/disconnection to ISP * Concatenation of networks * Multiple names * Authority to add/mod/delete? * ... Erik: these are mostly related to mDNS This work is in the dnsext WG. See draft-guttman-dhc-mdns-enable-00.txt. Name conflicts could be dealt with by doing service discovery rather than naming.. Establishing specific policy for what is allowed and what is not allowed on the local network is a question of administration, which is by definition not zero configuration Peter van der Stok: Want to use mDNS at the same time as uDNS Erik: There is work on this subject already going on See draft-cheshire-dnsext-multicastdns-00.txt Patton: The working group has been focussed on protocol details for a while. This may be a good time to revisit some of the larger issues. These should be discussed on the mailing list. Tony Hain: Applicability statement needs to deal with these issues. Thaler: mDNS explicitly allows names to be duplicates, when that is appropriate. ---------------------------------------------------------------------- Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Sep 6 11:51: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 ESMTP id LAA00933 for ; Thu, 6 Sep 2001 11:51:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F2F96912C0; Thu, 6 Sep 2001 11:53:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C26E1912C1; Thu, 6 Sep 2001 11:53: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 CCEE7912C0 for ; Thu, 6 Sep 2001 11:53:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9871E5DD9F; Thu, 6 Sep 2001 11:53:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id 76CEA5DD94 for ; Thu, 6 Sep 2001 11:53:05 -0400 (EDT) Received: from SERVER.ACM.org ([63.199.7.253]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GJ900DSS03XPU@mta5.snfc21.pbi.net> for ZeroConf@Merit.edu; Thu, 06 Sep 2001 08:52:45 -0700 (PDT) Date: Thu, 06 Sep 2001 08:52:39 -0700 From: Peter Johansson Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: <200109060807.f8687Vw25457@scv2.apple.com> X-Sender: Celeborn@PostOffice.PacBell.net To: Zero Configuration Message-id: <5.1.0.14.2.20010906085148.03a0f678@PostOffice.PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT At 01:07 AM 9/6/2001 -0700, Stuart Cheshire wrote: >The following minutes will be sent to Please amend the minutes (if you have not already done so) to include the attendance list. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Thu Sep 6 14:11:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04740 for ; Thu, 6 Sep 2001 14:11:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D71E3912C6; Thu, 6 Sep 2001 14:13:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2750912C7; Thu, 6 Sep 2001 14:13:09 -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 C55B1912C6 for ; Thu, 6 Sep 2001 14:13:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A04C75DDAC; Thu, 6 Sep 2001 14:13:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brandenburg.cs.mu.OZ.AU (unknown [202.12.73.55]) by segue.merit.edu (Postfix) with ESMTP id AC42E5DDA9 for ; Thu, 6 Sep 2001 14:13:06 -0400 (EDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f86IAAl01882; Fri, 7 Sep 2001 01:10:11 +0700 (ICT) From: Robert Elz To: Peter Johansson Cc: Zero Configuration Subject: Re: IETF 51 ZEROCONF Minutes In-Reply-To: <5.1.0.14.2.20010906085148.03a0f678@PostOffice.PacBell.net> References: <5.1.0.14.2.20010906085148.03a0f678@PostOffice.PacBell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Sep 2001 01:10:10 +0700 Message-ID: <1880.999799810@brandenburg.cs.mu.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 06 Sep 2001 08:52:39 -0700 From: Peter Johansson Message-ID: <5.1.0.14.2.20010906085148.03a0f678@PostOffice.PacBell.net> | Please amend the minutes (if you have not already done so) to include the | attendance list. IETF minutes don't include attendance lists - ever. That info used to be captured by the secretariat from the info recorded on the famous "blue sheets" and made available in a separate file. See ftp://ftp.ietf.org/ietf/dnsind (or any other old working group) That practice stopped several years ago - probably partly due to the workload involved (attempting to convert data hand written while sitting in a chair with nothing to write on into correct names & addresses), but more importantly, to avoid the lists being used for non IETF purposes (spam, head hunters, ...) kre From owner-zeroconf@merit.edu Thu Sep 6 15:07:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06297 for ; Thu, 6 Sep 2001 15:07:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 073E4912CA; Thu, 6 Sep 2001 15:08:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8C81912CB; Thu, 6 Sep 2001 15:08: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 E1883912CA for ; Thu, 6 Sep 2001 15:08:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFA785DD9A; Thu, 6 Sep 2001 15:08:49 -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 2566A5DD94 for ; Thu, 6 Sep 2001 15:08:49 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA02749 for ; Thu, 6 Sep 2001 12:08:48 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 6 Sep 2001 12:08:47 -0700 Received: from [206.111.147.149] (vpn-gh-38.apple.com [17.254.136.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id MAA27156 for ; Thu, 6 Sep 2001 12:08:46 -0700 (PDT) Message-Id: <200109061908.MAA27156@scv3.apple.com> Subject: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Thu, 6 Sep 2001 12:08:46 -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 Keith Moore previously sent the message below. Because the mailing list software is currently configured to only accept mail from subscribed members of the list, the mail was rejected. We are working on having Merit modify the mailing list configuration to forward rejected mail to the WG chairs, but in the meantime, I enclose a copy of Keith's mail below. I am preparing a reply to the points he raises, and should have it ready shortly. ------------------------------------------------------------------------ Subject: comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt From: Keith Moore Date: Thu, 26 Jul 2001 19:10:40 -0400 These comments are in response to the Last Call request. (This is a bad time for a Last Call, as folks are typically quite busy now. So I hope the Last Call deadline is extended for a couple of weeks past the London IETF meeting.) 1. Applicability 1.1. Intended Purpose My first set of comments have to do with the intended purpose of IPv4 link-local addresses. (Some of them apply to IPv6 link-local addresses also, but obviously those cannot be addressed in the context of this document.) Link-local addresses are obviously valuable, for reasons implied in the Introduction and Abstract. They allow hosts on an isolated network to begin communicating (assuming their applications can discover one anothers' addresses) without explicit setup and without support (e.g. DHCP, DNS) that would be present in a more sophisticated network. However, there are some limitations also that should be mentioned: - poor scalability - This technique works well only for small, isolated networks, and connections of short duration. As the number of ad hoc network participants gets larger the network overhead due to address defense gets higher, and the liklihood of address collisions gets higher. Along with that the liklihood of having connections torn down due to address collisions also increases. networks of up to 100 hosts are probably okay, but after 1000 hosts the address collisions start becoming a significant factor in reliability. (actually, having an explicit design parameter upper bound on # hosts per link using link-local addresses would be a very good idea - it would let us analyze the probability of various kinds of undesirable situations - broadcast storms, broken connections, etc - and it might be that there is a need to discourage hosts from using link-local addresses if they find they're on a large network.) - reduced reliability - The need to cease using addresses when collisions occur means that applications using link-local addresses will generally be less reliable than applications using stable addresses. - limited applicability - Link-local addresses are inherntly only usable on the local link, and are not a solution for anything that needs to be accessable from outside that link, or to access outside devices. Consequently, link-local addresses should be used sparingly, or for special purposes by applications that are aware of them. However this document offers no guidance to application authors regarding appropriate (or inappropriate) use of link-local addresses. I believe this document needs to expand its Applicability section to include not only link-level considerations, but also to specify reasonable expectations for use of link-local addresses by applications. 1.2. Security claims In a couple of places this document makes claims that use of link-local addresses provides a security benefit. Such claims cannot be supported in general, and we should not encourage the use of locally-scoped addresses as a security mechanism. (actually, we should actively discourage such notions) - It's unrealistic to assume that chosen security boundaries and network topology will conveniently coincide. A home network user will still want to print from a PDA that is connected to a wide area wireless network (whether he is at home or not), and he'll want to be able to view the image from his home babycam from that same PDA whether he's at home or not. - Link-local addresses *will* be routed from one network to another even if we prohibit this. Some people will find this useful and ignore our prohibitions; others will fail to configure their routers appropriately (admittedly, the TTL rules help a lot here). - It's fairly obvious that this mechanism is being designed for use in ad hoc networks of moderate size (say 100 or even 1000 hosts). Under those conditions, the threat potential is sufficiently large that it's not reasonable for a network- accessible device to ignore security issues. Even a single host on a wireless link (or bridged to a wireless link) has to cope with myriad security threats. The idea that a simple host can avoid addressing security is just a dream. - Even if the addresses will not be routed, experience indicates that most general-purpose hosts are easily compromised. A single Windows box on a home network that is attached to the Internet will suffice to give an attacker connectivity with all devices on that local network, even if they only use link-local addresses. (and such devices are easily autodiscovered by watching for their ARP requests...) - The End-to-End principle argues that hosts need to be responsible for their own security just as they need to be responsible for recovery of data loss, end-to-end message integrity, etc. Device and application vendors will want to claim that link-local addresss give them a justification to ignore security issues in their products. We should not lend support to such claims. Even if you argue that simple end devices shouldn't have to implement strong authentication (I do not agree but IMHO it's reasonable to have that discussion) and that such security should be provided by the network, link-local addresses are neither a sufficiently robust nor a sufficiently flexible security mechanism for this purpose. The problem with the document can be fixed by removing the security claims from this document, and by adding some disclaimers about link-local addresses NOT being a security mechanism to the Security Considerations section. I don't know how to solve the problem of naive implementors (or for that matter, naive consumers) 1.3. Missing pieces It seems unlikely that link-local addresses by themselves will significantly enable existing applications, for instance, that expect to look up the names of their peers using DNS. (yes, applications can often be configured to use IP addresses, but applications that are looking for named services will have a hard time finding them.) If link-local addresses are being proposed in the context of a broader solution with other pieces, it might help to state those assumptions. If nothing else, it might help to state that there are missing pieces (even if they're for further study). 2. Impact on Applications The document says little or nothing about the impact of link-local addresses on applications. It's important to consider both the effect on applications that aren't aware of link-local addresses, and on those that are aware of them. One can argue that without link-local addresses there would be no communications at all under certain circumstances, and that a somewhat-less-reliable communications capability is preferable to no communications capability at all. This is true - provided that link-local addresses do not decrease the reliability of communications when better capabilities would otherwise be available. So one principle might be that the existence of a communications capability using link-local addresses should not impair operations when other capabilities are available. 2.1 Non-aware Applications A non-aware application that uses a link-local address as a source or destination address may have problems for any of several reasons: 1. the address gets changed without warning, perhaps in mid-connection 2. the address is only usable in local contexts, even after the network has (re)joined the rest of the Internet For example, - A non-aware host may see multiple DNS A records for a service and (not knowing any better) choose a link-local address, even though that address is less stable/reliable than one of the alternatives. (that address might even "look" better to a clever application, since the host will have a local interface to the same network) I don't have a good solution for this. But I'll note that there are numerous issues associated with putting link-local addresses in DNS; it's not at all clear that this is doable in a reasonable fashion. If you can solve the problems assocaited with putting link-local addresses in DNS you can probably set up a DHCP server and assign more stable addresses. - A distributed application may advertise its link-local address to its peers as a rendezvous point. But that address may be changed without warning, and that address may not be usable from other points in the network. I don't have a good solution for this. - Another problem is that for a host with multiple interfaces, there may be multiple, reachable, destinations with the same link-local address. Non-aware applications are likely to assume that all reachable destinations can be uniquely distinguished by destination address alone (this is generally true even for NAT-aware applications). Few existing applications bother to look at the source address assigned by the operating system, or to distinguish their peers by both source and destination address. I'm not sure how to fix this either, but it should at least be documented. The best fix I can think of is that hosts with multiple interfaces would only allow non-aware applications to use link-local addresses on a single, designated interface. Another fix is for hosts with multiple interfaces to relay link-local claim/defend messages to other interfaces, in order to ensure that such addresses are unique. 2.2 Aware applications Applications that are aware of link-local addresses can presumably choose if and when to use them as either source or destination addresses. However, to do this effectively probably requires some support from the socket API which is currently missing. An application can distinguish link-local addresses from other addresses, and it can explicitly choose a source address using bind(), but it has no way to say "use the best non-link-local address that is available", or for that matter "use the best link-local address that is available". It would be bad if different OS vendors were to implement this in different ways. 3. Impact on Operations 3.1 Timer hazards The claim/defend protocol appears to have a flaw which will cause it to work very suboptimally, or not at all, for a large number of hosts on a single Ethernet which are started at the same time (as in after a power failure). If the hosts all send their probes at the same time, numerous collisions will result, causing requests and responses to get dropped due to too much contention for the medium. Since those hosts will retry at fixed intervals, the collisions will with high probability happen again at the retry interval. Even if the hosts don't quite start at the same time, if they start their retry timers *after* failure of a transmission to produce a response, they will tend to "sync up" - because all hosts see more or less the same periods during which the Ethernet cannot be accessed, if they restart their timers after their responses are not heard, they will all end up restarting those times are approximately the same time. This could be addressed by varying the retry interval from one host to another, and by starting retry timers *before* sending an ARP request. For instance, the host's chosen address could be used as the seed of a pseudo-random number generator, the output of which would determine the delay to the next retry. The retries would not be uniformly spaced apart, but would be spread out over time. This could be combined with exponential decay if that were considered desirable. 3.2 When to use link-local addresses Since link-local addresses do impact the network (significantly if they are a lot of hosts using them), perhaps there should be some well-defined conditions under which link-local addresses should NOT be claimed or used? for instance, a host with a statically assigned address doesn't need a link-local address unless it's talking to a host that only has a link-local address. similarly for a host that can get an address with DHCP. maybe hosts shouldn't claim a link-local address until they find out that they need one. 4. overall impact This is just one of many proposals that can (depending on how you look at it) change fundamental assumptions in the Internet architecture, or reflect changes in those assumptions that have already been made. Some will argue that DHCP has already caused applications and to assume that addresses are volatile, and that NATs have already caused applications to assume that addresses are not gloablly usable. To some extent this might be true, and yet if we were to insist that all applications adopt these assumptions the network would be much less useful than we have come to expect. At a minimum when we make changes like this it seems important to consider what long-held assumptions are being challeged, and what effects these changes might cause for current and future applications. It also seems important to consider whether such changes can be made in a way that is less disruptive both to applications and to Internet flexibility. The Internet was designed 30 years ago for very different conditions, so some amount of change is inevitable. The danger is that these changes will be made in a piecemeal fashion and without considering the global effects of apparently localized changes. So if it seems like I've gone over this with a fine-toothed comb, that's why. I think ad hoc networks are incredibly useful, but I am not sure that we understand how to build them without affecting existing applications, or that we know how to make ad hoc networks coexist in the same address and protocol space with the global Internet. -------------------------------------------------------------------------- comments on specific portions of the text follow: section 1.0: A host need not implement a DHCP client in order to use a link-local address. True, but that host might not be able to communicate with other hosts on the same network unless those hosts also use link-local addresses. section 1.2: Two hosts are considered to be on the same link if, when one host sends packets to the other, the entire link-layer packet payload arrives unmodified. In particular, any device forwarding a packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT modify any part of the IP header. This starts out being a definition of "on the same link" and ends up making what looks like a (retroactive) requirement on packet forwarders. It's not clear whether the latter statement is meant to be a clarification of the definition of "on the same link" or if it's really meant to impose a new requirement on devices that aren't aware of, and don't implement, this protocol. I think it's the former, but if that's true, it needs to be reworded, and use of MUST NOT is not appropriate. If the latter is intended, it needs wider review. I don't think the zeroconf group can unilaterally impose requirements on routers and bridges. What I might say is that this is a fundamental assumption behind the v4 link-local address mechanism; and unless this condition is met, link-layer addressing cannot be expected to work correctly. section 1.3: Implementations of IPv4 link-local address autoconfiguration MUST expect address collisions, and MUST be prepared to handle them gracefully by automatically selecting a new address whenever a collision is detected, as described in Section 2. Unless you very carefully work out the details so as not to interfere with existing applications, this requirement on "implementations of IPv4 link-local address autoconfiguration" appears to also extend to applications. In other words, applications that expect to work in an environment using link-local addresses MUST be able to survive address changes. (but how to do so without some other naming system?) section 1.5: Another example of why it is beneficial for hosts to maintain a link- local address in addition to other addresses is that there may be networks where some of the hosts have only a link-local address. true so far, but... For example, a user with a wireless home network may have a laptop computer and an IP printer. The laptop computer may have both a self-configured link-local address and a DHCP-configured global address. The printer, in contrast, may have only a link-local address, because the user does not need (or want) the printer to be globally addressable. this is a poor example, because it suggests using link-local addresses (and the absence of global addresses) as a security mechanism. also, it's perfectly reasonable to want a printer to be globally accessible - after all, that's what a fax machine is. to clarify, a host that only needs a link-local address to do its job need not be assigned a global address. but we don't want to encourage this as a mechanism for enforcing security or access policy. (whether it's reasonable for certain appliances to use only link-local addresses, and have no provision for other kinds of addresses, is a different question. I don't think we should assume a priori that this is reasonable) section 2.1: if a link-local address is (usually) derived from some persistent per-host identifier then this can serve as a (coarse) identifier for the host, and perhaps (if the host is assigned to a user) for that user. this is not a problem if link-local addresses never escape the local net - after all, the MAC address is also visible from the local link. however, it might be a good idea to recommend that applications that are aware of link-local addresses do not expose them to the outside. this might just be a nit, but it's one of the issues that comes to mind every time someone suggests using a persistent identifier. section 2.2: see my comments above. fixed-length timers between broadcasts are an invitation to broadcast storms. section 2.4: this section is worded as if a 'host' decides the source address, but sometimes the application decides. 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 host does not have a link-local source address, then it MAY choose to ARP for the destination address and then send its packet, with a routable source IP address and a link-local destination IP address, directly to its destination on the same physical link. is there any way that a host with only a link-local IP address would know how to reply to that routable IP address? is it just expected to treat the entire link as a /32 and ARP for it? what if it has more than one interface? section 2.5: okay, here we have several cases where zeroconf is trying to dictate the behavior of things that don't know about link-layer addresses, and don't need to conform to this spec. Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 255. Any host receiving an IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST discard the packet if the TTL in the IP header is not 255. An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IP header. these appear to be intended to apply to all hosts, whether they implement link-local addresses or not. it's reasonable to require this of hosts that implement this spec, maybe not so reasonable (or realistic) to require this of all hosts. if nothing else, if you're imposing new requirements on hosts, they need to be made very visible - not buried within a spec about link-local addresses. This restriction also applies to multicast packets. IP packets with a link-local source address MUST NOT be forwarded off the local link even if they have a multicast destination address. again, quite reasonable to apply to hosts that implement this protocol. not reasonable to apply to every multicast router. Similar considerations apply at layers above IP. For example, DNS Resource Records containing link-local addresses SHOULD NOT be sent to hosts outside the link to which those link-local addresses apply. now you appear to be imposing constraints on DNS implementations. Automatically generated web pages SHOULD NOT contain links with embedded link-local addresses if those pages are viewable from hosts outside the local link where the addresses are valid. now you appear to be imposing constraints on HTTP servers. I think it would be better if as many of these as possible were re-stated as operational recommendations, rather than, or in addition to, constraints on implementations. e.g. rather than saying that all IPv4 hosts should discard packets from 169.254/16 with TTL != 255, you might recommend that border routers be configured to discard such packets. and rather than saying that hosts should not send packets with destination addresses in 169.254/16 to routers, maybe you should say that routers should be configured to black-hole them. rather than saying that DNS servers should not expose 169.254/16 addresses, say that people should not put those address into DNS servers if they can be exposed to the outside (probably they shouldn't do it at all!). similarly for web servers. the last thing we need is to require all layers of the protocol stack to be aware of link-local addresses. (bottom page 9 - top of page 10) The designers of these devices assume that they will communicate only with other local devices, and implement a degree of security appropriate for that expected environment. they may indeed assume this. but that doesn't mean it's reasonable to assign a link-local address to such devices and expect that this provides security, and we shouldn't support their claims if they do this. realistically, the scope of a link is large enough that you cannot ignore security issues or (especially in wireless networks) assume that adequate security is provided by the medium. a USB mouse or SCSI disk that doesn't require authentication might be one thing; an insecure device on 802.11 or even wired Ethernet is quite another. This does not mean that link-local devices are forbidden from communicating outside the local link. IP hosts that implement both link-local and conventional routable IP addresses may still use their routable addresses without restriction as they do today. Extremely simple IP devices that implement only a link-local address may also communicate with hosts outside the local link, provided that such communication is mediated through a device capable of enforcing appropriate security controls. For example, a home heating system could be controlled via a Web server on the local network, where the Web server uses cryptographic methods to verify the authority of the remote user, and then uses link-local communication on the local network to communicate commands to the heating system's thermostat. while there's nothing incorrect about what is said here, the implication is that it's acceptable for devices with only link-local addresses to not have security - and that's simply not correct. It should be understood that this mediated communication is not mandatory; it is an option afforded to designers of very simple devices who wish to implement only a link-local address and thereby simplify their security assumptions. and this makes the incorrect assumption even more explicit. section 3.2: Some operating systems have networking APIs that allow applications to specify network interfaces by name, index value, or other local identifier, and to identify interfaces this way both for incoming and outgoing packets/connections. For operating systems that have this capability (and have application software that makes use of it) it is sufficient to configure all interfaces with a single common IPv4 link-local address, and defend that address on all interfaces. this fails if multiple interfaces are connected to the same link. (and there are valid reasons for doing this) however as long as the host has the capability to assign different addresses to the different interfaces, it can start out assuming that they're the same, and respond to its own ARP messages, as long as it ends up with different addresses :) a host for which it's impossible for multiple interfaces to connect to the same link (because they're inherently different types of link that cannot reasonably be bridged together) can get away with this. section 3.3.2: Networking implementations that only allow the destination address to be specified should limit themselves to configuring only one interface for link-local addressing this might apply equally to non-aware applications, since the application doesn't know that it needs to bind the source address. section 8: this section is missing a great deal, and needs a lot of work. Keith Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Sep 10 05:15: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 ESMTP id FAA07647 for ; Mon, 10 Sep 2001 05:15:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2537891210; Mon, 10 Sep 2001 05:16:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4F6B91247; Mon, 10 Sep 2001 05:16: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 AD79B91210 for ; Mon, 10 Sep 2001 05:16:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AC9A5DDC9; Mon, 10 Sep 2001 05:16:13 -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 86FF35DDA8 for ; Mon, 10 Sep 2001 05:16:12 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id CAA16710 for ; Mon, 10 Sep 2001 02:16:11 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 10 Sep 2001 02:16:08 -0700 Received: from [206.111.147.149] (vpn-gh-1041.apple.com [17.254.140.16]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id CAA14878; Mon, 10 Sep 2001 02:16:07 -0700 (PDT) Message-Id: <200109100916.CAA14878@scv1.apple.com> Subject: Re: comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Mon, 10 Sep 2001 02:16:07 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Keith Moore" , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >These comments are in response to the Last Call request. Thank you for your detailed comments. I will attempt to answer them here. >1. Applicability > >1.1. Intended Purpose > >My first set of comments have to do with the intended purpose of >IPv4 link-local addresses. (Some of them apply to IPv6 link-local >addresses also, but obviously those cannot be addressed in the >context of this document.) > >Link-local addresses are obviously valuable, for reasons implied >in the Introduction and Abstract. They allow hosts on an isolated >network to begin communicating (assuming their applications can >discover one anothers' addresses) without explicit setup and without >support (e.g. DHCP, DNS) that would be present in a more sophisticated >network. However, there are some limitations also that should be >mentioned: > >- poor scalability - This technique works well only for small, > isolated networks, and connections of short duration. As the > number of ad hoc network participants gets larger the network > overhead due to address defense gets higher, and the liklihood > of address collisions gets higher. Along with that the liklihood > of having connections torn down due to address collisions also > increases. networks of up to 100 hosts are probably okay, but > after 1000 hosts the address collisions start becoming a > significant factor in reliability. I disagree. In the normal case, once a host has selected an address, it will keep that address indefinitely. This is at least as reliable as today's hard-wired Ethernet networks using manual or DHCP-assigned addresses. Any new host joining the network will probe an address before using it, thereby ensuring that it does not interfere with existing hosts. The only time when undetected conflicts have to be resolved is when two previously separate segments are bridged together. I would argue that this is (a) rare, and (b) even on a conventional managed network, bridging previously separate networks together while hosts are running usually entails some degree of chaos. The difference here is that when two hosts find they inadvertently have the same IP address, instead of failing silently and causing all kinds of confusion to the users, the hosts automatically recover and continue working. > (actually, having an explicit design parameter upper bound on # hosts > per link using link-local addresses would be a very good idea - it > would let us analyze the probability of various kinds of undesirable > situations - broadcast storms, broken connections, etc - > and it might be that there is a need to discourage hosts from using > link-local addresses if they find they're on a large network.) I agree that the draft could make a specific statement in this regard. I propose adding the following new text to the draft: This protocol is designed for links of no more than 1300 hosts. A host connecting to a link that already has 1300 hosts, selecting a link-local address at random, has a 98% chance of selecting an unused link-local address on the first try. A host has a 99.96% chance of selecting an unused link-local address within two tries. The probability that it will have to try more than ten times is about 1 in 10^17. This does not mean that a host should attempt to count the number of other hosts on the link and refuse to operate if it finds there are more than 1300. It does mean that network operators with more than 1300 hosts on a single link may want to consider dividing that single link into two or more subnets. >- reduced reliability - The need to cease using addresses when > collisions occur means that applications using link-local addresses > will generally be less reliable than applications using stable > addresses. I disagree. When two hosts on the same link are using the same IP address, no applications work reliably, no matter how the addresses were assigned. The requirement in this draft to automatically select a new address as soon as the conflict is detected restores working operation as soon as possible. In contrast, two hosts with the same manually-assigned address will fail to work until a human intervenes to correct the situation. In the case of a device like the Apple AirPort Base Station, which has no screen or keyboard, the only way for a human to intervene to correct the misconfigured address is via the network, which is difficult if the network is not working. Having the device automatically select a new address automatically automatically restores its ability to communicate on the local link. >- limited applicability - Link-local addresses are inherntly only > usable on the local link, and are not a solution for anything > that needs to be accessable from outside that link, or to access > outside devices. I agree, but I feel that the title of the draft, "Link-Local Addresses", and numerous comments about ignoring packets from outside the local link, non-forwarding, etc., make this very clear to the reader. Is there specific additional text you would like to see in the draft? >Consequently, link-local addresses should be used sparingly, or >for special purposes by applications that are aware of them. >However this document offers no guidance to application authors >regarding appropriate (or inappropriate) use of link-local addresses. I believe that Section 2.4, "Source Address Selection", gives guidance in this respect: If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. In the case where two hosts on the same link each have both a link- local address and another address configured via some other means, the host may use either its link-local source address or a routable address, depending on which is expected to be more likely to remain stable for the expected lifetime of the connection. Note that link- local addresses may be forced to change over time, as described in Section 2.3. >I believe this document needs to expand its Applicability section >to include not only link-level considerations, but also to >specify reasonable expectations for use of link-local addresses >by applications. Can you suggest specific text? I believe most applications can use link-local addresses without any special awareness. If I type "epson.local.arpa" into my Web browser to access the configuration page for my Zeroconf Epson ink-jet printer, and multicast DNS correctly looks up a link-local address for the printer, the Web browser has no reason to (and SHOULD NOT) treat that address any differently to any other address. I would say the same is true of just about any application. How many current applications give special treatment to Net 10 addresses? I suspect most do not, and do not need to. Perhaps a few specialized applications should -- a tool that generates externally visible web pages should try to avoid putting links on those pages that aren't usable from outside the company's internal network. >1.2. Security claims > >In a couple of places this document makes claims that use of link-local >addresses provides a security benefit. Such claims cannot be supported >in general, and we should not encourage the use of locally-scoped >addresses as a security mechanism. (actually, we should actively >discourage such notions) I tried to be very careful about how this was worded. Evidently not careful enough. I did not say that link-local devices should have *no* security, just that link-local devices should "implement a degree of security appropriate for that expected environment." If you can suggest specific text I'd be grateful. One of the goals of Zeroconf IP is to provide a viable replacement for all the USB protocols, FireWire protocols, IrDA protocols, BlueTooth protocols, etc., and help us escape that Tower of Babel move closer to an all-IP world. Vendors of USB printers currently implement little or no security, because they assume that the number of devices that can launch an attack against those printers is very small, and physically localized. If we could achieve a world where every $49 ink-jet printer supports link-local Zeroconf IP, then it becomes a smaller step to enhance those printers to include global IP and security as well. If we erect unreasonable barriers to printer vendors considering supporting link-local Zeroconf IP, then they will continue to use only serial ports, parallel ports, USB, BlueTooth, etc. >- A home network user > will still want to print from a PDA that is connected to a > wide area wireless network (whether he is at home or not) I agree. I'd love to have a $49 ink-jet printer that supports secure printing over IP from anywhere in the world, but the truth is that today's $49 ink-jet printers don't support IP at all. They only use USB, they have no security, and if you're not at home you can't use them. How do we get from today's world to our common goal of ubiquitous secure worldwide IP everywhere? >- Link-local addresses *will* be routed from one network to > another even if we prohibit this. Some people will find this > useful and ignore our prohibitions; others will fail to configure > their routers appropriately (admittedly, the TTL rules help a > lot here). Some people accidentally turn on Windows printer sharing with no password, thereby giving the world access to their local USB printer. Is this any different? If devices choose to implement the TTL=255 check, they are pretty safe from external packets brought in by a conventional IP router. If the router is correctly configured to not forward inbound 169.254/16 packets, they are pretty safe. With sufficient misconfiguration, even the most secure system can be made insecure, so it is unsurprising that link-local addressing can be similarly subverted. >- It's fairly obvious that this mechanism is being designed > for use in ad hoc networks of moderate size (say 100 or even > 1000 hosts). Under those conditions, the threat potential is > sufficiently large that it's not reasonable for a network- > accessible device to ignore security issues. Even a single > host on a wireless link (or bridged to a wireless link) > has to cope with myriad security threats. The idea that > a simple host can avoid addressing security is just a dream. The mechanism is also designed for one PC connected to one printer, using a crossover Ethernet cable instead of a USB cable. The difference is that with the Ethernet printer, you *can* connect it to a network of a thousand hosts if you want, at which point you probably start bugging the printer vendor for some security. With the USB printer you don't have that choice. >- Even if the addresses will not be routed, experience indicates > that most general-purpose hosts are easily compromised. A > single Windows box on a home network that is attached to the > Internet will suffice to give an attacker connectivity with all > devices on that local network, even if they only use link-local > addresses. (and such devices are easily autodiscovered by > watching for their ARP requests...) The same thing applies to all the devices on the USB bus. I argue that we have more hope of preaching the doctrine of end-to-end security in the IP world than we do in the USB world. >- The End-to-End principle argues that hosts need to be responsible > for their own security just as they need to be responsible for > recovery of data loss, end-to-end message integrity, etc. No argument. Hence the recommended TTL=255 check, which is reduces dependence on other devices to do the right thing. (Note: The language in the draft may have to be modifed somewhat for compatibility with older Windows systems, but the principle remains.) >Device and application vendors will want to claim that link-local >addresss give them a justification to ignore security issues in their >products. We should not lend support to such claims. No argument. No one should ignore security issues, but can we provide them with an environment where the security threats are a little less daunting? If every product has to withstand arbitrary attack from the whole world, many products are simply not viable on IP, and will continue to use their current Tower of Babel protocols. >1.3. Missing pieces > >It seems unlikely that link-local addresses by themselves will >significantly enable existing applications, for instance, that >expect to look up the names of their peers using DNS. (yes, >applications can often be configured to use IP addresses, but >applications that are looking for named services will have a >hard time finding them.) In fact, with self-assigned randomly-chosen addresses, hand-configuring devices with dotted-decimal IP addresses ceases to be viable. Link-local addresses absolutely require a naming protocol (or shouting dotted-decimal IP addresses across the room). Currently on Mac OS, name lookup is done with AppleTalk NBP. (You find a file server in the Chooser using AppleTalk NBP, but then connect to it using a TCP connection to its IP address, which may be a self-assigned link-local address.) Currently on Windows, name lookup is done with NetBIOS. Ideally, we want to replace both with Multicast DNS. SLP can also allow hosts to learn useful address information in this situation. Name-to-address mapping is one of the four Zeroconf Requirements, as specified in draft-ietf-zeroconf-reqts-09.txt. I don't believe that a standards-track RFC at this time should discuss Multicast DNS when Multicast DNS is in its infancy and it is not at all clear how things will eventually work out. Can you suggest specific text? >2. Impact on Applications > >The document says little or nothing about the impact of link-local >addresses on applications. It's important to consider both the >effect on applications that aren't aware of link-local addresses, >and on those that are aware of them. > >One can argue that without link-local addresses there would be no >communications at all under certain circumstances, and that a >somewhat-less-reliable communications capability is preferable to >no communications capability at all. This is true - provided that >link-local addresses do not decrease the reliability of communications >when better capabilities would otherwise be available. The primary purpose of link-local addresses is to provide communication where otherwise there would be none. Is there specific wording you would like to see in the draft? >2.1 Non-aware Applications > >A non-aware application that uses a link-local address as a source >or destination address may have problems for any of several reasons: > >1. the address gets changed without warning, perhaps in mid-connection This is as likely with a link-local address as it is with a manual or DHCP-assigned address. That is to say, it can happen, but usually does not. Good applications should cope with this. Some applications do not cope well. >2. the address is only usable in local contexts, even after the > network has (re)joined the rest of the Internet The same thing applies with DHCP, if I move my laptop from a private network using Net 10 addresses, to a public network using global addresses. >For example, > >- A non-aware host may see multiple DNS A records for a service and > (not knowing any better) choose a link-local address, even though > that address is less stable/reliable than one of the alternatives. > (that address might even "look" better to a clever application, > since the host will have a local interface to the same network) Providing better name service APIs is a problem that is already being tackled, to solve the IPv6 "source address selection problem", which is essentially the same problem. > I don't have a good solution for this. But I'll note that > there are numerous issues associated with putting link-local > addresses in DNS; it's not at all clear that this is doable > in a reasonable fashion. If you can solve the problems assocaited > with putting link-local addresses in DNS you can probably > set up a DHCP server and assign more stable addresses. Multicast DNS doesn't use a centralized server. >- A distributed application may advertise its link-local address to > its peers as a rendezvous point. But that address may be changed > without warning, and that address may not be usable from other > points in the network. Repeating previous comments: This is as likely with a link-local address as it is with a manual or DHCP-assigned address. That is to say, it can happen, but usually does not. Good applications should cope with this. Some applications do not cope well. > I don't have a good solution for this. > >- Another problem is that for a host with multiple interfaces, > there may be multiple, reachable, destinations with the same > link-local address. Non-aware applications are likely to > assume that all reachable destinations can be uniquely > distinguished by destination address alone (this is generally > true even for NAT-aware applications). Few existing > applications bother to look at the source address assigned by > the operating system, or to distinguish their peers by both > source and destination address. The same problem applies for Net 10 addresses today, where a multi-homed host can have connections into multiple different Net 10 address spaces. The same problem also applies for IPv6 hosts using link-local or site-local addresses. My preferred solution here is that the networking stack should provide a "connect-by-name" API, which allows the OS to handle all these address selection and interface selection problems transparently on the application's behalf. > I'm not sure how to fix this either, but it should at least > be documented. The best fix I can think of is that hosts with > multiple interfaces would only allow non-aware applications > to use link-local addresses on a single, designated > interface. I agree that the draft could make a specific statement in this regard. I propose adding the following new text to the draft: For applications that send packets (or initiate outgoing connections) without identifying a desired source interface, by interface identifier, source IP address, or any other means, an operating system that configures link-local addresses on multiple interfaces has two choices. It can either restrict such applications to using link-local addresses on only one default interface, or it can ARP for the given destination address on all interfaces, and use the first response it gets. While clearly sub- optimal, in most cases this heuristic approach will successfully establish communication with the desired correspondent host. > Another fix is for hosts with multiple > interfaces to relay link-local claim/defend messages to other > interfaces, in order to ensure that such addresses are unique. I believe the transitive closure of this behaviour would be for every ARP packet to spread to every reachable network. Any topological loop would result in an infinite broadcast storm. >2.2 Aware applications > >Applications that are aware of link-local addresses can presumably >choose if and when to use them as either source or destination >addresses. However, to do this effectively probably requires some >support from the socket API which is currently missing. An application >can distinguish link-local addresses from other addresses, and it can >explicitly choose a source address using bind(), but it has no way >to say "use the best non-link-local address that is available", or for >that matter "use the best link-local address that is available". I would be disappointed if application writers need to care about this. I would feel that we have failed in our goal of providing local IP that provides communications functionality which is, at the API level, equivalent to today's global IP. Applications should simply specify a name to connect to, and the OS should automatically provide the best quality connection possible in the current environment. >3. Impact on Operations > >3.1 Timer hazards > >The claim/defend protocol appears to have a flaw which will cause >it to work very suboptimally, or not at all, for a large number of >hosts on a single Ethernet which are started at the same time (as >in after a power failure). If the hosts all send their probes >at the same time, numerous collisions will result, causing requests >and responses to get dropped due to too much contention for the medium. >Since those hosts will retry at fixed intervals, the collisions >will with high probability happen again at the retry interval. This is a good suggestion. I propose adding the following new text to the draft: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to two seconds, and should then send four probe packets, spaced two seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. >3.2 When to use link-local addresses > >Since link-local addresses do impact the network (significantly if >they are a lot of hosts using them), perhaps there should be some >well-defined conditions under which link-local addresses should >NOT be claimed or used? The volume of ARP traffic generated by hosts using link-local addresses is not significantly different to the volume of ARP traffic generated by hosts using any other kind of address. A host that starts up and then is fortunate enough to never need to use its link-local address sends six ARP packets on startup. It is likely to send many more ARPs than that in the course of just one hour using its other address. >for instance, a host with a statically assigned address doesn't >need a link-local address unless it's talking to a host that only >has a link-local address. similarly for a host that can get >an address with DHCP. maybe hosts shouldn't claim a link-local >address until they find out that they need one. That assumes that the host's statically assigned address is correct. One of the purposes of link-local addresses is that you can absolutely rely on them. No matter how badly configured a host's networking stack is, you should at least be able to rely on link-local addressing working sufficiently well for you to communicate with the host to correct its misconfigured networking settings. If hosts stop using link-local addresses when their configuration indicates they don't need them, you can lose this benefit in precisely the case where you need it. >4. overall impact > >This is just one of many proposals that can (depending on how you >look at it) change fundamental assumptions in the Internet architecture, >or reflect changes in those assumptions that have already been made. >Some will argue that DHCP has already caused applications and >to assume that addresses are volatile DHCP is a really a symptom, not a cause. It is the mobility of laptop computers and PDAs that have invalidated the assumption that every host needs only one fixed IP address. Sure, at the London IETF meeting we *could* all have continued using our home IP addresses using Mobile IP, but that wouldn't have been a necessary or efficient way to communicate with the local printers in the IETF terminal room. For most applications, having an IP address that is topologically appropriate for the current location is more important than every piece of hardware being branded at birth with a fixed globally unique IP address. With laptop computers and PDAs it is also no longer appropriate to assume that you shut down your device and reboot it every time you change location. My Palm V PDA hasn't been rebooted since the day I took it out of its box. >At a minimum when we make changes like this it seems important to >consider what long-held assumptions are being challeged, and what >effects these changes might cause for current and future applications. >It also seems important to consider whether such changes can be made >in a way that is less disruptive both to applications and to Internet >flexibility. I agree with this sentiment. Where I disagree is the notion that it is a backward step to provide (limited) communication where otherwise there would be no communication at all. >So if it seems like I've gone over this with a fine-toothed >comb, that's why. I think ad hoc networks are incredibly >useful, but I am not sure that we understand how to build them >without affecting existing applications I am grateful for your fine-toothed comb analysis. However, both Mac OS and Windows have had some flavour of link-local IP addressing for several years, and to my knowledge no existing application has ever had to be rewritten before it could make use of link-local IP networking. I agree that there are challenges, but not insurmountable ones. > A host need not implement a DHCP client in order to use > a link-local address. > >True, but that host might not be able to communicate with other hosts >on the same network unless those hosts also use link-local addresses. Not necessarily true. Link-local-to-routable address communication is both possible and encouraged. >section 1.2: > > Two hosts are considered to be > on the same link if, when one host sends packets to the other, the > entire link-layer packet payload arrives unmodified. In particular, > any device forwarding a packet whose source and/or destination > address is in the 169.254/16 prefix MUST NOT modify any part of the > IP header. > >This starts out being a definition of "on the same link" and ends up >making what looks like a (retroactive) requirement on packet forwarders. > >It's not clear whether the latter statement is meant to be a clarification >of the definition of "on the same link" It is trying to define the possibly slippery concept of "same link". If the IP header (or any other IP packet content) is modified before forwarding (e.g. decrementing TTL), then the packet is (by this definition) not on the same link any more. If you can provide a clearer definition of "same link", we will happily consider it. >or if it's really meant to >impose a new requirement on devices that aren't aware of, and don't >implement, this protocol. I think it's the former, but if that's true, >it needs to be reworded, and use of MUST NOT is not appropriate. > >If the latter is intended, it needs wider review. I don't think the >zeroconf group can unilaterally impose requirements on routers and >bridges. Like any standard, this one only asserts requirements on those devices that choose to implement the standard. A router that claims to conform to this standard MUST NOT forward link local packets. A router that does not claim to conform to this standard is not bound by it. Customers are free to purchase whichever kind of router they prefer. >What I might say is that this is a fundamental assumption behind the >v4 link-local address mechanism; and unless this condition is met, >link-layer addressing cannot be expected to work correctly. What do you mean by "work correctly"? Link-local, site-local, and other variants of local addressing have been "working correctly" for years. Routers that forward these packets may be annoying and a waste of bandwidth, but how do they make it not "work correctly"? >section 1.3: > > Implementations of IPv4 link-local address autoconfiguration MUST > expect address collisions, and MUST be prepared to handle them > gracefully by automatically selecting a new address whenever a > collision is detected, as described in Section 2. > >Unless you very carefully work out the details so as not to interfere >with existing applications, this requirement on "implementations of >IPv4 link-local address autoconfiguration" appears to also extend to >applications. In other words, applications that expect to work in >an environment using link-local addresses MUST be able to survive >address changes. (but how to do so without some other naming system?) The requirement to handle address changes comes from mobility, from DHCP, and from the fact that if they want to, the user can even change their manual address without having to reboot the machine. The naming system is NBP, NetBIOS, mDNS, SLP, or shouting dotted decimal IP addresses across the room, just as with manual or DHCP addresses :-) >section 1.5: > > Another example of why it is beneficial for hosts to maintain a link- > local address in addition to other addresses is that there may be > networks where some of the hosts have only a link-local address. > >true so far, but... > > For example, a user with a wireless home network may have a laptop > computer and an IP printer. The laptop computer may have both a > self-configured link-local address and a DHCP-configured global > address. The printer, in contrast, may have only a link-local > address, because the user does not need (or want) the printer to be > globally addressable. > >this is a poor example, because it suggests using link-local addresses >(and the absence of global addresses) as a security mechanism. >also, it's perfectly reasonable to want a printer to be globally >accessible - after all, that's what a fax machine is. We've covered this already, but to answer the point: Link-local addresses are one step on the road from insecure USB to global addresses and security. We can't get to the destination if we can't take the first step. >section 2.1: > >if a link-local address is (usually) derived from some persistent >per-host identifier then this can serve as a (coarse) identifier >for the host, and perhaps (if the host is assigned to a user) for >that user. this is not a problem if link-local addresses never >escape the local net - after all, the MAC address is also visible >from the local link. however, it might be a good idea to recommend >that applications that are aware of link-local addresses do not >expose them to the outside. > >this might just be a nit, but it's one of the issues that comes to >mind every time someone suggests using a persistent identifier. Would the following new text address this concern? Another reason to restrict leakage of link-local addresses outside the local link is privacy concerns. If link-local addresses are derived from a hash of the hardware address, some argue that they could be indirectly associated with an individual, and thereby used to track that individual's activities. Within the local link the hardware addresses in the packets are all directly observable, so as long as link-local addresses don't leave the local link they provide no more information to an intruder than could be gained by direct observation of hardware addresses. >section 2.4: > >this section is worded as if a 'host' decides the source address, >but sometimes the application decides. Except in very specialized cases, no normal application should ever have to make this kind of decision. > 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 host does not have a > link-local source address, then it MAY choose to ARP for the > destination address and then send its packet, with a routable source > IP address and a link-local destination IP address, directly to its > destination on the same physical link. > >is there any way that a host with only a link-local IP address would >know how to reply to that routable IP address? is it just expected >to treat the entire link as a /32 and ARP for it? Yes. This is what current implementations do. >what if it has more than one interface? Then it needs a RIP listener, or some other way to build a rudimentary routing table, just like any multi-homed host. >section 2.5: > >okay, here we have several cases where zeroconf is trying to dictate >the behavior of things that don't know about link-layer addresses, >and don't need to conform to this spec. > > Any host sending an IPv4 packet with a source and/or destination > address in the 169.254/16 prefix MUST set the TTL in the IP header > to 255. > > Any host receiving an IPv4 packet whose source and/or destination > address is in the 169.254/16 prefix MUST discard the packet if the > TTL in the IP header is not 255. > > An IPv4 packet whose source and/or destination address is in the > 169.254/16 prefix MUST NOT be sent to any router for forwarding, and > any network device receiving such a packet MUST NOT forward it, > regardless of the TTL in the IP header. > >these appear to be intended to apply to all hosts, whether they implement >link-local addresses or not. it's reasonable to require this of hosts >that implement this spec, maybe not so reasonable (or realistic) to require >this of all hosts. > >if nothing else, if you're imposing new requirements on hosts, they >need to be made very visible - not buried within a spec about link-local >addresses. I don't understand the problem. Hosts that don't claim to conform to this specification don't have to implement this. However, such hosts will not interoperate well with hosts that do conform to this specification. A host implementer could choose to ignore the fact that Class D IP addresses are conventionally used for multicast, or the fact that 224.0.0/24 is conventionally used for link-local multicast, but market forces dictate that people don't want to buy hosts that do that. There is a market for products that *do* implement the specifications published in standards-track RFCs. > This restriction also applies to multicast packets. IP packets with > a link-local source address MUST NOT be forwarded off the local link > even if they have a multicast destination address. > >again, quite reasonable to apply to hosts that implement this protocol. >not reasonable to apply to every multicast router. Well, where *are* requirements on multicast routers specified, if not in standards-track RFCs? > Similar considerations apply at layers above IP. For example, DNS > Resource Records containing link-local addresses SHOULD NOT be sent > to hosts outside the link to which those link-local addresses apply. > >now you appear to be imposing constraints on DNS implementations. No more than currently imposed by use of Net 10 or IPv6 link local addresses. Would it be better to not mention this in the draft, and leave implementers to work it out for themselves? Whenever you have private name spaces, it is helpful if names from one name space do leak across the boundary into a different name space where they are not valid. I believe it is helpful for the document to point out this inevitable fact so that all implementers are aware of it. It would be intellectually dishonest to pretend that the issue did not exist. > Automatically generated web pages SHOULD NOT contain links with > embedded link-local addresses if those pages are viewable from hosts > outside the local link where the addresses are valid. > >now you appear to be imposing constraints on HTTP servers. No more than currently imposed by use of Net 10 or IPv6 link local addresses. >e.g. rather than saying that all IPv4 hosts should discard packets >from 169.254/16 with TTL != 255, you might recommend that border >routers be configured to discard such packets. and rather than >saying that hosts should not send packets with destination addresses >in 169.254/16 to routers, maybe you should say that routers should >be configured to black-hole them. You previously argued end-to-end principles. Now you say that the two end systems should not implement their own protection against packets leaking in from outside the link, but should instead rely on the correct operation of all routers on the network to implement this protection. You previously argued that this draft could not impose requirements on routers. Now you are arguing that it should. I'm confused. >rather than saying that DNS servers >should not expose 169.254/16 addresses, say that people should not >put those address into DNS servers if they can be exposed to the outside >(probably they shouldn't do it at all!). similarly for web servers. You're assuming that a person put the addresses into a DNS server. The whole point of Zeroconf is that no person is required to configure anything. The software is entirely self-configuring, so requirements on what a person does have no place here. Likewise, you're assuming that a person typed in link-local addresses into some HTML text. This is not useful if the host doesn't have a fixed address, (and embedding IP addresses in HTML text is questionable at the best of times anyway, because few hosts have an IP address that is truly fixed over time periods of years or decades). The draft specifically says Automatically generated web pages SHOULD NOT contain links with embedded link-local addresses if those pages are viewable from hosts outside the local link where the addresses are valid. There are three salient points here: 1. Automatically generated web pages (not manually typed ones) 2. should not contain embedded IP addresses (host names are better) 3. and ESPECIALLY not embedded IP addresses that are not useful to the person (or device) reading the page. I don't see much to disagree with in that statement. > (bottom page 9 - top of page 10) > The designers of these devices assume that they will communicate > only with other local devices, and implement a degree of security > appropriate for that expected environment. > >they may indeed assume this. but that doesn't mean it's reasonable to >assign a link-local address to such devices and expect that this >provides security, and we shouldn't support their claims if they do >this. I argue that different levels of security *are* appropriate in different contexts. From the draft: For example, a typical USB mouse does not have a password, nor does it encrypt its mouse- movement data, and in most environments this is acceptable. The last thing I need is a mouse that costs $100 and doesn't work because I lost the crypto key that my computer needs to talk to it. >section 3.2: > > Some operating systems have networking APIs that allow applications > to specify network interfaces by name, index value, or other local > identifier, and to identify interfaces this way both for incoming > and outgoing packets/connections. For operating systems that have > this capability (and have application software that makes use of it) > it is sufficient to configure all interfaces with a single common > IPv4 link-local address, and defend that address on all interfaces. > >this fails if multiple interfaces are connected to the same link. >(and there are valid reasons for doing this) Why? From the draft: If a host receives an ARP packet where the 'sender hardware address' in the ARP packet is equal to *any* of the host's active interfaces, then this is not a conflicting ARP packet, and should be silently discarded. This is because a user of a multi-homed host with two Ethernet interfaces may connect both interfaces to the same Ethernet hub, in which case the two interfaces will see each other's packets, and if it did not check and realize that the apparently conflicting ARP packets were coming from itself the host could erroneously conclude that all its addresses were in conflict. Another common example is a host with both wired and wireless Ethernet interfaces, in an environment where a wireless gateway is available, but (perhaps unknown to the user) is bridged onto the same wired Ethernet. >section 8: > >this section is missing a great deal, and needs a lot of work. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Can you elaborate on what needs to be added? Thanks. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Sep 11 03:58: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 ESMTP id DAA00317 for ; Tue, 11 Sep 2001 03:58:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 166769124F; Tue, 11 Sep 2001 03:57:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D239F91252; Tue, 11 Sep 2001 03:57: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 DC6829124F for ; Tue, 11 Sep 2001 03:57:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC9F05DDDC; Tue, 11 Sep 2001 03:57:55 -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 0E55D5DD97 for ; Tue, 11 Sep 2001 03:57:55 -0400 (EDT) Received: from mailgate2.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 AAA09256 for ; Tue, 11 Sep 2001 00:57:53 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 11 Sep 2001 00:57:52 -0700 Received: from [206.111.147.149] (vpn-gh-1041.apple.com [17.254.140.16]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f8B7vpw08491; Tue, 11 Sep 2001 00:57:51 -0700 (PDT) Message-Id: <200109110757.f8B7vpw08491@scv2.apple.com> Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Tue, 11 Sep 2001 00:57:51 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Erik Nordmark" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Thanks for your comments Erik. >The text in section 1.2 which attempts to define link seems to exclude >all link layers that modify some part of the link-layer packet. >This clearly excludes MPLS and might exclude source routing token ring >as two examples. The intention was to state that the link-layer *payload* (IP header and up) should not be modified, not the link-layer header. >Why not just refer to or copy the definitions of "link" and the terms >it depend on from RFC 2460? I find the definition in RFC 2460 somewhat self-referential: link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets... This defines "link" in terms of "link layer", but then leaves the term "link layer" undefined. It gives a list of examples, but a list of examples is not a definition. I actually think that in the most precise definition of "on the same link" for the purposes of IP is the one the draft gives: two hosts are "on the same link" if and only if IP packets sent from one to the other arrive with no part of the IP packet modified. If the TTL is decremented en route, they are not on the same link. If the IP addresses are rewritten by a NAT box or TCP port numbers are changed or the IP packet is modified in any other way, then the hosts are not communicating directly on the same link. The reason the draft defines this in terms of link-layer payload instead of IP packets is that ARP packets must also arrive unmodified, not just IP packets. >And presumably the definitions belong in section 1.1 and not 1.2. I propose putting the following modified text in Section 1.1: This document describes link-local addressing, for IP communication between two hosts on a single link. Two hosts are considered to be on the same link if, when one host sends packets to the other, the entire link-layer packet payload arrives unmodified. The link-layer *header* may be modified, such as in Token Ring Source Routing [IEEE8025], but not the link-layer *payload*. In particular, any device forwarding a packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT modify any part of the IP header or IP packet body. This means that the packet may pass through devices such as Ethernet switches, bridges, hubs or repeaters, but not through devices like IP routers that modify the IP header. I am aware that by this strict definition, a Token Ring and an Ethernet segment bridged together do not qualify as a single link, because the bridge modifies the contents of ARP packets. Bridges do this to work around the ubiquitous bug that Token Ring hosts typically put their six-byte IEEE MAC addresses into the ARP packet with the bit order reversed from the normal canonical order. When packets go to another Token Ring host this bug goes unnoticed, because receiving hosts misinterpret received ARP packets the same way, thereby nullifying the effect of the bug. For packets that cross the bridge, the bit order of the hardware addresses within the ARP packets has to be flipped, or the ARP packets from the Token Ring side would be invalid and meaningless on the Ethernet side of the bridge. This is an unreliable hack. Networks bridged this way to do not qualify to be called a single link. Do Token Ring-to-Ethernet bridges also flip the bit order of the chaddr field of DHCP packets? I think not. What about the Client ID option of DHCP packets, in the case where the Client ID option carries a six-byte MAC address (but not when the Client ID is a user-entered string)? What about all the other places where six-byte MAC addresses can be embedded in packets that the bridge doesn't know about? This kind of bridging is fragile and unreliable, and while it can certainly be made to work in some situations, this draft should not promise to support it. >I don't understand what the text in section 2.1 about > This means that even without using any other > persistent storage, a host will usually select the same link-local > address each time it is booted [...] >relates to the fact the you refer to RFC 1750 which says "It recommends >the use of truly random hardware techniques ..." > >If you have truly random hardware techniques then you would *not* get the >same random number on each boot. So what is the relationship really with >RFC 1750? The reference to RFC 1750 was put in at the request of Donald Eastlake on 31st May this year. I do not have a strong opinion about it myself. Would you prefer to see that reference removed? >Section 2.1 claims that 169.254/16 is assigned by the IANA for this >purpose. I didn't think it had a reference to the draft so I went to >look. Turns out it isn't explicitly listed in >http://www.iana.org/assignments/ipv4-address-space > >We need to make sure we have the correct instructions for the IANA >which might include transferring the ownership of the address block >to refer to this spec. # whois 169.254@whois.arin.net [whois.arin.net] IANA (NETBLK-LINKLOCAL) Internet Assigned Numbers Authority 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 US Netname: LINKLOCAL Netblock: 169.254.0.0 - 169.254.255.255 Coordinator: Internet Corporation for Assigned Names and Numbers (IANA-ARIN) res-ip@iana.org (310) 823-9358 Domain System inverse mapping provided by: BLACKHOLE.ISI.EDU 128.9.64.26 BLACKHOLE.EP.NET 198.32.1.116 Record last updated on 30-Aug-2000. Database last updated on 8-Sep-2001 23:09:15 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. I have contacted res-ip@iana.org to see what needs to be done to correct this. >The algorithm in section 2.3 seems to force an unneeded IP address >change if a single packet is lost. >A is trying to use address X, which is already in use by B. >A sends arp request. B sees it and responds with a gratuitus reponse. >This response is lost. >A sends the arp request again after 2 seconds. (It is supposed to do this 4 >times). B sees it. Now the rules say that it MUST cease to use the address. >This doesn't seem very robust. I think you are confusing sections 2.2 and 2.3. The four ARP packets two seconds apart are in Section 2.2, "Claiming a Link-Local Address". Also, they are ARP probes, not ARP requests. ARP probes are benign. They have zero source address, and cause no harm to any other host on the network. The forced reconfiguration in Section 2.3 only comes into effect if the ARP probing process failed, and two hosts are trying to use the same source IP address (for example when two separate network segments are later joined). Forced reconfiguration is rarely needed, and when it is needed, it is the quickest (and only) way to restore working communication. Two hosts cannot use the same IP address and have reliable communication. Whether or not an ARP packet may occasionally be lost makes no difference here. If two hosts are trying to use the same source IP address, reliable communication will not be restored until at least one of them stops using that address. >Have both Apple and Microsoft implemented exactly this? Apple has implemented exactly this. I can't speak for Microsoft. > If the destination address is the 255.255.255.255 broadcast address > or a multicast address, then the host may use either its link-local > source address or a routable address, as appropriate. >Huh? Sending to a global multicast address with a link-local source >is a good idea? >How about allowing either for broadcast or multicasts to 224.0.0.0/24 >but mandating global source for other multicasts. For example, hosts may want to use SSM addresses. There are no SSM addresses in the 224.0.0.0/24 prefix. What if you have a MADCAP server on the network, but no DHCP server, so the hosts are using link-local addresses? Is the MADCAP server then restricted to assigning only multicast addresses in the 224.0.0.0/24 prefix? Is a MADCAP server allowed to assign multicast addresses in the 224.0.0.0/24 prefix? What about the Zeroconf couterpart to MADCAP (ZMAAP). Can it also only assign multicast addresses in the 224.0.0.0/24 prefix? I did consider saying that link-local source addresses may not send to multicast addresses outside 224.0.0.0/24, but I fear (though I don't know for certain) that this would be overly restrictive. >Section 2.5 a few paragraphs that seem to endorse the construction of >boxes that depend solely on the IP addresses being used for some notion >of weak security. As we all know bridges to wireless media breaks >any such assumptions. I don't think the IETF should be endorsing such >weak security in standards track documents. >How about making 2.5 state the protocol mechanisms and the >in the security considerations section state that >1) the protocol prevents packets using link-local addresses from being >injected > outside the link through the use of a ttl 255 check, and 2) users of >link-local addresses should be aware of the existence of > bridges e.g. to wireless media that make the use of ttl 255 a very > weak security mechanism. I was very careful not to say that devices should have no security. I said that designers should implement a degree of security appropriate for the expected environment. Security wording is always tricky. If you can propose specific wording I would welcome that. >The way I view it section 3.2 talks about constraints when the APIs >allow applications to specify and retrive interface information, and >section 3.3 talks about issues when such APIs are not available. >But the section titles doesn't match this so I'm confused about the >intent. Section 3 covers multi-homing issues. Section 3.1 covers one choice for multi-homing -- don't do it. Section 3.2 covers another option -- a single address shared between all interfaces -- and describes what is necessary to do this. Section 3.3 covers an alternative option -- a different address on each interface. Can you suggest better titles? >Section 3.2 recommends using a single link-local address across >multiple interfaces but it doesn't explain why this is better >or simpler than using different ones. I think it can be worse >in some cases. If a conflict appears on one interface forcing >the host to pick a new link-local on that interface it would be >nice if that didn't effect connections using link-local >addresses on all interfaces. 1. Address collisions are rare, so in practice this is not an issue. 2. If it were to be an issue, the more addresses a host has, the greater its chance of experiencing a collision, so having fewer addresses to collide is arguably better. >Section 3.3 seems to skip the issue about how to connect or >send the first UDP to a link-local address in the absense of >API support to identify interfaces. Using the source IP address >to identify the interface works after the initial exchange e.g. >after a tcp connection has been established. But making it work >for UDP responders when the socket is bound to INADDR_ANY seems >hard. Application software has to do what any good application software (e.g. DNS server, NFS server, etc.) has to do today on a multi-homed host -- it enumerates the available interfaces, opens a socket per interface, and binds each socket to its interface. > In addition, this kind of host should probe for, and defend, all of > its link-local addresses on all of its active interfaces that are > using link-local addresses. >I don't see why this is strictly needed. The host needs to >ensure that its IP are unique across the interfaces but it >should be able to handle having a local address X on interface >#1 while address X is also assigned to a remote node on >interface #2. This case is discussed in 3.3.1, "Example Illustrating (Incorrect) Ambiguous Address Re-Use": When host A sends a UDP packet from source address P to destination address Q without specifying an explicit outgoing interface identifier, it is ambiguous whether A intends to talk to itself, or to host B. Do you disagree with that example? >And defending its addresses on all interfaces has the disadvantage of >increasing the risk of having to pick a new address. That is the benefit of using choice 3.2 (Single Shared Link-Local Address) on hosts where the OS and application software make that possible. >The example in 3.3.1 doesn't seem to match what is said at the >top of section 3.3: "[...] enable use of the source address as >an unambiguous interface identifier". This means that in 3.3.1 >P identifies the interface and the only Q on that interface is >assigned to B. If A wants to talk to itself it can use a source >of 127.0.0.1 (indentifying the loopback interface) and the same >as a destination, or a source of P and dest P, etc. Allowing a >source of P and a destination Q for loopback traffic seems >counter to using the strong end system model. I believe that in most operating systems today, if a multi-homed host has addresses P and Q, and sends a packet addressed to Q, then that packet is looped back inside the network stack and redelivered locally. It is not sent out on the wire. It seemed wise not to mandate changing this behaviour for LL destination addresses, but I do not have a strong opinion about that. Am I wrong about the current behaviour of today's multi-homed hosts? >But I still don't understand the description in section 3.3 is >supposed to handle what is common in the BSD API: a TCP socket >is created and then connected to the destination address. In >this case there is nothing which can be used to infer the interface. >Is that intended to be outside the scope of section 3.3? Section 3.3 does not propose a solution to applications that think that an IP address alone is sufficient to uniquely identify the desired destination. I believe that such a solution would require magic. Section 3.3 explains how it is possible to produce a well-written application that can use link-local addresses on a multi-homed host. We do everything possible to make current software work as well as it can with link-local addresses, but that doesn't mean that there aren't ways you could improve current software to make it work even better. If we can run Zeroconf IP over a USB cable, then you can use today's ftp client software to transfer files over that cable. Perhaps you could improve today's ftp client software to work even better if you made it more aware of Zeroconf Considerations. Compare that with how much work you'd have to do to modify today's ftp client software to transfer files over a USB cable where IP is *not* available. >The second paragraph in section 3.4 seems to conflict with the >current model in section 3.1 - if you want to support multiple >interfaces being bridged togther in the same link then the >interfaces better have distinct link local addresses. Otherwise >you don't know which interface packets will arrive on which >means that the communication bound to an interface per the >strong ES model will fail half the time (when the packets >arrive on a different interface than were connection is sending >packets). This is a very good point. I propose the following new text: If a host receives an ARP packet where the 'sender hardware address' is not the hardware address of the interface on which the packet was received, but *is* the hardware address of one of the host's other interfaces, then this indicates that the host has two or more interfaces connected to the same network link. This can happen if the user of a multi-homed host with two Ethernet interfaces connects both interfaces to the same Ethernet hub. It can also occur less obviously, such as a host with both wired and wireless Ethernet interfaces, in an environment where a wireless gateway is available, and (perhaps unknown to the user) happens to be bridged onto the same wired Ethernet. If a host implementing a single shared link-local address (Section 3.2) receives such an ARP packet, it should cease using its link- local address on one of the two interfaces in question. If there is a performance difference between the two interfaces (e.g. Gigabit wired Ethernet and 11Mb/s wireless), then the host should generally cease using its link-local address on the lower performance interface. If a host implementing a different link-local address for each interface (Section 3.3) receives such an ARP packet, it should silently discard it and not treat it as a conflict. Such a host should not shut down either interface's link-local address, because to do so would break existing connections established to the discontinued IP address. Thanks again for your comments. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Sep 11 04:12: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 ESMTP id EAA00448 for ; Tue, 11 Sep 2001 04:12:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 215A791252; Tue, 11 Sep 2001 04:12:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D50939127F; Tue, 11 Sep 2001 04:12: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 B931D91252 for ; Tue, 11 Sep 2001 04:12:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 808E05DDE1; Tue, 11 Sep 2001 04:12:44 -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 F14325DDDC for ; Tue, 11 Sep 2001 04:12:43 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id BAA10878 for ; Tue, 11 Sep 2001 01:12:43 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 11 Sep 2001 01:12:42 -0700 Received: from [206.111.147.149] (vpn-gh-1041.apple.com [17.254.140.16]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id BAA18169; Tue, 11 Sep 2001 01:12:41 -0700 (PDT) Message-Id: <200109110812.BAA18169@scv1.apple.com> Subject: Re: IETF 51 ZEROCONF Minutes Date: Tue, 11 Sep 2001 01:12:41 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Keith Moore" Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >surely you will admit that there are scaling problems with appletalk >that impact its reliability for ethernets with large #s of hosts? For three years at Apple I was on a switched Ethernet with 1016 available AppleTalk addresses and about 1000 hosts. Watching the network with EtherPeek I saw it often took a host 50-100 tries to find an unused address. This process could take dozens of milliseconds. I don't recommend overloading a network to this extent, but to say it was unreliable is incorrect. Once a host found an unused AppleTalk address, it kept it, and defended it, and we never had any reliability problems caused by hosts trampling on each other's AppleTalk addresses. >the point is that these link-local addresses aren't intended >to be used directly - you need to use this mechanism in conjunction >with some kind of service discovery mechanism. Isn't this true of all addresses? What kinds of addresses *are* intended to be used directly, without use of DNS or SAP or some other kind of naming or discovery protocol? I understand why at first glance self-assigned link-local addresses seem very weird and alien, because you don't know from one day to the next what IP address your machine may have, but for most users, exactly the same is true of DHCP addresses. Can you suggest specific wording? If we say, "Link-local addresses require some kind of naming protocol," then that is too vague and invites more questions than it answers. If we say, "Link-local addresses require Multicast DNS," then that looks like a normative reference to other work that it not yet close to standardization. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Sep 11 09:51: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 ESMTP id JAA08502 for ; Tue, 11 Sep 2001 09:51:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F28E49128E; Tue, 11 Sep 2001 09:48:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E81F91290; Tue, 11 Sep 2001 09:47: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 B6C989128D for ; Tue, 11 Sep 2001 09:47:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BA0A5DDB6; Tue, 11 Sep 2001 09:47:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 024505DD8E for ; Tue, 11 Sep 2001 09:47:00 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA12671; Tue, 11 Sep 2001 09:46:53 -0400 (EDT) Message-Id: <200109111346.JAA12671@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Keith Moore" , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 01:12:41 PDT." <200109110812.BAA18169@scv1.apple.com> Date: Tue, 11 Sep 2001 09:46:53 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >surely you will admit that there are scaling problems with appletalk > >that impact its reliability for ethernets with large #s of hosts? > > For three years at Apple I was on a switched Ethernet with 1016 available > AppleTalk addresses and about 1000 hosts. Watching the network with > EtherPeek I saw it often took a host 50-100 tries to find an unused > address. This process could take dozens of milliseconds. I don't > recommend overloading a network to this extent, but to say it was > unreliable is incorrect. Once a host found an unused AppleTalk address, > it kept it, and defended it, and we never had any reliability problems > caused by hosts trampling on each other's AppleTalk addresses. Having an indication of expected scaling limits helps a lot. I've seen a single bridged ethernet supporting several thousand hosts. (yes, there were a few problems...) > >the point is that these link-local addresses aren't intended > >to be used directly - you need to use this mechanism in conjunction > >with some kind of service discovery mechanism. > > Isn't this true of all addresses? What kinds of addresses *are* intended > to be used directly, without use of DNS or SAP or some other kind of > naming or discovery protocol? IP addresses are intended to be used directly. DNS is optional. Many applications expect IP addresses to be stable for weeks or more and not to be changed on a whim. (In my day job I work with large scale distributed systems and Grid computing systems, so I see these every day. It's a different perspective than that of a user who thinks of the 'net as the web and email and ICQ.) > I understand why at first glance self-assigned link-local addresses seem > very weird and alien, because you don't know from one day to the next > what IP address your machine may have, but for most users, exactly the > same is true of DHCP addresses. I don't know what you mean by "most" users, and even if true, it's not necessarily a good idea to take conditions that exist for "most" users at the present time and say that they're right for "all" users for the future of the Internet. DHCP can be used to assign long-term addresses - just keep renewing the same lease. The fact that it's often used differently just reflects the current fashion to have most machines as "clients" that only initiate connections. This may change in the future, and there are many valuable applications that employ large numbers of hosts and expect their addresses to be stable. > Can you suggest specific wording? > > If we say, "Link-local addresses require some kind of naming protocol," > then that is too vague and invites more questions than it answers. > > If we say, "Link-local addresses require Multicast DNS," then that looks > like a normative reference to other work that it not yet close to > standardization. I think a paragraph somewhere as part of an introduction could say that link-local addresses are expected to be used along with some sort of name lookup scheme that works in ad hoc networks, which is TBD, would suffice. That way, it's not a normative reference. From the point of view of a reader who hasn't been participating in the zeroconf group, I think it makes more sense to give a vague explanation than to give no explanation. Keith From owner-zeroconf@merit.edu Tue Sep 11 10:48:21 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09582 for ; Tue, 11 Sep 2001 10:48:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 324F491362; Tue, 11 Sep 2001 10:41:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4352C91349; Tue, 11 Sep 2001 10:41:13 -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 E6D8191335 for ; Tue, 11 Sep 2001 10:30:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7B125DDCC; Tue, 11 Sep 2001 10:30:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 152FB5DD8E for ; Tue, 11 Sep 2001 10:30:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA57417; Tue, 11 Sep 2001 07:21:38 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 11 Sep 2001 07:21:38 -0700 (PDT) From: Bernard Aboba To: Stuart Cheshire Cc: Keith Moore , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-Reply-To: <200109110812.BAA18169@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > If we say, "Link-local addresses require some kind of naming protocol," > then that is too vague and invites more questions than it answers. Linklocal addressing is no different than DHCP assignment with respect to naming. RFC 2131 doesn't make any statements about naming; neither should this specification. > If we say, "Link-local addresses require Multicast DNS," then that looks > like a normative reference to other work that it not yet close to > standardization. I see no reason for this specification to include any references to mDNS, normative or not. From owner-zeroconf@merit.edu Tue Sep 11 11:17:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10039 for ; Tue, 11 Sep 2001 11:17:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50B9191334; Tue, 11 Sep 2001 10:45:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 376A791335; Tue, 11 Sep 2001 10:41: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 8431A912FC for ; Tue, 11 Sep 2001 10:26:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB6C65DDE3; Tue, 11 Sep 2001 10:26:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id AC0215DE37 for ; Tue, 11 Sep 2001 10:26:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA57410; Tue, 11 Sep 2001 07:17:05 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 11 Sep 2001 07:17:05 -0700 (PDT) From: Bernard Aboba To: Stuart Cheshire Cc: Erik Nordmark , zeroconf@merit.edu Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt In-Reply-To: <200109110757.f8B7vpw08491@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Is a MADCAP server allowed to assign multicast addresses in the > 224.0.0.0/24 prefix? > Addresses in the 224.0.0.0/24 prefix are not dynamically assigned. So they should not be assigned by MADCAP or ZMAAP. > I did consider saying that link-local source addresses may not send to > multicast addresses outside 224.0.0.0/24, but I fear (though I don't know > for certain) that this would be overly restrictive. In general, there's no reason to use a linklocal address to send to a global multicast address, since that packet could reach hosts multiple hops away, and packets from a linklocal address should remain local to the link. From owner-zeroconf@merit.edu Tue Sep 11 11:34: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 ESMTP id LAA10287 for ; Tue, 11 Sep 2001 11:34:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1CDCD91402; Tue, 11 Sep 2001 11:32:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E06591370; Tue, 11 Sep 2001 10:45: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 3FB1591356 for ; Tue, 11 Sep 2001 10:42:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 144AE5DD8F; Tue, 11 Sep 2001 10:42:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 668845DD8E for ; Tue, 11 Sep 2001 10:42:56 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA12984; Tue, 11 Sep 2001 10:42:51 -0400 (EDT) Message-Id: <200109111442.KAA12984@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , Stuart Cheshire , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 07:26:18 PDT." Date: Tue, 11 Sep 2001 10:42:50 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > IP addresses are intended to be used directly. DNS is optional. > > Many applications expect IP addresses to be stable for weeks or more and > > not to be changed on a whim. > > Most servers run with static addresses, and don't use DHCP. For similar > reasons, I would expect that those servers will not want to serve clients > using a linklocal address. right, but one of the justifications for linklocal addresses is to support plug-and-play appliances, and any $49 printer is a server. Keith From owner-zeroconf@merit.edu Tue Sep 11 11:38:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10479 for ; Tue, 11 Sep 2001 11:38:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB247913DE; Tue, 11 Sep 2001 11:32:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AF2F9136B; Tue, 11 Sep 2001 10:45: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 BFC7191337 for ; Tue, 11 Sep 2001 10:35:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9868B5DDB6; Tue, 11 Sep 2001 10:35:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DF4AF5DD8E for ; Tue, 11 Sep 2001 10:35:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA57425; Tue, 11 Sep 2001 07:26:18 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 11 Sep 2001 07:26:18 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: Stuart Cheshire , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-Reply-To: <200109111346.JAA12671@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > IP addresses are intended to be used directly. DNS is optional. > Many applications expect IP addresses to be stable for weeks or more and > not to be changed on a whim. Most servers run with static addresses, and don't use DHCP. For similar reasons, I would expect that those servers will not want to serve clients using a linklocal address. From owner-zeroconf@merit.edu Tue Sep 11 12:57:31 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13098 for ; Tue, 11 Sep 2001 12:57:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 746C791441; Tue, 11 Sep 2001 12:21:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2161091470; Tue, 11 Sep 2001 12:17:44 -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 121EE91479 for ; Tue, 11 Sep 2001 12:11:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF4E45DD9B; Tue, 11 Sep 2001 12:11:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 3E0F95DD95 for ; Tue, 11 Sep 2001 12:11:55 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA13913; Tue, 11 Sep 2001 12:11:48 -0400 (EDT) Message-Id: <200109111611.MAA13913@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Stuart Cheshire , Keith Moore , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 07:21:38 PDT." Date: Tue, 11 Sep 2001 12:11:48 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > If we say, "Link-local addresses require some kind of naming protocol," > > then that is too vague and invites more questions than it answers. > > Linklocal addressing is no different than DHCP assignment with respect to > naming. RFC 2131 doesn't make any statements about naming; neither should > this specification. I disagree, because - DHCP has different applicability than link-local addressing, - DHCP can be used as a means to assign stable addresses to hosts that need them, - the very environment which justifies creation of linklocal addresses makes traditional DNS name lookup problematic - even if this were a shortcoming in the DHCP specification (and I think there are some shortcomings there), this would not justify a shortcoming in the linklocal address specification. > > If we say, "Link-local addresses require Multicast DNS," then that looks > > like a normative reference to other work that it not yet close to > > standardization. > > I see no reason for this specification to include any references to mDNS, > normative or not. I don't see a need for a reference to any specific technology, only some background information to supply context to the reader. I think folks are making too big a deal about this. Most of what I'm asking for are simple clarifications to the text, rather than changes to the protocol. They're not things that should delay the document by any significant amount of time. Keith From owner-zeroconf@merit.edu Tue Sep 11 13:22: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 ESMTP id NAA13791 for ; Tue, 11 Sep 2001 13:22:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 20F67914E7; Tue, 11 Sep 2001 13:11:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96BFF9147A; Tue, 11 Sep 2001 12:56:11 -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 0FE5891433 for ; Tue, 11 Sep 2001 11:55:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0CE05DD95; Tue, 11 Sep 2001 11:55:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 6CB805DD8F for ; Tue, 11 Sep 2001 11:55:24 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA13763; Tue, 11 Sep 2001 11:55:10 -0400 (EDT) Message-Id: <200109111555.LAA13763@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , Bernard Aboba , Stuart Cheshire , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 17:46:50 +0200." Date: Tue, 11 Sep 2001 11:55:10 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > > IP addresses are intended to be used directly. DNS is optional. > > > > Many applications expect IP addresses to be stable for weeks or more and > > > > not to be changed on a whim. > > > > > > Most servers run with static addresses, and don't use DHCP. For similar > > > reasons, I would expect that those servers will not want to serve clients > > > using a linklocal address. > > > > right, but one of the justifications for linklocal addresses is to support > > plug-and-play appliances, and any $49 printer is a server. > > That's one reason why service discovery is so important. If one > cannot locate one's server by IP address, one can locate it using > a discovery protocol. right, and my point relative to the "how to get an IP address" document is merely that a reader has a hard time seeing how the address selection protocol will be used if he doesn't know that a service discovery or name-to-address lookup protocol is also intended to be part of the picture. Keith From owner-zeroconf@merit.edu Tue Sep 11 21:59:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24642 for ; Tue, 11 Sep 2001 21:59:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B257E91369; Tue, 11 Sep 2001 21:20:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A09F391AEE; Tue, 11 Sep 2001 20:46: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 158759172F for ; Tue, 11 Sep 2001 20:32:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEF795DD9A; Tue, 11 Sep 2001 20:32:34 -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 8B8E55DD8E for ; Tue, 11 Sep 2001 20:32:34 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id RAA13605 for ; Tue, 11 Sep 2001 17:32:33 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA20016 for ; Tue, 11 Sep 2001 17:24:03 -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 f8C0WLA22682; Wed, 12 Sep 2001 10:32:22 +1000 (EST) Message-ID: <3B9EAD15.865EEA19@email.mot.com> Date: Wed, 12 Sep 2001 10:32:21 +1000 From: Aidan Williams X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Keith Moore , Stuart Cheshire , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > > IP addresses are intended to be used directly. DNS is optional. > > Many applications expect IP addresses to be stable for weeks or more and > > not to be changed on a whim. > > Most servers run with static addresses, and don't use DHCP. For similar > reasons, I would expect that those servers will not want to serve clients > using a linklocal address. Well.. I have a "server" which gets an address from a pool via DHCP, from my ISP. This address, although dynamic, is quite stable. I see no reason why a link-local address could not be stable in a similar kind of way. regards aidan ____ :wq! From owner-zeroconf@merit.edu Tue Sep 11 23:38:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26681 for ; Tue, 11 Sep 2001 23:38:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C37591A81; Tue, 11 Sep 2001 23:12:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EF7291976; Tue, 11 Sep 2001 21:24: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 6E08191AAC for ; Tue, 11 Sep 2001 20:19:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DF105DD9A; Tue, 11 Sep 2001 20:19:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 2EBA95DD8E for ; Tue, 11 Sep 2001 20:19:34 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA03260; Tue, 11 Sep 2001 17:19:27 -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 RAA14183; Tue, 11 Sep 2001 17:19:22 -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 f8C0JJA21588; Wed, 12 Sep 2001 10:19:20 +1000 (EST) Message-ID: <3B9EAA07.A030BA9E@email.mot.com> Date: Wed, 12 Sep 2001 10:19:19 +1000 From: Aidan Williams X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore Cc: Stuart Cheshire , zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes References: <200109111346.JAA12671@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > I think a paragraph somewhere as part of an introduction could say that > link-local addresses are expected to be used along with some sort of > name lookup scheme that works in ad hoc networks, which is TBD, > would suffice. That way, it's not a normative reference. > This would be good material for the host profile document http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-host-prof-01.txt rather than the IPv4 link-local draft. - aidan From owner-zeroconf@merit.edu Wed Sep 12 01:12: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 ESMTP id BAA28193 for ; Wed, 12 Sep 2001 01:12:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C7DD791332; Wed, 12 Sep 2001 01:04:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A03C8915F7; Tue, 11 Sep 2001 23:46: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 55B2191C53 for ; Tue, 11 Sep 2001 23:14:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CD935DDE4; Tue, 11 Sep 2001 23:14:49 -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 C11965DDC7 for ; Tue, 11 Sep 2001 23:14:48 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA10718 for ; Tue, 11 Sep 2001 20:14:48 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Sep 2001 20:14:47 -0700 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id UAA11822 for ; Tue, 11 Sep 2001 20:14:47 -0700 (PDT) Message-Id: <200109120314.UAA11822@scv1.apple.com> Subject: Re: IETF 51 ZEROCONF Minutes Date: Tue, 11 Sep 2001 20:14:47 -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 >Most servers run with static addresses, and don't use DHCP. For similar >reasons, I would expect that those servers will not want to serve clients >using a linklocal address. Except that increasingly, people with home servers on cable modems using DHCP use dynamic DNS services to provide stable names for those servers. The requirement for a server to have a constant IP address is really going away. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Sep 12 01:12: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 ESMTP id BAA28234 for ; Wed, 12 Sep 2001 01:12:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 563629178E; Wed, 12 Sep 2001 00:43:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FE9091527; Tue, 11 Sep 2001 23:46: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 0E04F91BD1 for ; Tue, 11 Sep 2001 23:13:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E81675DDE4; Tue, 11 Sep 2001 23:13:36 -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 688D85DDC7 for ; Tue, 11 Sep 2001 23:13:36 -0400 (EDT) Received: from mailgate2.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 UAA15738 for ; Tue, 11 Sep 2001 20:13:36 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Sep 2001 20:13:35 -0700 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f8C3DZw06699 for ; Tue, 11 Sep 2001 20:13:35 -0700 (PDT) Message-Id: <200109120313.f8C3DZw06699@scv2.apple.com> Subject: Re: IETF 51 ZEROCONF Minutes Date: Tue, 11 Sep 2001 20:13:34 -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 >Linklocal addressing is no different than DHCP assignment with respect to >naming. RFC 2131 doesn't make any statements about naming; neither should >this specification. Or indeed RFC 2462, "IPv6 Stateless Address Autoconfiguration". Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Sep 12 01:55: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 ESMTP id BAA00685 for ; Wed, 12 Sep 2001 01:55:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3639B914CE; Wed, 12 Sep 2001 00:23:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 975FC916F7; Tue, 11 Sep 2001 23:42:26 -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 CC8CA91BDE for ; Tue, 11 Sep 2001 23:13:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3BAF5DDE5; Tue, 11 Sep 2001 23:13:48 -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 52ED95DDC7 for ; Tue, 11 Sep 2001 23:13:48 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA15783 for ; Tue, 11 Sep 2001 20:13:47 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Sep 2001 20:13:46 -0700 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id UAA22890 for ; Tue, 11 Sep 2001 20:13:47 -0700 (PDT) Message-Id: <200109120313.UAA22890@scv3.apple.com> Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Tue, 11 Sep 2001 20:13:47 -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 >Addresses in the 224.0.0.0/24 prefix are not dynamically assigned. >So they should not be assigned by MADCAP or ZMAAP. Agreed. This was my point. >In general, there's no reason to use a linklocal address to send >to a global multicast address, since that packet could reach hosts >multiple hops away, and packets from a linklocal address should >remain local to the link. So, if a host with a link-local address that needs a dynamic multicast address cannot use addresses in the 224.0.0.0/24 prefix, and it cannot use a global multicast address, what can it use? While it may seem natural at first to say that a host with a link-local address should only use link-local multicast, I think that in practice this would leave the host with no multicast at all. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Sep 12 01:56:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00727 for ; Wed, 12 Sep 2001 01:56:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D26B912C4; Wed, 12 Sep 2001 01:12:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 027BF91440; Tue, 11 Sep 2001 23:53: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 DB4E291C4A for ; Tue, 11 Sep 2001 22:54:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1AA75DDE1; Tue, 11 Sep 2001 22:54:46 -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 6F4A25DDC7 for ; Tue, 11 Sep 2001 22:54:46 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id TAA08555 for ; Tue, 11 Sep 2001 19:54:46 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Sep 2001 19:54:45 -0700 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id TAA20738 for ; Tue, 11 Sep 2001 19:54:45 -0700 (PDT) Message-Id: <200109120254.TAA20738@scv3.apple.com> Subject: Re: IETF 51 ZEROCONF Minutes Date: Tue, 11 Sep 2001 19:54:45 -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 >IP addresses are intended to be used directly. DNS is optional. Is this really a serious argument? Are IPv6 addresses intended to be used without a naming protocol? If you really want, IPv4 link-local addresses can be used directly. We can plug our two laptops together with a crossover Ethernet cable, you can read your IP address from your screen, and I can type it into my AppleShare client. It works fine, but a naming protocol is obviously better, and a service discovery protocol is better than that. Why are IPv4 link-local addresses different to IPv6 link-local addresses in this respect? You can use either without a naming protocol, but would you *want* to? RFC 2460 does not discuss naming and DNS for IPv6 addresses. What is different about this draft? >Many applications expect IP addresses to be stable for weeks or more >and not to be changed on a whim. If you unplug your laptop from the office network and take it home with you, then applications that expect IP addresses to be "stable for weeks or more" are not going to work, no matter how you assign the address. If you don't want to unplug the computer from the network and take it home with you, link-local addresses are stable. >DHCP can be used to assign long-term addresses - >just keep renewing the same lease. Your link-local addresses is long-term -- just keep defending it. You seem to have some misconception that link-local addresses keep changing at random for no reason. They do not. Link-local addresses only change if two hosts are found to be using the same address. If two hosts are found to be using the same address then networking doesn't work reliably no matter how the address was assigned, so selecting a new address is the best course of action in that case. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Sep 12 02:35:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11161 for ; Wed, 12 Sep 2001 02:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0CCC91408; Wed, 12 Sep 2001 01:12:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02B0B91634; Wed, 12 Sep 2001 00:35: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 E6518916AE for ; Tue, 11 Sep 2001 23:25:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BFC85DD95; Tue, 11 Sep 2001 23:25:08 -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 F2A795DDC7 for ; Tue, 11 Sep 2001 23:25:07 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA11920 for ; Tue, 11 Sep 2001 20:25:07 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Sep 2001 20:25:06 -0700 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id UAA24234 for ; Tue, 11 Sep 2001 20:25:06 -0700 (PDT) Message-Id: <200109120325.UAA24234@scv3.apple.com> Subject: Re: IETF 51 ZEROCONF Minutes Date: Tue, 11 Sep 2001 20:25:06 -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 >my point relative to the "how to get an IP address" >document is merely that a reader has a hard time seeing how the >address selection protocol will be used if he doesn't know that >a service discovery or name-to-address lookup protocol is also >intended to be part of the picture. I believe that anyone wanting to implement link-local addresses, and reading this document to learn how, will already have an idea of why they are doing it and how they intend to use them. I would rather not try to mandate how link-local addresses should be used. If people want to use link-local addresses by having an LCD panel on the front panel of the device that displays its IP address, then I may think that's foolish, but I don't see any reason to tell people they shouldn't do that. If people want to use link-local addresses using some ad-hoc broadcast protocol of their own invention to discover other peers on the network, I don't see any reason to tell people they shouldn't do that. If you have specific wording that you'd like to see in the draft, can you tell us? I don't know exactly what you want to see, but I can tell you are not happy with it the way it is now. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Sep 12 04:24: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 ESMTP id EAA14321 for ; Wed, 12 Sep 2001 04:24:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC36591344; Wed, 12 Sep 2001 04:08:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55939918F7; Wed, 12 Sep 2001 03:29: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 7E810918FB for ; Wed, 12 Sep 2001 03:17:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55BA35DDEC; Wed, 12 Sep 2001 03:17:47 -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 9FFF55DD95 for ; Wed, 12 Sep 2001 03:17:46 -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 BAA25579; Wed, 12 Sep 2001 01:17: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 JAA04515; Wed, 12 Sep 2001 09:17:43 +0200 (MET DST) Date: Wed, 12 Sep 2001 09:30:09 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: IETF 51 ZEROCONF Minutes To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: "Your message with ID" <200109120325.UAA24234@scv3.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, I appreciate where you are coming from, but I respectfully disagree. > I would rather not try to mandate how link-local addresses should be used. The IETF doesn't mandate how protocols are used. We do, however, aim to produce standards which can reasonably be used, and that is Keith's point. > If people want to use link-local addresses using some ad-hoc broadcast > protocol of their own invention to discover other peers on the network, I > don't see any reason to tell people they shouldn't do that. There is a very good reason to tell them they shouldn't do that: There is an IETF standard protocol for service discovery on IP networks which scales up on a subnet well, and beyond, is interoperable, and has understood administrable properties. It *is* our business to tell people what they should or should not do - that's what applicability statements, host requirements specifications and BCPs are all about. Erik From owner-zeroconf@merit.edu Wed Sep 12 13:34: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 ESMTP id NAA28624 for ; Wed, 12 Sep 2001 13:34:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 118B6912DE; Wed, 12 Sep 2001 13:34:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2D1A912EE; Wed, 12 Sep 2001 13:33: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 967A7912DE for ; Wed, 12 Sep 2001 13:33:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7ABC15DDBC; Wed, 12 Sep 2001 13:33:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 46FB85DDB5 for ; Wed, 12 Sep 2001 13:33:55 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA25057; Wed, 12 Sep 2001 13:33:47 -0400 (EDT) Message-Id: <200109121733.NAA25057@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 20:13:34 PDT." <200109120313.f8C3DZw06699@scv2.apple.com> Date: Wed, 12 Sep 2001 13:33:47 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >Linklocal addressing is no different than DHCP assignment with respect to > >naming. RFC 2131 doesn't make any statements about naming; neither should > >this specification. > > Or indeed RFC 2462, "IPv6 Stateless Address Autoconfiguration". not the same thing at all. IPv6 had stateless autoconfiguration from the start, so IPv6 application writers expect it, whereas you're trying to retro-fit it into IPv4. and 2462 doesn't choose addresses at random. Keith From owner-zeroconf@merit.edu Wed Sep 12 13:40: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 ESMTP id NAA28738 for ; Wed, 12 Sep 2001 13:40:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35FBC912F2; Wed, 12 Sep 2001 13:37:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE77F912F7; Wed, 12 Sep 2001 13:37: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 E030A912F2 for ; Wed, 12 Sep 2001 13:36:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C18385DDB5; Wed, 12 Sep 2001 13:36:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id DD4765DDBD for ; Wed, 12 Sep 2001 13:35:57 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA25094; Wed, 12 Sep 2001 13:35:52 -0400 (EDT) Message-Id: <200109121735.NAA25094@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 20:14:47 PDT." <200109120314.UAA11822@scv1.apple.com> Date: Wed, 12 Sep 2001 13:35:52 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Except that increasingly, people with home servers on cable modems using > DHCP use dynamic DNS services to provide stable names for those servers. > > The requirement for a server to have a constant IP address is really > going away. that's simply false. lots of applications still require stable names, and DNS is often not an acceptable substitute. Keith From owner-zeroconf@merit.edu Wed Sep 12 13:45: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 ESMTP id NAA28876 for ; Wed, 12 Sep 2001 13:45:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAAC491301; Wed, 12 Sep 2001 13:38:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4ED5A91303; Wed, 12 Sep 2001 13:38:07 -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 791A291301 for ; Wed, 12 Sep 2001 13:37:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EF3A5DDBC; Wed, 12 Sep 2001 13:37:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 181A65DD93 for ; Wed, 12 Sep 2001 13:37:56 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA25123; Wed, 12 Sep 2001 13:37:52 -0400 (EDT) Message-Id: <200109121737.NAA25123@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 20:25:06 PDT." <200109120325.UAA24234@scv3.apple.com> Date: Wed, 12 Sep 2001 13:37:51 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I believe that anyone wanting to implement link-local addresses, and reading this document to learn how, will already have an idea of why they are doing it and how they intend to use them. It's not just the implementors of link-local addresses that need to know these things; it's also the writers of applications that will be affected. > If you have specific wording that you'd like to see in the draft, can you > tell us? I'll try to come up with specific wording for all of these things; it's just taking me a few days to find the time. And yesterday was a complete loss, I'm afraid. Keith From owner-zeroconf@merit.edu Wed Sep 12 13:54: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 ESMTP id NAA29032 for ; Wed, 12 Sep 2001 13:54:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0A8AC91320; Wed, 12 Sep 2001 13:50:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 450C691323; Wed, 12 Sep 2001 13:45:58 -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 E003091326 for ; Wed, 12 Sep 2001 13:45:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD9B15DD93; Wed, 12 Sep 2001 13:45:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 7C6FA5DDB5 for ; Wed, 12 Sep 2001 13:45:23 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA25147; Wed, 12 Sep 2001 13:45:17 -0400 (EDT) Message-Id: <200109121745.NAA25147@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IETF 51 ZEROCONF Minutes In-reply-to: Your message of "Tue, 11 Sep 2001 19:54:45 PDT." <200109120254.TAA20738@scv3.apple.com> Date: Wed, 12 Sep 2001 13:45:17 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >IP addresses are intended to be used directly. DNS is optional. > > Is this really a serious argument? yes it is. first because DNS is not fast or reliable enough for some kinds of applications; second, because DNS names are quite often overloaded and are not precise enough to be used as "endpoint identifiers" in distributed systems; third, because systems don't always have a reliable means of determining their DNS names (or their view of their DNS name may be different than the public view of their DNS name); and fourth, because we need to retain the option of implementing other name-to-address lookup services without making them dependent on DNS. I can elaborate on all of these if necessary. > Are IPv6 addresses intended to be used without a naming protocol? we're talking about IPv4 here, not IPv6. and we're talking about DNS specifically here, not just "a naming protocol". > You seem to have some misconception that link-local addresses keep > changing at random for no reason. They do not. it's a scaling issue. in a sufficiently large network temporary partitionings of the network (say via bridges that fail or restart) becomes a significant impact on reliability. I'm also concerned about the behavior of link-local addresses on large bridged networks during bootstrapping - say after a power failure. stating an expected scale for a network using link-local addresses (as I believe you'd agreed is reasonable) would help a lot. I will need to re-assess many of my comments in light of this change, and I haven't had time to do that yet. Keith From owner-zeroconf@merit.edu Wed Sep 12 20:49: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 ESMTP id UAA06980 for ; Wed, 12 Sep 2001 20:49:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98FB2919E5; Wed, 12 Sep 2001 20:44:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3985919C4; Wed, 12 Sep 2001 20:15:58 -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 A8C9491951 for ; Wed, 12 Sep 2001 19:51:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B1365DDE2; Wed, 12 Sep 2001 19:51:07 -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 3D5955DDDC for ; Wed, 12 Sep 2001 19:51:07 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA13341 for ; Wed, 12 Sep 2001 16:51:06 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Sep 2001 16:51:04 -0700 Received: from [206.111.147.149] (vpn-gh-42.apple.com [17.254.136.41]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id QAA10650 for ; Wed, 12 Sep 2001 16:51:05 -0700 (PDT) Message-Id: <200109122351.QAA10650@scv1.apple.com> Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Wed, 12 Sep 2001 16:51:05 -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 I'd like to request that people who have comments on the draft try to phrase them in terms of what *specific* text they'd like to see in the draft. Right now I no longer remember who is advocating that DNS is required, and who is advocating that DNS is optional. I can't keep straight who is saying, "we need to retain the option of implementing other name-to-address lookup services without making them dependent on DNS" and who is saying, "we're talking about DNS specifically here." I think we need to get back to focussing on what needs to be in the draft. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Sep 12 23:44: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 ESMTP id XAA11703 for ; Wed, 12 Sep 2001 23:44:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A6A6191967; Wed, 12 Sep 2001 23:35:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BC7B91900; Wed, 12 Sep 2001 23:25: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 B201E919E7 for ; Wed, 12 Sep 2001 23:15:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F6665DDF0; Wed, 12 Sep 2001 23:15:48 -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 187F45DDF3 for ; Wed, 12 Sep 2001 23:15:48 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA19191 for ; Wed, 12 Sep 2001 20:15:47 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Sep 2001 20:15:46 -0700 Received: from [206.111.147.149] (vpn-gh-42.apple.com [17.254.136.41]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id UAA09101 for ; Wed, 12 Sep 2001 20:15:46 -0700 (PDT) Message-Id: <200109130315.UAA09101@scv3.apple.com> Subject: Yesterday Date: Wed, 12 Sep 2001 20:15:47 -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 >And yesterday was a complete loss, I'm afraid. I don't believe there is anyone on this list, no matter where they are or what nationality, who could not be profoundly upset by yesterday's events. Yesterday I felt that as co-chair of the working group that perhaps I should make some kind of statement, but I could find no words to say. I wanted to give blood, but they won't take blood from English people because of fears of mad cow disease. The offices at Apple were half empty, and of the people who were there, I didn't see a single one who didn't have a window open on their screen showing the CNN multicast video feed. I still don't have any good words to say, and anyway this is probably not the right forum for that, but I thank you for your one simple sentence that sums up what many of us are feeling. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Sep 16 11:27:21 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12898 for ; Sun, 16 Sep 2001 11:27:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4293C91293; Sun, 16 Sep 2001 11:25:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FD0B9128F; Sun, 16 Sep 2001 11:25: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 CE2F69128A for ; Sun, 16 Sep 2001 11:25:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C44B35DE27; Sun, 16 Sep 2001 11:25:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2D7A55DDE6 for ; Sun, 16 Sep 2001 11:25:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA07874 for ; Sun, 16 Sep 2001 08:17:42 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 16 Sep 2001 08:17:42 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: Question on Stewart's last mDNS item Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > >Did svrloc crash & burn without me noticing? Or is there a > >terrible gap in coverage? > > A while back I promised you an answer to this question. It took me a > while, but here it is. > > I realized that one goal of Multicast DNS was to replace AppleTalk NBP, Indeed, replacement of legacy protocols (including Novell IPX and NetBIOS) was one of the major goals discussed at the original Zeroconf BOF. I also believe that this goal has been at the root of some of the major arguments we've had about the overall direction of the mDNS effort. Unfortunately, until now this goal was never articulated, and therefore did not find its way into the Zeroconf requirements document. So in writing the mDNS draft, we assumed that the Zeroconf WG had decided that it wasn't important. > but no one had actually written down precisely what is required to > replace AppleTalk NBP. If, as you suggest, we have been working on the solution to a problem whose requirements have not yet been defined, then I believe that this represents a major deficiency in the Zeroconf requirements document. Section 2.2.1 of draft-ietf-zeroconf-reqts-09.txt mentions that: "A mechanism to support DNS resolver interfaces in the zero configuration environment is required. Requirement: - MUST support DNS application layer interfaces as described in RFC 1123, section 6.1 [RFC 1123]." Section 2.2.2 mentions that: "Requirement: - MUST allow a host to determine if its name is unique. Then not unique, notify the user or configuration software so that another name may be chosen and similarly verified." That's essentially it for the zeroconf name resolution requirements. From owner-zeroconf@merit.edu Mon Sep 17 05:36:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06969 for ; Mon, 17 Sep 2001 05:36:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71D499133C; Mon, 17 Sep 2001 05:35:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3702291340; Mon, 17 Sep 2001 05:35:23 -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 47C569133C for ; Mon, 17 Sep 2001 05:35:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E8BB5DD9F; Mon, 17 Sep 2001 05:35:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gordon.ukservers.net (gordon.ukservers.net [217.10.138.217]) by segue.merit.edu (Postfix) with ESMTP id E4F475DDA1 for ; Mon, 17 Sep 2001 05:35:21 -0400 (EDT) Received: from procyon (unknown [212.56.66.3]) by gordon.ukservers.net (Postfix) with ESMTP id 67E8E4C29E for ; Mon, 17 Sep 2001 10:35:08 +0100 (BST) Message-ID: <013401c13f64$c8d0ef60$5801a8c0@localdomain> From: "Philip Nye" To: "Zeroconf Working Group" Subject: Claim and defend Date: Mon, 17 Sep 2001 11:37:43 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I am fairly new on this list and have been following the Autoconfigure and ZMAAP discussions with interest. There seem to be a growing number of protocols and applications which use a claim and defend principle for allocating exclusive numbers in a peer to peer system. The same general principle is used in autoconfigured IP addresses, in ZMAAP, for allocation of address space between MADCAP servers and elsewhere. I have come across several other areas of development where I would like a serverless way to negotiate number assignment across multiple hosts. Because the details differ in all existing cases I am confronted by the probability of having to implement several of these separately in a single lightweight product. I find myself wondering whether some sort of generalised number assignment protocol wouldn't be "a good thing". I envisage a protocol which can use the same general claim and defend principle with a different parameter set to obtain a number or range of numbers of whatever class is required. The same protocol could then be applied wherever this need arose. Has this been looked at or discussed before? Does anyone else see a benefit? Philip Nye From owner-zeroconf@merit.edu Mon Sep 17 08:11:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09836 for ; Mon, 17 Sep 2001 08:11:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A535A91225; Mon, 17 Sep 2001 08:10:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B349912A1; Mon, 17 Sep 2001 08:10: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 7D18791225 for ; Mon, 17 Sep 2001 08:10:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 66D0B5DDA1; Mon, 17 Sep 2001 08:10:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 4702B5DD99 for ; Mon, 17 Sep 2001 08:10:31 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA15221 for ; Mon, 17 Sep 2001 05:10:21 -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 FAA00016 for ; Mon, 17 Sep 2001 05:10:19 -0700 (MST)] Received: from email.mot.com ([10.238.2.43]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f8HCAEA06084; Mon, 17 Sep 2001 22:10:14 +1000 (EST) Message-ID: <3BA5E825.A53AB08D@email.mot.com> Date: Mon, 17 Sep 2001 22:10:13 +1000 From: Aidan Williams X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Philip Nye Cc: Zeroconf Working Group Subject: Re: Claim and defend References: <013401c13f64$c8d0ef60$5801a8c0@localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Philip Nye wrote: > Because the details differ in all existing cases I am confronted by > the probability of having to implement several of these separately > in a single lightweight product. I find myself wondering whether > some sort of generalised number assignment protocol wouldn't be "a > good thing". I envisage a protocol which can use the same general > claim and defend principle with a different parameter set to obtain > a number or range of numbers of whatever class is required. The same > protocol could then be applied wherever this need arose. > > Has this been looked at or discussed before? > Does anyone else see a benefit? > Yes, I see a benefit. I don't recall email to the list. Allocation of the number in a distributed way is reasonably straightforward. Dealing with collisions tends to be fairly protocol/application specific, and collisions are unavoidable when networks are joined. As much as I like the idea, it doesn't currently fit under the zeroconf working group charter, which says: [ http://www.ietf.org/html.charters/zeroconf-charter.html ]: > The WG will also produce two protocol specifications. First, the WG > will develop a document describing automatic generation and > assignment of link-local IPv4 addresses in environments lacking host > configuration (static or using DHCP). The document will describe > existing practice as well as define recommendations for future > implementations. Second, the WG will develop a profile of the > Address Allocation Protocol (AAP) to provide Zero Configuration > Multicast Address Allocation support for IPv4 and IPv6. ZMAAP would probably look different, but hey, it already looks different to AAP.. regards aidan ____ :wq! Communications and Networks Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://cnlab.arc.corp.mot.com/ From owner-zeroconf@merit.edu Mon Sep 17 08:51: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 ESMTP id IAA11391 for ; Mon, 17 Sep 2001 08:51:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D484C91270; Mon, 17 Sep 2001 08:51:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C33A91283; Mon, 17 Sep 2001 08:51:13 -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 A866691270 for ; Mon, 17 Sep 2001 08:51:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9382E5DDA1; Mon, 17 Sep 2001 08:50:52 -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 15CFE5DD99 for ; Mon, 17 Sep 2001 08:50:52 -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 FAA05203; Mon, 17 Sep 2001 05:50:24 -0700 (PDT) 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 OAA24098; Mon, 17 Sep 2001 14:50:22 +0200 (MET DST) Date: Mon, 17 Sep 2001 15:02:50 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Claim and defend To: Philip Nye , Aidan Williams Cc: Zeroconf Working Group In-Reply-To: "Your message with ID" <3BA5E825.A53AB08D@email.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Philip, Aidan, > Philp Nye wrote: > > I find myself wondering whether > > some sort of generalised number assignment protocol wouldn't be "a > > good thing". I envisage a protocol which can use the same general > > claim and defend principle with a different parameter set to obtain > > a number or range of numbers of whatever class is required. Current thinking is that you want the claim and defend protocol to be the same one which is *used* so that conflicts can be detected passively (without periodic messages or polling to detect conflicts). v4 LL autoconfiguration uses ARP for claim and defend. It has hosts broadcast ARP replies so that others can see if there's a conflict. The current discussion of ZMAAP would make it use ZMAAP for session discovery as well as address allocation, so session discovery replies would automatically clue in other mini-MAASs of an allocation conflict. > > Has this been looked at or discussed before? > > Does anyone else see a benefit? I believe claim and defend is completely bound to the application protocol which it serves - if it is to be done with this elegant 'use provides maintenance' characteristic. If no traffic exists for a particular protocol, no periodic messages need be sent to maintain its namespace, given this approach. So I do not see a benefit. Aidan wrote: > Yes, I see a benefit. I don't recall email to the list. Allocation > of the number in a distributed way is reasonably straightforward. Not really if you want scalable properties. Every problem has its unique scoping issues and usage pattern. > Dealing with collisions tends to be fairly protocol/application > specific, and collisions are unavoidable when networks are joined. These can be detected in an app specific way, as I noted, or using a beackon approach (scales linearly to the number of nodes sending the beackons - which is bad) or polling (scales linearly to the number of clients seeking to maintain a conflict-free namespace, which is worse.) > As much as I like the idea, it doesn't currently fit under the > zeroconf working group charter, which says: I completely agree. This will not be taken up by the ZEROCONF WG. I encourage you (Philip) to investigate this on your own, but I am not hopeful about the results. Erik From owner-zeroconf@merit.edu Mon Sep 17 11:02:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13578 for ; Mon, 17 Sep 2001 11:02:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C4E7912AA; Mon, 17 Sep 2001 11:00:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 120A0912AB; Mon, 17 Sep 2001 11:00: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 060CC912AA for ; Mon, 17 Sep 2001 11:00:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E01B55DD9F; Mon, 17 Sep 2001 11:00:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gordon.ukservers.net (gordon.ukservers.net [217.10.138.217]) by segue.merit.edu (Postfix) with ESMTP id B22A55DD99 for ; Mon, 17 Sep 2001 11:00:36 -0400 (EDT) Received: from procyon (unknown [212.56.66.3]) by gordon.ukservers.net (Postfix) with ESMTP id 453414D120 for ; Mon, 17 Sep 2001 16:00:32 +0100 (BST) Message-ID: <002001c13f92$3e2e95a0$5801a8c0@localdomain> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Re: Claim and defend Date: Mon, 17 Sep 2001 17:03:07 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Erik Guttman" > > Philip, Aidan, > > > Philp Nye wrote: > > > I find myself wondering whether > > > some sort of generalised number assignment protocol wouldn't be "a > > > good thing". I envisage a protocol which can use the same general > > > claim and defend principle with a different parameter set to obtain > > > a number or range of numbers of whatever class is required. > > Current thinking is that you want the claim and defend protocol to be > the same one which is *used* so that conflicts can be detected passively > (without periodic messages or polling to detect conflicts). v4 LL > autoconfiguration uses ARP for claim and defend. It has hosts > broadcast ARP replies so that others can see if there's a conflict. > The current discussion of ZMAAP would make it use ZMAAP for session > discovery as well as address allocation, so session discovery replies > would automatically clue in other mini-MAASs of an allocation conflict. I would see just about all of ZMAAP as being simply a special instance of the more generalised case and would expect the lookup or discovery (session discovery in the case of ZMAAP) to be a part of the same generalised protocol. LL autoconfiguration is rather different only because it is relies on a whole lot of backwardly compatible assumptions from long before any of this was devised. It is my prediction that there will be more applications of the same principle and the whole thing will have to be re-invented each time. Could ZMAAP be turned into a more general protocol? Meanwhile - is there a description of session discovery under ZMAAP? What does the term mean? The only reference in the current draft seems to be to SAP and SDP which at first glance seem rather restricted in their application and wouldn't seem well suited to dynamic detection of address conflicts. Philip From owner-zeroconf@merit.edu Mon Sep 24 09:42: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 ESMTP id JAA08570 for ; Mon, 24 Sep 2001 09:42:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C2EB9126F; Mon, 24 Sep 2001 09:42:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69F4B91272; Mon, 24 Sep 2001 09:42:31 -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 782EE9126F for ; Mon, 24 Sep 2001 09:42:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C8AB5DDA3; Mon, 24 Sep 2001 09:42:30 -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 0F5195DDA0 for ; Mon, 24 Sep 2001 09:42:30 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21228; Mon, 24 Sep 2001 06:41:48 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8ODfWg19890; Mon, 24 Sep 2001 15:41:32 +0200 (MET DST) Date: Mon, 24 Sep 2001 15:37:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt To: Stuart Cheshire Cc: Erik Nordmark , zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > I actually think that in the most precise definition of "on the same > link" for the purposes of IP is the one the draft gives: two hosts are > "on the same link" if and only if IP packets sent from one to the other > arrive with no part of the IP packet modified. If the TTL is decremented > en route, they are not on the same link. If the IP addresses are > rewritten by a NAT box or TCP port numbers are changed or the IP packet > is modified in any other way, then the hosts are not communicating > directly on the same link. I suspect people will agree with this, but there is a slight risk that we'd end up discussion "transparent" vs. "non-transparent" links - links that don't decrement ttl but do e.g. NAT type operations. Let's hope we don't end up in those discussions. > The reason the draft defines this in terms of link-layer payload instead > of IP packets is that ARP packets must also arrive unmodified, not just > IP packets. OK, but your proposed text below mentions IP which I think distracts from the ARP part. > >And presumably the definitions belong in section 1.1 and not 1.2. > > I propose putting the following modified text in Section 1.1: > > This document describes link-local addressing, for IP communication > between two hosts on a single link. Two hosts are considered to be on > the same link if, when one host sends packets to the other, the > entire link-layer packet payload arrives unmodified. The link-layer > *header* may be modified, such as in Token Ring Source Routing > [IEEE8025], but not the link-layer *payload*. In particular, any > device forwarding a packet whose source and/or destination address is > in the 169.254/16 prefix MUST NOT modify any part of the IP header > or IP packet body. This means that the packet may pass through > devices such as Ethernet switches, bridges, hubs or repeaters, but > not through devices like IP routers that modify the IP header. As I said above the "In particular ..." sentence might muddle things. And also seem to suggest that there might be link layers that would not modify packets with link-local addresses but modify other IP packets. Thus I think the "doesn't modify link-layer packet payload" is sufficient. > I am aware that by this strict definition, a Token Ring and an Ethernet > segment bridged together do not qualify as a single link, because the > bridge modifies the contents of ARP packets. [...] Presumably you also exclude the FDDI to Ethernet bridges that end up fragmenting IP packets without decrementing ttl etc. > Networks > bridged this way to do not qualify to be called a single link. [...] > This kind of bridging is > fragile and unreliable, and while it can certainly be made to work in > some situations, this draft should not promise to support it. While I agree that such things are flaky I see two issues: 1) The link definition in RFC 2460 isn't this strict and there would be less confusion if there was a single definition across IETF standards. 2) It is up to the WG to decide whether or not such links are in scope or out of scope for the linklocal spec. > >I don't understand what the text in section 2.1 about > > This means that even without using any other > > persistent storage, a host will usually select the same link-local > > address each time it is booted [...] > >relates to the fact the you refer to RFC 1750 which says "It recommends > >the use of truly random hardware techniques ..." > > > >If you have truly random hardware techniques then you would *not* get the > >same random number on each boot. So what is the relationship really with > >RFC 1750? > > The reference to RFC 1750 was put in at the request of Donald Eastlake on > 31st May this year. I do not have a strong opinion about it myself. Would > you prefer to see that reference removed? I'd like the WG to decide whether they want randomness or non-randomness first. At the moment the spec is inconsistent since it says strong randomness in one place and assumes non-randomness elsewhere. > >The algorithm in section 2.3 seems to force an unneeded IP address > >change if a single packet is lost. > >A is trying to use address X, which is already in use by B. > >A sends arp request. B sees it and responds with a gratuitus reponse. > >This response is lost. > >A sends the arp request again after 2 seconds. (It is supposed to do this 4 > >times). B sees it. Now the rules say that it MUST cease to use the address. > >This doesn't seem very robust. > > I think you are confusing sections 2.2 and 2.3. The four ARP packets two > seconds apart are in Section 2.2, "Claiming a Link-Local Address". Also, > they are ARP probes, not ARP requests. ARP probes are benign. They have > zero source address, and cause no harm to any other host on the network. > > The forced reconfiguration in Section 2.3 only comes into effect if the > ARP probing process failed, and two hosts are trying to use the same > source IP address (for example when two separate network segments are > later joined). Forced reconfiguration is rarely needed, and when it is > needed, it is the quickest (and only) way to restore working > communication. Two hosts cannot use the same IP address and have reliable > communication. Whether or not an ARP packet may occasionally be lost > makes no difference here. If two hosts are trying to use the same source > IP address, reliable communication will not be restored until at least > one of them stops using that address. Hmm - perhaps the text should be made more clear by - using "ARP request or response packet" instead of "ARP packet" - a section explicitly listing the differences agaist ARP as specified in the old RFC. > >Huh? Sending to a global multicast address with a link-local source > >is a good idea? > >How about allowing either for broadcast or multicasts to 224.0.0.0/24 > >but mandating global source for other multicasts. > > For example, hosts may want to use SSM addresses. There are no SSM > addresses in the 224.0.0.0/24 prefix. What is the utility of using SSM for packets that can not leave the link? SSM deals with scalaing issues for large scope multicast routing, and there are no scaling issues of that nature for link-local multicast. > What if you have a MADCAP server on the network, but no DHCP server, so > the hosts are using link-local addresses? Is the MADCAP server then > restricted to assigning only multicast addresses in the 224.0.0.0/24 > prefix? Is a MADCAP server allowed to assign multicast addresses in the > 224.0.0.0/24 prefix? Good questions that should be answered by somebody (else). But the questions don't directly address my concerns about using a link-local source address for non-link local multicast destinations. Note that IPv6 allows this with the requirement that routers not forward packets (out a different link) that have a link local source. I don't think that requirement exists in theory or in current router deployment for IPv4 link-locals, but I'd love to be corrected. Erik From owner-zeroconf@merit.edu Mon Sep 24 13:15:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24419 for ; Mon, 24 Sep 2001 13:15:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA2479129A; Mon, 24 Sep 2001 13:16:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A3BA9129E; Mon, 24 Sep 2001 13:16: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 1E6199129A for ; Mon, 24 Sep 2001 13:16:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF9EF5DD93; Mon, 24 Sep 2001 13:16:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com (unknown [131.107.3.118]) by segue.merit.edu (Postfix) with ESMTP id 466375DD91 for ; Mon, 24 Sep 2001 13:16:02 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 24 Sep 2001 10:15:19 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Sep 2001 10:15:18 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 24 Sep 2001 10:15:18 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 10:15:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt Date: Mon, 24 Sep 2001 10:15:15 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E7DB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt thread-index: AcFE/rPstWx9asHrThWm/0Xsu/6G/wAHOshQ From: "Dave Thaler" To: "Erik Nordmark" , "Stuart Cheshire" Cc: X-OriginalArrivalTime: 24 Sep 2001 17:15:15.0244 (UTC) FILETIME=[7A114EC0:01C1451C] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA24419 Erik Nordmark writes: > > >Huh? Sending to a global multicast address with a link-local source > > >is a good idea? > > >How about allowing either for broadcast or multicasts to 224.0.0.0/24 > > >but mandating global source for other multicasts. > > > > For example, hosts may want to use SSM addresses. There are no SSM > > addresses in the 224.0.0.0/24 prefix. > > What is the utility of using SSM for packets that can not leave the link? > SSM deals with scalaing issues for large scope multicast routing, and > there are no scaling issues of that nature for link-local multicast. The utility is that one can allocate an address with 0 messages on the wire, and 0 extra delay due to network latency. > > What if you have a MADCAP server on the network, but no DHCP server, so > > the hosts are using link-local addresses? Is the MADCAP server then > > restricted to assigning only multicast addresses in the 224.0.0.0/24 > > prefix? Is a MADCAP server allowed to assign multicast addresses in the > > 224.0.0.0/24 prefix? > > Good questions that should be answered by somebody (else). Normally MADCAP would never allocate link-local addresses, one would use ZMAAP for that, except if you have a huge number of hosts on the link. In theory, the MADCAP server can assign non-link-local addresses, but if a link-local address is used as a source address, the packets really shouldn't be routed off the local link (same as if TTL=1 were used) but see below... > But the questions don't directly address my concerns about using a > link-local source address for non-link local multicast destinations. > Note that IPv6 allows this with the requirement that routers > not forward packets (out a different link) that have a link local source. > I don't think that requirement exists in theory or in current router > deployment > for IPv4 link-locals, but I'd love to be corrected. I believe you are correct, this isn't explicitly stated anywhere. So in practice, it's best that a MADCAP server not allocate from larger multicast scopes if the admin knows equivalent unicast addresses are not available. -Dave