New mailing list for DNS-SD/mDNS Extensions
A new IETF mailing list has been created for discussions regarding DNS-SD/mDNS Extensions: https://www.ietf.org/mailman/listinfo/mdnsext This is in response to recent events in the industry and marketplace. In August, EDUCAUSE delivered a petition to Apple asking for improvements to Bonjour (aka DNS-SD/mDNS) to allow discovery of services beyond the local link. http://www.networkworld.com/news/2012/080312-bonjour-petition-261390.html https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind1208L=WIRELESS-LANO=DP=31656 In principle DNS-SD can already be used in conjunction with conventional unicast DNS to enable wide-area service discovery, but in practice this capability is not widely used. This disconnect between customer needs and current practice suggests that we need to revisit how to solve this problem. In response to this customer demand, Aerohive, Aruba, Cisco, and Xirrus have all recently announced Bonjour gateway products which allow service discovery beyond the local link. However, these were brought to market rapidly, and it's unclear whether they represent a desirable long-term direction for service discovery protocol development. Other companies are also reported to be developing their own Bonjour gateway products, not yet announced. It would be beneficial for the end users, network operators, these vendors, and for the long-term health of the Internet to bring this work into the IETF where all interested parties can collaborate on it. Proposed Scope of Work: The MDNSEXT mailing list discussions will focus on service discovery solutions suitable for: 1. Enterprise networks 2. Academic/Educational/University networks 3. Multi-link home networks, such as that envisaged by HOMENET* 4. Mesh networks, such as SE2.0/ZigBee/6lowpan-style networks * It is hoped that MDNSEXT can develop a solution that is suitable for all four network environments, including the HOMENET case. Of course the HOMENET WG is free to evalulate for itself whether it wishes to adopt the MDNSEXT solution, or develop something different. Proposed Goals: 1. Enable discovery of services across multiple links. 2. Zero configuration operation possible, but not mandatory. - i.e. Zero configuration operation is supported by the protocols, but administrative control is also available on networks where that is desired. 3. Scalability, in terms of: - Network traffic - CPU and memory requirements on network entities - User interface (huge flat list is not user friendly) - Having a smooth continuum of operation from local link to site to global, rather than wildly different incompatible modes of operation at different network scales - Granularity of services available on a server (extend the notion of service?) 4. Suitable for both local (zero-config) and global (configured) use - i.e. Suitable out-of-the box defaults should enable zero- configuration use on many small- to medium-sized networks, while still allowing for administrative control in networks where that's desired. 5. Incremental deployability - Identify what changes to existing network elements will be required, and attempt to minimize those changes. - Don't break existing DNS-SD/mDNS functionality and devices A BoF session is tentatively planned for 1520-1650 Tuesday 6th November 2012, subject there being enough interest to warrant moving ahead to that stage. Stuart Cheshire
Re: [IAOC] primary Paris hotel booking
On 3 Jan 2012, at 16:02, Bob Hinden wrote: Wes, I think everyone on the IAOC was surprised when we first heard that the meeting hotel insisted that people can only use fax or email to send in their reservations. We tried to get the hotel to change this, but they would not budge. This included their rejection of accepting reservations by phone. I sent them an encrypted PDF by email, and then called Hotel Concorde to give Carole Masson the password by phone. I was told that I could neither speak with Carole Masson nor leave a message for her. So right now the hotel has an encrypted PDF from me which they cannot view. BTW, the Hotel Concorde phone number given at http://www.ietf.org/meeting/83/hotel.html is wrong. Web page says: +33 1 40 68 50 50 Actual number: +33 1 40 68 50 68 Stuart Cheshire ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
On 3 Jan 2012, at 13:35, Brian E Carpenter wrote: There's a third case, paid a lower rate than the conference rate (usually due to a smart corporate travel agent). I've never understood why conferences don't get a corporate-equivalent rate. Brian Good suggestion Brian. I just called our corporate travel department and got the same rate as IETF, including free Internet and breakfast, and cancel by 6 PM on check-in day. Stuart Cheshire ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Need help tracking down problem accessing IETF Subversion repository on Mac OS X
On 27 Sep 2011, at 7:32, Henrik Levkowetz wrote: Hi, Yoav's tcpdump analysis, together with Martin's observations, helped me find the problem at the server end. I've changed the config now (addding a missing 'NameVirtualHost *:443' to Apache's config), and Stuart's example now works for me on OS X Snow Leopard and Lion: svn info https://svn.tools.ietf.org/svn/wg/hybi Great. Thanks for fixing this. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Need help tracking down problem accessing IETF Subversion repository on Mac OS X
I'm using the IETF Subversion repository, described here: http://trac.tools.ietf.org/misc/venue/wiki/ IetfSpecificFeatures#SourceControlRepositorySVN It used to work for me, but for the last few months, on both OS X SnowLeopard and on Lion, it hasn't worked: % svn info https://svn.tools.ietf.org/svn/wg/hybi svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/hybi': SSL negotiation failed: SSL error code -1/1/336032856 (https:// svn.tools.ietf.org) It's supposed to do this: % svn info https://svn.tools.ietf.org/svn/wg/hybi Path: hybi URL: https://svn.tools.ietf.org/svn/wg/hybi Repository Root: https://svn.tools.ietf.org/svn/wg/hybi Repository UUID: 5e38896a-673a-488c-9143-21546a17fde4 Revision: 137 Node Kind: directory Last Changed Author: ife...@google.com Last Changed Rev: 137 Last Changed Date: 2011-08-31 11:18:27 -0700 (Wed, 31 Aug 2011) If you're on a Mac, can you please try this command for me and let me know if it works for you or gives the 336032856 error? If it's just my machine that's having the problem then I'll continue troubleshooting, but if it turns out that this doesn't work AT ALL for ANY Mac user, then I'll file a bug report. We should probably also update the IETF Wiki page to document this, and if we find a workaround that should go on the page too. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Subversion troubles?
I'm using svn 1.6.15 on Mac OS X 10.6.7. It used to work fine for me, but recently it stopped working. I now get SSL errors, e.g.: % svn ls https://svn.tools.ietf.org/svn/wg/6lowpan svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/6lowpan': SSL negotiation failed: SSL error code -1/1/336032856 (https://svn.tools.ietf.org) If I do the insecure version using http instead of https then it works: % svn ls http://svn.tools.ietf.org/svn/wg/6lowpan 6lowpan-terminology.xml hc/ nd/ packets/ routing-requirements/ usecases/ Is anyone else seeing this problem? Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-zhu-mobileme-doc-04
On 7 Mar 2011, at 3:08 AM, Roni Even wrote: Hi, My impression from reading the document and according to figure 1 was that all end host communication was done in a UDP tunnel. So what is the relation of the TCP connection to BTMM. Roni Even Question: When you use IPSEC VPN, what are the TCP connections used for? Answer: Every application that uses TCP today still uses TCP when TCP is running over the IPSEC VPN. BTMM is an IPv6 overlay network, tunneled over IPv4. Every TCP-based application you run is still a TCP-based application. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
MHonArc mail archive line wrapping
In the MHonArc mail archive there are often super-long lines, which would be wrapped to the window width when viewing in most mail clients, but when viewed in a web browser they appear as long single lines which take a lot of left-to-right scrolling to read them. For example: http://www.ietf.org/mail-archive/web/renum/current/ msg00060.html This appears to be due to MHonArc's use of the PRE tag, which tells the web browser to display the literal text exactly as given, in a fixed-width font. The MHonArc FAQ suggests a couple of solutions to this problem: Can long lines be wrapped in converted messages? http://www.mhonarc.org/MHonArc/doc/faq/mime.html#lineclip Can the PRE tags be removed from converted messages? http://www.mhonarc.org/MHonArc/doc/faq/mime.html#removepre Can we consider using either of these options? Using maxwidth=xxx would solve this problem, though of course it opens the debate about what's the right value for xxx. Using nonfixed has the nice property of letting the web browser wrap the text to the window width, but might break ASCII-art diagrams. Perhaps that could be fixed by making the default font a fixed-width one (e.g. via style sheet) and using the keepspace option, which would give us monospaced text while still allowing the web browser to wrap the text to the current window width. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt (DNS-Based Service Discovery) to Proposed Standard
On 22 Dec 2010, at 23:33, Pekka Savola wrote: What I'm saying is that having to manually pre-configure the hostname in DNS goes against what appears to be one of the main DNS-SD goals, i.e., the host can invent the hostname or use it in a zero-conf fashion. I don't think it's possible to integrate DNS-SD with secure DNS without losing at least some of the properties DNS-SD was designed to address. So it would be unrealistic to require this from the protocol, especially given its background. What I would have wanted to see is more truth in advertising how in practise using security impedes the use of DNS-SD. Which usage modes of DNS-SD can be made to work and at what cost. I see the confusion. Multicast DNS is intended to be zero-configuration. DNS-SD is not necessarily. I have added this to the introduction which should hopefully clarify this: When used with Multicast DNS, DNS-SD can provide zero-configuration operation -- just connect a DNS-SD/mDNS device and its services are advertised on the local link with no further user interaction. When used with conventional unicast DNS, some configuration will usually be required -- such as configuring the device with the DNS domain(s) in which it should advertise its services, and configuring it with the DNS Update [RFC 2136] keys to give it permission to do so. In rare cases, such as a secure corporate network behind a firewall where no DNS Update keys are required, zero-configuration operation may be achieved by simply having the device register its services in a default registration domain it learns from the network (See Section 12 Discovery of Browsing and Registration Domains) but usually security credentials will be required to perform DNS Updates. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12
On 22 Dec 2010, at 2:11 PM, Ben Campbell wrote: -- 14, 1st paragraph: The option to fail-over to Multicast DNS for names not ending in .local. SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. I have trouble imagining any safe circumstance to enable this. Can you offer an example? On an isolated network, or on some future machine that exclusively uses DNSSEC for all DNS queries, thereby guarding itself against spoofing. Some words to that effect in the text would be useful. Done -- Appendix A: Please describe the conclusions, not just the arguments. Arguments were made for and against using Multicast on UDP port 53. The arguments for using a different port were greater in number and more compelling so the final decision was to use UDP port 5353. Text to the effect of ...the final decision... would be helpful in the draft. Done. Section 13 states that something is out of scope for the document. It's conventional to make such statements early in the document. For example, if someone was trying to learn how mDNS is used in service discovery, he might be disappointed to read this far before they discover he was in the wrong place. Moved to introduction. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12
and elaboration of 8.2. -- 8.3, 1st paragrah: gratuitous That seems the wrong choice of words, since such responses are not without cause or reason which is the usual dictionary definition. Maybe unsolicited? (No problem if this is some DNS term of art that I haven't heard.) Changed. -- ..., last paragraph: as described below in Conflict Resolution. Section number cross-references would be helpful. Fixed. -- 9, indented paragraph after numbered list item 5: It's not clear to me if this is supposed to refer to just item 5, or to item 4 and 5. In any case, the advise that one may simply not notify does not seem helpful for case 5. Thanks. That text was supposed to apply to item 4. -- 11, 1st paragraph: These older clients discard all packets with TTLs other than 255. Can you provide a reference for this behavior? How old is old? This includes things like network printers implementing draft- cheshire-dnsext-multicastdns-04.txt, published February 2004. Some of these printers are still around today. -- 12, 4th paragraph: The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The IPv6 name server for a Multicast DNS Domain is FF02::FB. Name server _address_? Changed. -- ..., 6th paragraph: ...delegation of all Multicast DNS Domains to the 224.0.0.251:5353 and [FF02::FB]:5353,... Missing words? Fixed. -- ..., 7th paragraph: Please expand SOA on first mention Fixed. -- 15, last paragraph: Can you provide section cross references for these safeguards? Fixed: Section 10.3 -- 13: Seems like this should be stated early in the document, in the intro, or in a scope section or applicability statement. ? -- 16.3: ...each have their own... its own I disagree: clients is plural. -- 17, 3rd paragraph from end: This seems to imply there are no letters in UTF8 outside the ASCII range. Fixed. -- ..., last paragraph: The simple rules for case-insensitivity in Unicast DNS also apply... Reference? Fixed: [RFC1034] [RFC1035] -- 18, paragraph 3: ...,a Multicast DNS Responder SHOULD send the Resource Record alone, in a single IP datagram, sent using multiple IP fragments. I have trouble parsing this clause. Should sent using just be using? Changed. -- ..., 2nd to last paragraph: Ethernet Jumbo packet Reference? Added reference. -- 19.2 and 19.3: Incomplete sentences Fixed. -- 19.12 and 19.13: References to normative text? Fixed. -- 20, paragraph 1: The value of Multicast DNS is... Is assume you mean a value... or one value...? Changed: Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. -- 23, paragraphs 1 and 2: Can you provide references or pointer to the existing registrations? Added references. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt
On 21 Nov 2010, at 8:44 PM, Doug Barton wrote: That said, I'm reasonably supportive of the draft moving forward Thanks. 1. In Section 4.1, 4th full paragraph, the bit, (because of the limitations of the typing-based user interfaces of that era) should be stricken. It does not add value to the clarity of the text, nor would arguing about whether it's correct or not. I see your point, but I think the text provides useful context to remind readers about the user-interface considerations of that era -- especially young readers who don't remember the time when computers only had text-based interfaces. 2. In that same paragraph, shortly after the above, from a list of choices presented on the screen ... should be something similar to from a list of choices presented by the user interface ... Very good point. Of course, the concept of having a screen doesn't even apply to Apple's new telepathic-projection antimatter-powered iPhone. We've updated the document accordingly. One could also argue that the not intended to ever by typed in should be replaced with the appropriate 2119 language. The text is illustrative, not prescriptive. We have changed the text to say this: Users generally access a service not by typing in the Instance Name, but by selecting it from a list presented by a user interface. 3. In Section 7, 3rd full paragraph, it says, conforming to normal DNS host name rules: Only lower-case letters ... The normal DNS host name rules [citation required] do not permit only lower case letters. I do think however that it would be ok to spell out that this protocol requires that, like what was done with disallowing names without an alphabetic. Good catch. We have removed the incorrect and irrelevant side comment mentioning normal DNS host name rules: Application Protocol Names may be no more than fifteen characters (not counting the mandatory underscore), consisting of only letters, digits, and hyphens, must begin and end with a letter or digit, and must contain at least one letter. The requirement to contain at least one letter is prevent service names such as 80 or 6000-6063 which could be misinterpreted as port numbers or port number ranges. While both upper case and lower case letters may be used for mnemonic clarity, case is ignored for comparison purposes, so the strings HTTP and http refer to the same service. This is however just temporary text, and will be removed entirely when draft-ietf-tsvwg-iana-ports is published. 4. I'm not sure Section 15.2 needs to be in the document at all, although I am not formally opposed to its inclusion. User interface considerations were a central aspect of the design constraints for DNS-SD and mDNS. Rather than design a protocol first and then work out the UI second, with DNS-SD and mDNS we first worked out the user experience we wanted, and then designed the protocols to provide that user experience. This section explains how those requirements influenced the design decisions for the protocol. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt
On 23 Nov 2010, at 12:55 PM, Doug Barton wrote: Allow me to amplify my argument more completely. There are already 2 open source implementations of dns-sd that I'm familiar with, mDNSResponder and avahi; in addition to apple's Rendezvous. The OS versions are mostly interoperable on the protocol level, but not on the binary level. One example that I've been working with lately can be found at http://www.avahi.org/ticket/303. That is an API compatibility issue. The bug report says kDNSServiceFlagsShareConnection not implemented, affects CUPS. You won't find a mention of kDNSServiceFlagsShareConnection anywhere in draft-cheshire-dnsext-dns-sd-07.txt. The IETF specifies on-the-wire protocols, not APIs. There are many different implementations of DNS-SD, with different APIs, for different languages. The fact that people are complaining about subtle differences in one particular API between two different independent implementations should be a sign of how widely deployed this is. Regarding the document itself, I have reservations about the quality of the document, and whether or not it describes the protocol in sufficient detail that someone starting from scratch could develop another interoperable version. I think the Avahi bug report you found is adequate evidence of independent interoperable implementations. However I tend to agree with the point of view that the world is a better place if we have _a_ spec than if we have none, so I'm specifically not asking to re-address all of the concerns that have been discussed previously with the document. However the bit about lower case labels should definitely be fixed (either by removal, a citation, or a clarification that the requirement applies only to this protocol). This has been corrected. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-cheshire-dnsext-multicastdns-12.txt
On 30 Nov 2010, at 9:13 AM, Donald Eastlake wrote: I would suggest that the first word of Section 20, currently The, should be replaced by A major or One of the or the like. Agreed. The document now says: Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. For consistency with RFC 5395, all occurrences of pseudo-RR should be replace with meta-RR dictionary.reference.com says: meta A prefix meaning one level of description higher. If X is some concept then meta-X is data about, or processes operating on, X. For example, a metasyntax is syntax for specifying syntax, metalanguage is a language used to discuss language, meta-data is data about data, and meta-reasoning is reasoning about reasoning. Is that what you mean? A meta resource record is a resource record about resource records. The term pseudo-RR means: “false”, “pretended” or “unreal”. In this context the text is referring to any apparent RR in the packet that's not really an RR, not solely to RRs that describe other RRs. it would not hurt to add a reference to RFC 5395 Where would you like this reference to appear? Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt (DNS-Based Service Discovery) to Proposed Standard
. The _dns-sd string is already in the list at http://www.dns-sd.org/ ServiceTypes.html and will be migrated to IANA as per draft-ietf- tsvwg-iana-ports. Similarly, what would happen if someone named their Application instance '_sub' Nothing bad would happen. '_printer._sub' ? Application protocol names are not allowed to contain dots. 16. IPv6 Considerations IPv6 has no significant differences, except that the address of the SRV record's target host is given by the appropriate IPv6 address records instead of (or in addition to) IPv4 A records. .. well it's not obvious if you count it significant or not, but the reverses IP entries are under a different tree and longer. This comes up e.g. with _dns-sd discovery of browsing domains (S 12). We have updated the document to say: IPv6 has only minor differences. The address of the SRV record's target host is given by the appropriate IPv6 address records instead of (or in addition to) IPv4 A records. Address-based Domain Enumeration queries are performed using names under the IPv6 reverse-mapping tree, which is different to the IPv4 reverse-mapping tree and has longer names in it. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 25 Nov, 2009, at 01:52, W.C.A. Wijngaards wrote: * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. I think you may be misreading this. A statement of MUST do X does not imply MUST NOT do NOT X. A host implementing Multicast DNS, performing a Multicast DNS query, MUST send that query to the Multicast DNS port, or it won't work. There's no SHOULD about it. An implementation cannot choose to send the Multicast DNS query to a different port and expect it to work. A host implementing Multicast DNS generally implements a variety of other name resolution mechanisms like standard unicast DNS, NetBIOS, a local /etc/hosts file, etc., and names can be looked up via those mechanisms too. Indeed, you will find that if you install iTunes on your PC, even at a site that's set up a private DNS server for local, the sky does not fall. What happens is that Windows (and Mac OS X too) look up dot-local names both ways. Looking up names more than one way is not as efficient as it could be, and it might be better if we didn't have to do that, but it does work. I will add some text explaining this. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote: 90% of this proposal is equally relevant to the enterprise case. But the multicast part is not. The document is called Multicast DNS. Which parts of the document do you think do *not* relate to multicast? Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
On 4 Nov, 2008, at 07:50, Cyrus Daboo wrote: Hi, --On November 4, 2008 6:28:19 AM -0800 The IESG iesg- [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC The IANA section of the dns-sd draft describes a process for registration of SRV service identifiers, but there is another draft doing the same thing: http://www.ietf.org/internet-drafts/draft- gudmundsson-dns-srv-iana-registry-00.txt. So which of these two drafts is meant to define the actual SRV service type registry? -- Cyrus Daboo That text has been in DNS-SD since the start, back in 2001 when it was called Discovering Named Instances of Abstract Services using DNS (draft-cheshire-dnsext-nias-00.txt). I have absolutely no ego at stake over ownership of that issue -- I simply put it in because someone pointed out that RFC 2782 failed to define an IANA registry for its service names, and since DNS-SD/NIAS depends on SRV records and identifying service types by name instead of number, without an IANA registry the specification would be somewhat handicapped. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-hoffman-utf8-rfcs-03.txt
On 6 Oct, 2008, at 11:38, John C Klensin wrote: (2) The document seems to assume that availability of UTF-8 systems (or other systems based on Unicode with easy transcoding) is now near-ubiquitous. Actual experience, especially with documents being transmitted between computers by email and similar means, appears to be different. While I look forward to the day at which comprehensive UTF-8 support is universally available, at least as an interchange format, I do not believe that we are there yet... John, Paul Hoffman appears to be operating on the assumption that UTF-8-capable software is widely available today on most platforms; you appear to believe otherwise. It might be helpful if both of you (and others) could provide specific examples supporting those positions. Then we can work out how many people in reality are likely to have trouble reading UTF-8 documents. Speaking from my own experience, Unicode and UTF-8 have been supported in all versions of Mac OS X, and in Mac OS 9 before that. This means that any Macintosh computer sold in about the last ten years can handle UTF-8. Windows, Linux, etc., have probably had UTF-8 support for a similar length of time (others may be able to supply precise dates). A ten-year old Mac running Mac OS 9 certainly won't be able to display every glyph in today's Unicode character set, but it can read a UTF-8 format file, decode the bytes correctly, display the Unicode characters it knows, and display placeholders for the ones it doesn't. Perhaps a workable compromise is to specify UTF-8 as the encoding for RFCs, but limited today to some subset of the full Unicode character set. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa [EMAIL PROTECTED] wrote: Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. You may be interested to know that this is the direction we took with Multicast DNS and DNS-based Service Discovery (what Apple calls Bonjour). Every machine runs a little process called 'mdnsd' that answers peer-to-peer SRV queries. The registry of application names (i.e. protocol names) is currently maintained at: http://www.dns-sd.org/ServiceTypes.html Right now there are a couple of hundred application-layer protocols implemented that work this way. They bind to zero, get a random port assigned by the OS, and then register that port with the local 'mdnsd' service. The 'mdnsd' service also offers a workaround for the limitations of NAT. If you have a NAT gateway that speaks NAT-PMP (or the UPnP equivalent), then when the application registers its port with the local 'mdnsd' service, mdnsd talks to the NAT gateway, gets a public-to-private inbound port mapping created, and then mdnsd writes an SRV record into your DNS server (requires permission to update a DNS subdomain where Secure DNS Update is enabled) giving the *PUBLIC* IP address and port for your service. The result of this is that when you turn on Personal File Sharing on your Mac at home behind a NAT gateway, then if you want to, you can advertise that service globally. The port number won't be the usual well-known port for Apple Personal File Sharing, but as long as the client looks up the service via SRV record, it will find the correct port to connect to. Details are given at: http://www.dns-sd.org/ClientSetup.html Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Summary of the LLMNR Last Call
(3) Separate, but perhaps underlying both of the previous issues, there seems be a fundamental disagreement about what technical approach we should take to link-local name lookup. LLMNR takes the approach that local lookups should use the same names as global lookups and that upper layers should not care whether a name was resolved in the global DNS or locally, essentially making the local lookup mechanism an extension of the DNS. mDNS takes the approach that local lookups should be distinguishable from global lookups and accomplishes this through the use of a special local domain (.local). This claim is one of the bits of misinformation that seems to be spread about mDNS for some reason. It's repeated so often that people who haven't read the draft assume it's true. Even on Mac OS 9, five years ago, if you looked up www.ietf.org and had no unicast DNS servers configured, it would look it up via mDNS instead. The difference is that we were profoundly nervous about the implications of doing this without adequate security, which is why draft-cheshire-dnsext-multicastdns.txt allows multicast lookups for non-local names, but says: (14. Enabling and Disabling Multicast DNS) The option to fail-over to Multicast DNS for names not ending in .local. SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. (24. Security Considerations) When DNS queries for *global* DNS names are sent to the mDNS multicast address (during network outages which disrupt communication with the greater Internet) it is *especially* important to use DNSSEC, because the user may have the impression that he or she is communicating with some authentic host, when in fact he or she is really communicating with some local host that is merely masquerading as that name. The difference between mDNS and LLMNR is not in their lookup of global names, but that mDNS *also* designates a special sub-tree of the namespace where users explicitly have different security expectations. We have an expectation of what www.ietf.org means. Our expectation of what webserver.local means is different -- we know it's just a local, temporary, transient name. We might do on-line banking at www.bankofamerica.com, but never at moneybank.local. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Christian Huitema wrote: if an application tries to resolve host.local through, say, gethostbyname, then the query will indeed be forwarded to the local DNS service. The responsibility for the .local traffic lies mostly into whoever is promoting use of this top level domain and coding that use in applications. That would be Microsoft: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296250GSSNB=1 The Domain Name System name recommendations for Small Business Server 2000 and Windows Small Business Server 2003 July 16, 2004 Make the name a private domain name that is used for name resolution on the internal Small Business Server network. This name is usually configured with the first-level domain of .local. At the present time, the .local domain name is not registered on the Internet. The natural separation of internal and external networks occurs because of the use of a separate internal namespace. A client query generated from the Internet for www.contoso.local does not return any valid domain information because .local, at the present time, is not a registered domain name. Name resolution problems that are created by using a publicly registered domain name can be avoided by planning the private namespace around a .local first-level domain so that, in this example, Contoso.com and Contoso.local are both available to internal clients, but Contoso.com is only available to external internet clients. A suspicious person might think that the reason Microsoft is trying to encourage its customers to use .local is a deliberate attempt to foster interoperability problems with machines running mDNS. I do not think that. I'm sure there must be a perfectly reasonable non-Machiavelian explanation for why Microsoft is advocating use of the .local DNS domain. I just don't know what it is right now. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
Harald Tveit Alvestrand wrote: We're probably rehashing the DNSEXT discussion here, but I wasn't part of the DNSEXT discussion. LLMNR allows me to treat names in a different way than mDNS does. If I have a name that I'm certain I own (this box is, with high certainty, the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to assert that name on a LAN even when the DNS is not available, or when that name is not currently asserted in the DNS. mDNS, as I understand it, doesn't allow me to do that - I would have to assert HALVESTR-W2K02.local, or HALVESTR-W2K02.emea.cisco.com.local. No, this is completely wrong. There are *two* important goals of mDNS: Goal 1: I have a legitimate FQDN, and connectivity with my peers, but no connectivity to the greater Internet right now. In this mode, mDNS (like LLMNR) is providing fail-over for unicast DNS. Even on Mac OS 9, five years ago, if you looked up www.ietf.org and had no unicast DNS servers configured, it would look it up via mDNS instead. Goal 2: I have no legitimate FQDN. I just need a temporary no-frills name I can use for the time being. This is so that, for example, every HP printer can ship from the factory with the name hp-printer.local, which is at least good enough for bootstrapping until the customer has assigned a legitimate FQDN for the printer. This is what mDNS uses the .local namespace for. It's a free-for-all sand box where all names are up for grabs and no names are quite trustworthy. LLMNR seeks to solve the first goal but not the second, but in failing to provide a sand box for ad hoc names, it makes the entire DNS namespace a sand box for ad hoc names. mDNS seeks to address both problems, but we're aware that looking up general DNS names via unauthenticated local multicast queries has horrible security implications, and we're aware that today we're not confident that we know how to solve that problem, so the mDNS draft recommends: (14. Enabling and Disabling Multicast DNS) The option to fail-over to Multicast DNS for names not ending in .local. SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. (24. Security Considerations) When DNS queries for *global* DNS names are sent to the mDNS multicast address (during network outages which disrupt communication with the greater Internet) it is *especially* important to use DNSSEC, because the user may have the impression that he or she is communicating with some authentic host, when in fact he or she is really communicating with some local host that is merely masquerading as that name. The difference between LLMNR and mDNS here seems to be that mDNS *requires* me to use two different names in the two different cases; LLMNR, while it certainly *permits* me to do so, does not *require* it. Absolutely not. mDNS allows you to have a single FQDN, and answer those queries via multicast, but recognizes that we need solid security mechanisms before we can honestly recommend that. LLMNR allows you to have a single FQDN, and ignores the security risks. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Christian Huitema wrote: Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default. Christian, could you please tell us, for each OS mentioned, how to enable LLMNR? That would enable everyone participating in this discussion to witness for themselves exactly how it works and what it does. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
water works just as well? Go and drain your oil right now and replace it with good old clean, environmentally-friendly tap-water. If everyone actually did that, we'd all find out -- too late -- on the drive to work tomorrow what a terrible idea it was. So, what am I asked for, specifically? For the IETF to stop representing LLMNR as a superior drop-in replacement for mDNS. That's all, really. One idea that's been suggested is that both LLMNR and mDNS could be published as Informational RFCs, or both as Experimantal, and then we'll let the experiments run and possibly standardize one in the future. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Peter, I'm afraid I don't understand. As far as I can understand, mDNS uses the .local pseudo-domain and LLMNR does not. So how can LLMNR be blamed for bogus queries for *.local? Simple: If you call your printer myprinter.local, and then type ping myprinter.local, LLMNR will *always* send a DNS query to the root first, before rolling over to a local multicast query, whereas mDNS (except when operating in Microsoft compatibility mode) will *never* send a dot-local query anywhere other than the local LAN. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
As I understand it, one of three things will happen: (1) If the system implements mDNS, the .local domain is treated specially, so this just goes out as a link-local request. (2) If the system implements LLMNR, there will first be a global DNS lookup for twiki.local, which will fail. Then, a link-local name request will be tried. (3) If the system doesn't implement any link-local name resolution, there will be a global lookup for twiki.local which will fail. So, if people use .local domains on systems that implement LLMNR instead of mDNS, this can result in lookups for .local in the global DNS. But, given that choices (2) and (3) involve the same interaction with the DNS, I'm not sure how one can argue that LLMNR makes things any worse than things would be without it. Perhaps you could argue that mDNS makes things better, but that is only true for this one non-existent TLD -- all three systems would generate a bogus global DNS query if I did a DNS lookup for isoc.frog. Margaret There's one other relevant difference to note here: If you do a DNS lookup for isoc.frog you generate a bogus global DNS query. This is true. But... do you habitually do DNS lookups for isoc.frog? Well, in case 1 (mDNS), no, because it won't return a useful result, so why keep doing it? In case 3 (conventional DNS), no, because it won't return a useful result, so why keep doing it? In case 2 (LLMNR) the answer is yes, all the time, if you chose to call your printer isoc.frog, which LLMNR allows and encourages. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
I do not understand how defining a new, different service on a new port will kill anything. Are you saying that you *REALLY* do not understand how the IETF defining a new protocol, and stating publicly that it's intended to compete with some established protocol, gives all the appearance of an attempt to kill off that existing protocol? An attempt to split implementers into two non-interoperating camps? An attempt to cause customers and other implementers to put off making a decision on either protocol while they wait to see which camp wins? Of course LLMNR won't actually kill off mDNS, but there's a real risk of it causing confusion and delay. And, in the process, the failed effort to kill off mDNS squanders the IETF's credibility. Before you claim that LLMNR was not intended to compete with mDNS, this is from Bernard Aboba's LLMNR FAQ: http://www.drizzle.com/~aboba/DNSEXT/llmnrfaq.html Rendezvous [Bonjour] is an individual submission that is not a work item of any IETF working group, and is currently not an IETF standard. While it is possible for an individual submission to become an IETF standard, this is unlikely in this case because an existing WG (DNSEXT) is already working on a competing protocol (LLMNR) Before you claim that it's not causing confusion in the broader community, this is from the Wikipedia entry for Zeroconf: http://en.wikipedia.org/wiki/Zeroconf Name resolution There are two very similar ways of figuring out which networked item has a certain name. Apple Computer's Multicast DNS (mDNS) is in use, but is not an IETF standard. Microsoft's Link-local Multicast Name Resolution (LLMNR) is not yet being used, but is being officially standardized by the IETF. There's a clear message being promulgated that the two protocols are more-or-less equivalent in functionality, the only significant difference being that one has the endorsement of the IETF and the other doesn't. It would go a long way to ease my concerns if the LLMNR specification stated clearly in its introduction that it's NOT intended to compete with mDNS, because LLMNR doesn't have any of the functionality that mDNS provides to enable network browsing and service discovery. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Stuart, do you have a published specification of Apple's mDNS that you can point people at, so that people can understand what functionality mDNS has that LLMNR does not? Certainly. The framework document, describing what we need and why we need it, is: Requirements for a Protocol to Replace AppleTalk NBP http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-nbp-04.txt (32 pages) The two specification documents that, when used together, meet those requirements are: Multicast DNS http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-05. txt (45 pages) DNS-Based Service Discovery http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-dns-sd-03.txt (32 pages) Although the documents are complementary, we made an effort to keep a clean separation between the encoding of service discovery using DNS records (DNS-SD), and the transport of those records using multicast (mDNS). This makes it possible and fruitful to use one without the other, for example, wide-area DNS-SD service discovery performed via standard unicast DNS queries: http://www.dns-sd.org/ClientSetup.html http://www.dns-sd.org/ServerSetup.html Although the documents are separate, much of what's in mDNS is there to make DNS-SD work better. Some examples: * Because a given device may advertise many services, or be looking for many services, we allow several questions to be packed into a single query packet for efficiency. Semantically, a single query packet containing multiple questions is treated by receivers as exactly the same as multiple packets containing one question each. The only difference is that it's more efficient on the wire. (In addition to saving header overhead, where the queries are similar, DNS name compression can come into play.) * Because of packet loss, a question may need to be retransmitted more than once. Because of the nature of service discovery, a single question may elicit a hundred responses, not just one. How do we reconcile these two aspects? Every time we retransmit a query, we don't want to get bombed with the same hundred responses. In fact, if the flood of packets caused some slow device's response to get lost the first time, it's likely to get lost in each subsequent flood of packets too. The solution we worked out for this is to use the answer section of the query to list the already-known answers. This suppresses redundant responses from the hundred devices we've already heard from, and gives the slow one a chance to be heard. One property that a lot of these extensions have in common is that they can be safely omitted if all you want to do is look up host names. A client doesn't have to put anything in the answer section of a query, if the implementer chooses not to. A responder doesn't have to consult the answer section of a query, if the implementer chooses not to. This might mean lost opportunities to suppress unnecessary responses, but you could argue that for simple host name lookup you can live without that. It's very easy to make a simplified compatible subset of mDNS. Putting service discovery requirements aside for a moment, the other big difference between mDNS and LLMNR is that mDNS facilitates local-scoped names, analogous to RFC 1918 addresses. LLMNR lets you look up a host name without a DNS server, but it pre-supposes that you HAVE a globally unique fully-qualified host name in the first place. In contrast, mDNS says you can call your television tv.local if you want, and you don't need to pay anyone for that name, or ask permission, or know how to register it in some global database, but at the same time the name has only local significance so don't expect it to be usable worldwide. What's weird about LLMNR is that it blurs what's global and what's local. With LLMNR you can call your television tv.ietf.org if you want, and as long as the IETF's name server returns NXDOMAIN (which it does today) then a LLMNR-compliant host will fail over to local multicast and resolve that name to your television's address. This sends a very strange message to end users -- it suggests they can use any name they want in any domain they want without having to communicate with any registry. It also means that every failed DNS query will result in a LLMNR multicast on the local network, and (worse) every intentional LLMNR query needs to be preceded by a failed DNS query to some unsuspecting DNS server somewhere. mDNS says that local is a free-for-all playground where anyone can use any name and no one has any more right to a particular name than anyone else. LLMNR didn't want to do that, but what they've effectively ended up doing instead is saying that the root of the DNS namespace (and everything below it) is a free-for-all playground where anyone can use any name they want. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
I don't see anything in RFC 2026 criteria that hinges on whether Microsoft intends to implement a protocol. Is doesn't have to be Microsoft. Is there *anyone* out there who has implemented this, or plans to? Or am I just being old-fashioned in thinking that the idea behind a protocol specified in an RFC is that someone somewhere might implement it? Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
In The Public-Root there used to exist a domain .local. I know at least of one ISP who complained we did break a lot of windowed PCs. I dont know why queries for .local would leave their private LANs and reach even our root servers. They did! That is why we set up a dummy and returned localhost, to get rid of those bogus queries. That is what finally broke their windows and dropped our root server traffic some 25%. :) I don't think this has anything to do with mDNS or LLMNR. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
It is not typical for us to make statements in our standards regarding what proprietary mechanisms our standards are or are not intended to compete with, nor do we typically include statements that compare the features of our standards to proprietary protocols. Please stop calling it proprietary. The mDNS specificiation is publicly available, and is the result of many years of open public discussion. There are multiple independent open source implementations. Just because a certain IETF inner circle decided to turn their backs on it doesn't make it proprietary. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
. Something that would have the appearance of being the official successor to mDNS, a siren to lure potential implementers onto the rocks. Now, I can already hear a certain minority saying, You've convinced me. LLMNR should be published as an IETF Standard. Apple's heresy must be stopped at any cost. The question for the wider IETF community is whether that's what the IETF wants to do. Is the role of the IETF to foster interoperability, or to sabotage it? Are Internet Standard RFCs supposed to be useful things to be implemented, or are they supposed to be traps to ensnare the uninformed? It reminds me of OSI. We had a perfectly good networking protocol -- TCP/IP -- so ISO decided they needed to make their own similar-but-not-quite-the-same protocol to compete with it, just for the sake of not wanting to adopt something invented elsewhere. ISO thought that because they were an official standards body, whereas TCP/IP was just something that a bunch of guys had made that happened to work, that ISO could, by legislative fiat, oust the successful incumbent protocol. How many man-years of work were wasted by that abortive effort? Did OSI emerge from that debacle looking good, or looking bad? In fact, this comparison to OSI is overly generous. OSI was implemented and actually worked. It was just unnecessary. The problem with LLMNR is that it is deliberately limited to prevent it from being used for service discovery, which, you may recall, was the whole motivation for beginning this work in the first place. LLMNR is presented as being the official sanctioned successor to mDNS, as if it were somehow equivalent in functionality but better designed, while in fact it is so self-contradictory and nonsensical that it actually does nothing useful at all. Time and time again LLMNR has come up for last call. Each time I read it, and point out the fatal flaws and contradictions (that would have been painfully obvious to anyone had they actually tried to implement it). A few changes get made, and the document comes back around again. Piece by piece I'm designing a protocol for my competitors, so they can use it to compete with my own! If the proponents of LLMNR are sincerely supporting it because they believe it offers useful functionality (and I like to believe that's the case), then lets see some actual implementations. Whatever happened to rough consensus and RUNNING CODE? Once we have some actual implementations to try out, then we can compare them with mDNS and see what might be necessary (on both sides) to make them interoperate usefully. I'm quite happy for LLMNR to be a compatible subset of mDNS. What's silly is for LLMNR to be gratuitously incompatible for the sake of being incompatible. Bernard Aboba has an FAQ Web site where he writes: http://www.drizzle.com/~aboba/DNSEXT/llmnrfaq.html Apple's mDNS protocol differs from LLMNR (and DNS) in more than half a dozen ways. He then goes on to list a bunch of similarities like Apple's mDNS does not share the DNS cache, and finishes with: Apple mDNS and LLMNR use different ports, as well as different multicast addresses, and because of the many protocol differences, do not interoperate. Isn't that circular logic? They use different ports and multicast addresses because they're incompatible, but the main reason they're incompatible is because they use different ports and multicast addresses? Surely that particular incompatibility could be remedied easily, merely by NOT choosing to use a different port and multicast address? Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Zero Configuration Printers in Terminal Room
At IETF 63 in Paris, the helpful terminal room people are, as is customary, distributing sheets of paper with instructions saying how to set up printing on various different operating systems. This quick email is just to point out that the Mac users here don't actually need to follow the printing instructions on that sheet. If you're using a Mac, you don't need to open System Preferences, or add, set up, or configure anything. When you plug your laptop into one of the Ethernet connections in the terminal room area and bring up the Print dialog box in any application, you'll see that the two HP printers are already there, as if by magic, in the Printer popup menu, under the Bonjour heading. They call themselves Term-01 and Term-02. All network printers manufactured in the last year or two by HP, or pretty much any other printer maker, do this. Windows users can get Bonjour for Windows from http://www.apple.com/bonjour Stuart Cheshire [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Zero Configuration Printers in Terminal Room
While Stewart is absolutely 100% correct from a technical standpoint, we'd really appreciate it if you didn't do that. We very specifically didn't advertise the addresses of the printers directly, but rather pointed everyone at a print spooler. This is for several reasons. First, this gives the terminal room staff more of an ability to clear out large or broken jobs if something goes awry. Secondly, it allows for a much deeper queue, should a big job or two come in at a peek printing time. Finally, the Terminal_Room_Printers queue distributes jobs across both printers. So, if making those few extra clicks don't overtax people too much, we'd greatly appreciate following the instructions as distributed. Thanks! You can easily advertise your print spooler, if you want, so that it shows up as an available print service in the Printer menu's Bonjour list, just like the printers themselves do. All you have to do is add a few lines to the DNS zone file for ietf.org: ; Enable drowsing for this domain b._dns-sd._udp PTR @ db._dns-sd._udpPTR @ lb._dns-sd._udpPTR @ ; Advertise Print Service $INCLUDE ietf63printers _printer._tcp The text of the ietf63printers file goes something like this (except you'd replace the information below with the information pertaining to the print spooler you want to advertise): @ IN PTR IETF\ 63\ Printer\ A\ \(Term-01\) PTR IETF\ 63\ Printer\ B\ \(Term-02\) IETF\ 63\ Printer\ A\ \(Term-01\) SRV 0 0 515 wired-4-10 TXT pdl=application/postscript wired-4-10 A 86.255.4.10 IETF\ 63\ Printer\ B\ \(Term-02\) SRV 0 0 515 wired-4-11 TXT pdl=application/postscript wired-4-11 A 86.255.4.11 Any client machine with ietf.org as a search domain (e.g. learned via DHCP) will then automatically discover these advertised print services. To demonstrate the example, I've set up ietfprinters.org as illustrated above. Mac OS X 10.4 users can see for themselves how it works by manually entering ietfprinters.org into their list of search domains, and the advertised print services will magically appear in the print dialog. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Printing at IETF 56
The terminal room information sheet for IETF 56 includes instructions for how to set up printing for Windows machines, and instructions for how to set up printing for Unix machines, but no mention of Macs. Does this mean that printing from Macs is not supported? On the contrary, it means that printing from Macs doesn't require instructions. In the print dialog of any application on OS X 10.2, just click on the Printer popup menu, select the Rendezvous Printers submenu, and select the printer called IETF 56 Printer. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org
Re: arp self reference
Hi, for references purposes, I tried to find in the RFCs without success a reference describing the arp self mechanism, which is used by many implementations in IPv4 to verify the usability of an address. Anyone can help me find the reference? thanks in advance. Marc. See http://www.ietf.org/internet-drafts/ draft-ietf-zeroconf-ipv4-linklocal-03.txt. This cleared WG last-call in April, and has been submitted to the IESG for advancement to Proposed Standard. See sections 2.2. and 2.3. Note that though this draft discusses probing and collision detection for link-local addresses, it is advisable to do this for all IPv4 addresses, no matter how they are configured. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org
Re: IETF Wireless
I'm getting a flood of individual questions here, so I'll stem the flow by answering them publicly: That would be great. Will they sell them at a discount to the rest of us? The current retail price of $300 is already a "discount" price. For that price you get 11Mb/s wireless, 10Mb/s Ethernet with DHCP client, a 56k modem with PPP, DHCP server on both wired and wireless interfaces, DNS relay, Ethernet-level bridging, IP-level routing, WEP encryption, nice configuration software (that runs on a Mac) and even (ugh!) a NAT gateway. I'll let you speculate about how much profit Apple makes on each unit. For details, see http://www.apple.com/airport/. One word of warning, before you rush out and buy one: Understand that Apple makes this product in order to sell more Macs (all Macs, desktop and laptop, come with dual antennas moulded into the plastics and a slot for the $99 add-on card). If, after you buy a base station, you call the Apple support line and start your question with, "I have this Intel laptop running Linux...", then they are unlikely to give you much sympathy. If this is a problem for you, you should avoid buying a wireless base station from Apple. Many other vendors, including Lucent, sell them too. Bill Fenner has a page of unofficial information about the Apple wireless base station: http://www.aciri.org/fenner/airport/airport.html My reason for offering these to the IETF is to help the IETF, and within reason I will do as much as I can to help the IETF use them, including sitting there with my Mac laptop to configure them if necessary, but Apple does not extend that offer in general to every PC owner. the "gold" level of encryption may be important to lots of people, but as far as I know, the AirPort basestations only support the weaker crypto. AirPort base stations are fully 100% compatible with end-to-end IPSEC :-) Besides, if you tell 3000 people at an IETF meeting the single shared network key, it hardly matters how many bits are in it -- it's simply not a secret any more. AirPort uses the Lucent Silver card, which Lucent calls "64-bit RC4", even though 24 of the bits are a fixed "seed" value. Apple calls this "40-bit RC4", which is a little more honest. - It has no way to add extenal antennas to boost signal. Not true. I know people who've drilled a little hole in the case and attached an external Lucent antenna to the card inside. Stuart, if I recall, the beacons (base stations) can't be configured without an Apple laptop running an appropriate version of the software and operating system. Has that changed? If not, I have no idea whether we have such machines available or how we would find or scrounge one (and presumably a second as backup) to make the donation viable (the Lucent bridges that have been most often used of late can be configured from any of Win NT, Win95/98, or some U**x flavors). There are unsupported tools to configure AirPorts from Windows, and I've even heard that there's a Java version too. However, I'd recommend just setting them all to simple Ethernet-level bridging, and disabling all the other features, and then you don't ever need to reconfigure them again. I have several PC-owning friends who use AirPorts like this. Is there a way to turn off the NAT in the AirPort access points? We've had trouble here with PCs using them because the NAT implementation doesn't handle NETBIOS. Also, given the general dislike of many people in the IETF for NAT, it may not be something that the IETF wants to use itself. Ha! Made me laugh. Do you seriously think I'd let Apple ship a product that forced you to use NAT? Be serious! Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer
