RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
[for as112 project: maybe add .local into the list of domains??] On Wed, 2005-08-31 at 14:24 -0700, 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. You would have to get an experimental implementation of LLMNR from some developer site. This is not 'simply enabling it' :) And then I also wonder if there actually is an implementation for Win98/Win2k those two being pretty old and quite unsupported by now I guess... but this besides the point. To the best of my knowledge, Microsoft is not shipping this code. In these systems, ad hoc names are resolved through NETBIOS. The .local queries observed in Peter's root servers is most certainly not caused by an LLMNR implementation. They are most likely done by these nice DSL router (NAT :) setups. Most of these devices have a .local zone configured too. I would not be surprised if these leaked their queries to the root servers. That said, if people want to limit the effect of these 'bogus' queries onto the root servers I suggest that ISP's join into the AS112 project. Also it would maybe be an idea for AS112 to add .local there? Greets, Jeroen PS: Who ever named the LLMNR draft 'mdns' isn't that completely confusing for people looking up the mDNS draft, that is the protocol that Stuart made? :) signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])
Tony Finch wrote: the author can't say updates 2822, how should he fix it ? As you said the 822 issue is mentioned in the senderid-pra draft. Regarding RFC 822, the S-ID draft doesn't mention the fact that a large proportion of software which does something useful with Resent- headers still implements the 822 syntax, not the 2822 syntax. Except from all PRA-purposes and maybe MUAs displaying these Resent-* header fields somehow (822 or 2822): What other uses do you have in mind ? Maybe that was discussed somewhere in MARID last year, in that case I either missed it or didn't get it. A related issue, apparently 2822 twisted the syntax (more than one Resent-* block allowed) _and_ the semantics. Dave's old 822 concept could reflect forwarding (maybe - I'm not sure). If that's true 822-Resent-* and PRA are semantically similar, the only missing piece would be to either allow more than one block (like 2822), or invalidate old Resent-* header fields somehow, e.g. William's Original-* idea. While I'm at it: How's that supposed to work with RfC 2476bis 8.1 MAY add Sender ? Apparently 2476bis 8.1 is still based on the old 822-concept of Resent-* (?) Or does it ignore the issue ? Is this part of the PRA-mess in fact our fault (for a definition of TINW including everybody who reviewed the gellens-submit drafts) ? Of course I watched 2476 6.1 (and also 8.1), it's essential for stuff like draft-hutzler-spamops or op=auth, but something with Resent-* is very odd, and it's not necessarily PRA. Bye ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Jeroen Massar wrote: [for as112 project: maybe add .local into the list of domains??] (?) Better add .local to a hypothetical 2606bis. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
On Thu, 2005-09-01 at 09:38 +0200, Frank Ellermann wrote: Jeroen Massar wrote: [for as112 project: maybe add .local into the list of domains??] (?) Better add .local to a hypothetical 2606bis. Bye, Frank Full ack. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Keith Moore writes (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)'to Proposed Standard): The whole idea that local names should look like DNS names and be queried through the same APIs and user interfaces seems, well, wrong (or dubious at best), and needs serious study for the implications of applications using those APIs and the impact of such names on DNS, no? No. Or at least, the point of having something like a link-local name resolution protocol is that you can use the same interfaces to look up the local names when using the link-local protocol, as you do when looking up real DNS names when using the real DNS protocol. That way all the existing applications work and don't need to be changed. Otherwise you would be suggesting building an entirely new protocol and application stack, with changes to every application to support the link-local scheme, which is obviously out of the question. So what you're saying is that you're opposed to whole concept of link-local name resolution. And that therefore you favour LLMNR because it doesn't (in your view) provide it ! Of course you are wrong on this last point - LLMNR will be deployed behind the same APIs currently used to do real DNS lookups. I think that what you've done with your posting, really, is demonstrate Stuart Cheshire's claim that LLMNR is for blocking effort ! IMO, local names and a lookup service for local names would be extremely useful, but neither the names nor the query interface should look much like DNS - the names should look different because otherwise there's too much potential for confusion with DNS names, and the query service should look different because local name lookup service probably can't make the same kinds of consistency or stability assurances that DNS does. To say that, is to say that work on LLMNR should never have been started. There is no demand for a local name resolution protocol which doesn't present a DNS API to applications. You may well say that the whole concept of local name resolution, if it must be presented to applications behind a DNS API, is a bad idea and I have some sympathy with that view - but that's no argument for LLMNR against mDNS ! Stuart seems to be claiming that the people who first told him to take is mDNS away from the IETF, and LLMNR's authors, have that view - and that LLMNR is the result of those people producing a protocol which is intended to look enough like mDNS to fool people but is deliberately _not_ intended to do any of the things that mDNS is good for ! Ian. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
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. If we separate the concept of name ownership from name assertion mechanism, and regard the DNS as just one mechanism of name assertion, then the problem reduces to how do I prove that I have rights to the name, rather than what name should I assert. I think the LLMNR spec, which only talks about mechanism, is missing a reference to some other document (which may not exist, being too controversial to get written) laying out a theory of name ownership, in which both DNS and LLMNR fit as assertion mechanisms. Not that I can say, based on this, that one of (LLMNR, mDNS) is better than the other. But it certainly emphasizes the fact that they're attacking the problem from completely different perspectives. Harald --On 31. august 2005 23:34 -0400 Keith Moore moore@cs.utk.edu wrote: Dave Singer wrote: The whole idea that 'real DNS' can arbitrarily pre-empt local name resolution seems, well, wrong, and needs serious study for security implications for the services using those names, no? The whole idea that local names should look like DNS names and be queried through the same APIs and user interfaces seems, well, wrong (or dubious at best), and needs serious study for the implications of applications using those APIs and the impact of such names on DNS, no? IMO, local names and a lookup service for local names would be extremely useful, but neither the names nor the query interface should look much like DNS - the names should look different because otherwise there's too much potential for confusion with DNS names, and the query service should look different because local name lookup service probably can't make the same kinds of consistency or stability assurances that DNS does. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf pgpDFkplxjNJZ.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
FAKE A friend just called to teach me how to spell LLMNR. Sorry I can not do that without looking it up. And he told me not to be so harsh with it. Yes they need it. Their bot controler needs it. No, you dont need a windows for the controler, MAC or Linux does nicely. But the total cost of ownership of a hijacked windows - you know ... And he asked my not to tell you the details, like windows caching used horseshoes or Netbios packets remotely looking like DNS, or he would shot me or ask the Apple Music Company (no, not the MAC people) to do it :) /FAKE Kind regards, Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Dave Singer wrote: I'm a by-stander on this discussion, maybe off-base or out of it -- but something other than the undesirable traffic struck me. Isn't it also true that I might *deliberately break* all sorts of things by introducing 'blocking' names into DNS responses, so that an LLMNR request is never issued. So an ISP could 'grab' traffic that the users thought was local, by replying to a DNS request in a proxy (or converting a negative reply into an answer). Yes, we have done that accidently. We were told we have broken things on windows by publishing .local in the Public-Root. We stopped publishing that domain immediately. But yes, all you have to do is send some random packets, resolving '.local' to the windows box. The thing will happily cache them and next time ... Also, ISPs might be tempted to start turning around DNS requests in their proxies for names that they *think* should be answered by LLMNR, returning resolution failure, so as not to send too much traffic outbound. This pre-empts the real DNS from ever actually replying. The whole idea that 'real DNS' can arbitrarily pre-empt local name resolution seems, well, wrong, and needs serious study for security implications for the services using those names, no? -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
The whole idea that local names should look like DNS names and be queried through the same APIs and user interfaces seems, well, wrong (or dubious at best), and needs serious study for the implications of applications using those APIs and the impact of such names on DNS, no? No. Or at least, the point of having something like a link-local name resolution protocol is that you can use the same interfaces to look up the local names when using the link-local protocol, as you do when looking up real DNS names when using the real DNS protocol. That way all the existing applications work and don't need to be changed. False. That way, you break various kinds of applications because you violate assumptions that those applications quite reasonably made about the APIs and services they were using, and you flood the DNS with useless queries. This is the same kind of problem that resulted from introduction of NAT. Otherwise you would be suggesting building an entirely new protocol and application stack, with changes to every application to support the link-local scheme, which is obviously out of the question. Actually, it's the only approach that makes any sense. The idea that you can substitute a name service that works differently from what applications expect, without breaking some of those applications, is extremely naive. So what you're saying is that you're opposed to whole concept of link-local name resolution. No, I'm opposed to the concept of confusing resolution of local names with resolution of DNS names. And that therefore you favour LLMNR because it doesn't (in your view) provide it ! LLMNR isn't a competitor to mDNS. They attempt to address different problems. I favor adoption of LLMNR because in a world of disconnected and intermittently connected networks there's a need for applications to still be able to work - and being able to work includes being able to lookup the same DNS names that the applications would normally use in a connected network. I favor discouraging use of mDNS because I believe it harms interoperability of Internet applications and operation of the DNS. I would like to see a solution for the lookup of local names that did not have these characteristics. If that solution can be derived from the mDNS protocol, that's fine with me, but it shouldn't overload the DNS lookup APIs nor should it borrow the DNS name syntax. Of course you are wrong on this last point - LLMNR will be deployed behind the same APIs currently used to do real DNS lookups. LLMNR doesn't provide lookups for local names - it provides a local service that can be used to query for attributes of DNS names. IMO, local names and a lookup service for local names would be extremely useful, but neither the names nor the query interface should look much like DNS - the names should look different because otherwise there's too much potential for confusion with DNS names, and the query service should look different because local name lookup service probably can't make the same kinds of consistency or stability assurances that DNS does. To say that, is to say that work on LLMNR should never have been started. There is no demand for a local name resolution protocol which doesn't present a DNS API to applications. You appear to be confusing a protocol for resolving names locally with a protocol for resolving local names. They don't have to be the same thing. You may well say that the whole concept of local name resolution, if it must be presented to applications behind a DNS API, is a bad idea and I have some sympathy with that view - but that's no argument for LLMNR against mDNS ! Stuart seems to be claiming that the people who first told him to take is mDNS away from the IETF, and LLMNR's authors, have that view - and that LLMNR is the result of those people producing a protocol which is intended to look enough like mDNS to fool people but is deliberately _not_ intended to do any of the things that mDNS is good for ! LLMNR _looks like_ mDNS because both were intended for looking up names on a disconnected network, and because both were based on DNS. That doesn't mean LLMNR _is trying to solve the same problem_ as mDNS. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Maybe something like a Service Location Protocol, so that one could query by a combination of properties, not just name? Keith Moore wrote: Dave Singer wrote: The whole idea that 'real DNS' can arbitrarily pre-empt local name resolution seems, well, wrong, and needs serious study for security implications for the services using those names, no? The whole idea that local names should look like DNS names and be queried through the same APIs and user interfaces seems, well, wrong (or dubious at best), and needs serious study for the implications of applications using those APIs and the impact of such names on DNS, no? IMO, local names and a lookup service for local names would be extremely useful, but neither the names nor the query interface should look much like DNS - the names should look different because otherwise there's too much potential for confusion with DNS names, and the query service should look different because local name lookup service probably can't make the same kinds of consistency or stability assurances that DNS does. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
On 1-sep-2005, at 13:34, Keith Moore wrote: No. Or at least, the point of having something like a link-local name resolution protocol is that you can use the same interfaces to look up the local names when using the link-local protocol, as you do when looking up real DNS names when using the real DNS protocol. That way all the existing applications work and don't need to be changed. False. That way, you break various kinds of applications because you violate assumptions that those applications quite reasonably made about the APIs and services they were using, and you flood the DNS with useless queries. This is the same kind of problem that resulted from introduction of NAT. I find this a very curious position. Basically you're saying that the namespace for local lookups and global lookups must be so separate, that they can't even use the same code paths. I really don't see that having a clear separation between the two that is PART of the combined namespace (i.e., one or more global TLDs, one (or more?) local TLDs) would be insufficient here. Otherwise you would be suggesting building an entirely new protocol and application stack, with changes to every application to support the link-local scheme, which is obviously out of the question. Actually, it's the only approach that makes any sense. The idea that you can substitute a name service that works differently from what applications expect, without breaking some of those applications, is extremely naive. Which reasonable expectation are you talking about? I'm opposed to the concept of confusing resolution of local names with resolution of DNS names. [...] I favor adoption of LLMNR because in a world of disconnected and intermittently connected networks there's a need for applications to still be able to work - and being able to work includes being able to lookup the same DNS names that the applications would normally use in a connected network. I don't understand how you can be in favor of LLMNR while at the same time being opposed to confusion between local and global (DNS) names. In theory, I suppose it's possible that the information available over LLMNR and the information available from the DNS are 100% consistent. In practice, this is of course completely impossible, and unless my memory is going faster than I thought, the draft doesn't even address this issue. So effectively, there will be a local namespace available over LLMNR and a global one available from the DNS, with an overlap somewhere betwee 0 and 1. An application then has no way to know which namespace provided a certain result. I favor discouraging use of mDNS Let's be clear that this is a completely separate issue from whether the LLMNR protocol is the right answer to the right question. because I believe it harms interoperability of Internet applications and operation of the DNS. How, exactly? I would like to see a solution for the lookup of local names that did not have these characteristics. If that solution can be derived from the mDNS protocol, that's fine with me, but it shouldn't overload the DNS lookup APIs nor should it borrow the DNS name syntax. That seems unnecessarily conservative. Even if you find the separate TLD solution unacceptable, local names can still be put in a DNS class of their own. Classes were invented for exactly this reason, if memory serves. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])
On Thu, 1 Sep 2005, Frank Ellermann wrote: Regarding RFC 822, the S-ID draft doesn't mention the fact that a large proportion of software which does something useful with Resent- headers still implements the 822 syntax, not the 2822 syntax. Except from all PRA-purposes and maybe MUAs displaying these Resent-* header fields somehow (822 or 2822): What other uses do you have in mind ? Ignoring PRA, there are two current sides to the handling of Resent-*: message submission and message display. An 822 display end can probably muddle along OK when presented by a 2822 message. An 822 message submission server will probably do something wrong when fixing up a 2822 message that has been re-sent more than once. A 2822 submission server will have to have some fairly good heuristics to gracefully handle 822 re-sent messages. Things get even more interesting if an 822-re-sent message is then 2822-re-sent, because the header order of the original re-sending has to be fixed. Sender-ID effecively requires that this kind of submission server fix-up must be implemented by MTAs and MDAs that do aliasing / redirecting / forwarding. While I'm at it: How's that supposed to work with RfC 2476bis 8.1 MAY add Sender ? Apparently 2476bis 8.1 is still based on the old 822-concept of Resent-* (?) It doesn't address Resent-* at all so one would have to work out for oneself how a submission server should treat them. This is clearly a bug. (Is it too late to fix submit-bis now it is in the RFC Editor queue?) Specifying what to do with them is, however, tricky. Sender-ID lacks this specification too. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ 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...)
On 1-sep-2005, at 15:14, Tony Finch wrote: 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. This kind of naming is not possible for ad-hoc networks without Internet connectivity and without any domain name registration. Apparently, LLMNR tries to remedy this situation by making it possible. However, the protocol doesn't address the issue of name ownership. We actually have protocols that assert name ownership more or less as a by product: x.509 and the like. An LLMNR that requires responders to have an x.509 certificate for the name they're claiming to hold would at least solve this issue. Obviously such a protocol would be utterly useless in any kind of unmanaged environment where local lookups are most needed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Request for NomCom05 Volunteers
This is the call for volunteers to participate in the 2005 IETF Nominations Committee (NomCom), the committee that will select this year's nominees for the IAB and the IESG. Details about the Nominations Committee and its operation can be found in RFC 3777. The NomCom is the IETF's way of choosing its leadership. Typically, half of the positions on the IAB, half of the positions on the IESG and one IAOC position are filled by the NomCom each year. It is possible that the NomCom will have to fill more or fewer slots due to the creation or elimination of positions, resignations, transfers, etc. IESG positions that will be reviewed by this NomCom are: Applications Area -- Scott Hollenbeck Internet Area -- Margaret Wasserman Operations and Management Area -- Bert Wijnen Routing Area -- Alex Zinin Security Area -- Sam Hartman Transport Area -- Allison Mankin Additionally, the IESG is considering the creation of a Real Time Infrastructure Applications area, whose exact charter and scope is being defined. If this area is created, then two additional AD positions must be filled, one for one year and one for two years. The IESG commits to deciding about this by the end of September. IAB members whose positions will be reviewed by this NomCom are: Leslie Daigle Patrik Faltstrom Bob Hinden Eric Rescorla Pete Resnick Jonathan Rosenberg The IAOC member whose term will expire is: Ed Juskevicius For the NomCom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Volunteering for the NomCom is also a good way of serving the IETF community, so please volunteer. NomCom members are barred from nomination during the year they serve, even if they later resign. Therefore, being selected for the NomCom provides complete immunity against selection for the IAB, IESG or IAOC during that year. People who volunteer should be sure they can the afford the time to meet the responsibilities of participating on the NomCom, which will amount to several hours per week over the next 4 to 5 months. The task involves the following activities: - Reading candidates' statements - Participating in a weekly 2 hour conference call. - Attending the IETF meetings held during the selection process. - Conducting interviews with candidates. - Speaking to IETF participants about the candidates, the job requirements, or the process. All NomCom deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The NomCom members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult during the selection process, and from those who provide requested supporting information. All members are expected to handle this information in a manner consistent with its sensitivity. To qualify as a volunteer, a person needs to have attended 3 out of the last 5 IETF meetings. Anyone who meets this requirement is invited to volunteer by emailing your name, telephone number(s), and email address to [EMAIL PROTECTED] no later than noon in Boston on September 30, 2005. Please put NOMCOM VOLUNTEER in the subject line. Once the list of volunteers closes it will be announced and published at: http://www.ietf.org/nomcom/index.html I will run the selection process against the list of volunteers and announce the results on October 7, 2005. Ten NomCom voting members will be chosen from the pool of volunteers according to the procedure described by Donald Eastlake in RFC 2777, Publicly Verifiable Nomcom Random Selection. The source of randomness will be based on the shares-traded number of 12 stocks selected by the NomCom chair. The official shares-traded numbers (denoted in 000s) will be drawn from the October 7, 2005 Wall Street Journal which reports the sales figures from the previous trading day - October 6, 2005. If trading in any of the stocks is suspended, then the shares traded will be assumed to be 0. The NomCom voting members will start their term on October 14, 2005, after the IETF community has had a chance to review the random selection process. Please volunteer. Thank you, Ralph Droms [EMAIL PROTECTED] STOCKS USED IN THE NOMCOM SELECTION PROCESS: Exxon Mobil (XON) Time Warner (TWX) Wal-Mart (WMT) Hewlett Packard (HPQ) General Motors (GM) Nortel (NT) Honeywell (HON) Verizon (VZ) Dow Chemical (DOW) Citigroup (C) Johnson Johnson (JNJ) Gilette (G) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
On Thu, 1 Sep 2005, Iljitsch van Beijnum wrote: I don't understand how you can be in favor of LLMNR while at the same time being opposed to confusion between local and global (DNS) names. In theory, I suppose it's possible that the information available over LLMNR and the information available from the DNS are 100% consistent. Is LLMNR supposed to work with RFC 3927 IPv4 link-local address autoconfiguration? In which case it's also theoretically impossible for LLMNR to be consistent with the DNS. (Consistency would require dynamic DNS updates, and if they work your DHCP server should also be working, in which case you won't have an RFC 3927 address.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
# That said, if people want to limit the effect of these 'bogus' queries # onto the root servers I suggest that ISP's join into the AS112 project. # Also it would maybe be an idea for AS112 to add .local there? yes, but only when some rfc reserves .local the way rfc1918 reserves the 10.in-addr.arpa and other names handled by AS112. (IANA will, properly, refuse to add a .LOCAL NS RR pointing at AS112 or anywhere else until IETF reserves this name.) # PS: Who ever named the LLMNR draft 'mdns' isn't that completely # confusing for people looking up the mDNS draft, that is the protocol # that Stuart made? :) yes. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
On Thu, Sep 01, 2005 at 02:58:17PM +, Paul Vixie [EMAIL PROTECTED] wrote a message of 19 lines which said: yes, but only when some rfc reserves .local the way rfc1918 reserves the 10.in-addr.arpa and other names handled by AS112. (IANA will, properly, refuse to add a .LOCAL NS RR pointing at AS112 or anywhere else until IETF reserves this name.) In that direction (IANA waiting for IETF), I understand. But what about the other direction? When IETF reserves a name, is it always null-routed to AS112? It does not seem so, .example (RFC 2606), for instance, is not delegated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
# But what about the other direction? When IETF reserves a name, is it # always null-routed to AS112? It does not seem so, .example (RFC # 2606), for instance, is not delegated. if as112 is asked, my bet is, as112 will cooperate. for .example, as112 wasn't asked. (yet?) ___ 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...)
--On 1. september 2005 14:14 +0100 Tony Finch [EMAIL PROTECTED] wrote: 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. This kind of naming is not possible for ad-hoc networks without Internet connectivity and without any domain name registration. it's certainly *possible* (if each participant has some relationship to a domain name owner). The question is whether it's *desirable*. I see naming as 3 parts: - I pick a name - I assert that the name belongs to me - You choose to believe it (or not). With DNS names, I pick a name involves seeing which names are free in a DNS zone I have a relationship to (which may be dyndns.org, for instance), and doing the admin steps to reserve it. I assert involves me putting it into a DNS zone, and loading that zone onto a DNS server, where you'll presumably pick it up. You choose in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be because he's here and he says so. This could be backed up with certificates if you wanted to, of course. 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. This is descending into a philosophical debate... what's in a name... pgp9p5suz7Mfx.pgp Description: PGP signature ___ 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...)
On Thu, 2005-09-01 at 20:08 +0200, Harald Tveit Alvestrand wrote: 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. Can I read this as LLMNR SHOULD be used with domains in the .local domain ? Which puts it really in the same baliwick as mDNS (that is the version that existed before that draft was written with the name mdns ;) One can of course easily remove the check for the .local from the real mDNS and use it for anything else too. Just change the MUST into a SHOULD in the draft and everybody is happy. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ 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...)
On 1-sep-2005, at 20:08, Harald Tveit Alvestrand wrote: I see naming as 3 parts: - I pick a name - I assert that the name belongs to me - You choose to believe it (or not). With DNS names, I pick a name involves seeing which names are free in a DNS zone I have a relationship to (which may be dyndns.org, for instance), and doing the admin steps to reserve it. I assert involves me putting it into a DNS zone, and loading that zone onto a DNS server, where you'll presumably pick it up. You choose in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be because he's here and he says so. What I'm missing in this story is how the application finds out who said so. So either you need to allow Harald said so for all applications or for none of them. That is not good. This could be backed up with certificates if you wanted to, of course. Actually, it couldn't, as there is no provision for this in LLMNR. 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. This is descending into a philosophical debate... what's in a name... Here's a philosophical question for you: is it right to force a philosophy on people? The trouble with LLMNR is that it has lots of repercussions for applications that don't want it, links that don't want it (that one is true for mDNS as well) and even server operators that don't want it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Single DNS root
--On Thursday, 01 September, 2005 02:49 +0200 JFC (Jefsey) Morfin [EMAIL PROTECTED] wrote: Dear Harald and Paul, May be time to stop 3683ing this issue. Major moves in the naming area are probable in the year to come (PADs - shared root under UN - National TLDs, CENTR move.); while an ICANN request of update of RFC 2826 stays unanswered or opposed for four years. Jefsey, Just to understand the relationship between your reality and mine, what ICANN request for an update of RFC 2826 are you talking about? Certainly there was some discussion within ICANN circles about whether 2826 meant what it said. But, of course, anyone can say just about anything in an ICANN meeting or on an ICANN mailing list as long as it is consistent with the organization's norms for appropriate behavior (just as with Internet Drafts and IETF mailing lists). Such a comment is not equivalent to an ICANN request. I am aware of one informal inquiry from an ICANN staff member as to whether the IAB was likely to have more to say on the subject. The informal response (from one of the editors of 2826 but with general sympathy from the IAB) was, if I recall, approximately which part of 'unique' are you having trouble understanding?. At least in my memory and reality, there has been no ICANN request for an update, much less one that has been unanswered or opposed. Could you explain what you are talking about and identify the request to which you are referring? Or stop this, lest the claim about such a request become part of Harald's 3683 case? john ___ 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...)
On Thursday, September 01, 2005 15:31:05 -0400 Daniel Senie [EMAIL PROTECTED] wrote: These are the same issues I recall asking about when dynamic DNS was being discussed/proposed. Any machine can make a claim they're whomever they want to be, and that request to insert mapping gets fired off to some distant DNS server who has no idea who the client is. I recall being told that any authorization to use a particular name was out of scope of the protocol. Thanking the person who told me this, I've made it a point to disable dynamic DNS in all envinronments since it's been available in running code. It's useless. Actually, it's not completely useless. DDNS can be highly useful in specific deployments, where requests are authenticated and where there is a suitable authorization policy in place. And yes, policy (authorization or otherwise) generally is out of scope for a well-designed protocol, and for good general-purpose implementations as well. For example, here at CMU most of our authoritative nameservers are updated via DDNS; this allows us to map dynamically-assigned addresses to real hostnames, and to mix names of machines with dynamically- and statically-assigned addresses in the same domain. The trick is that DDNS updates are all authenticated, and the only clients permitted to make such updates are the DHCP servers (which add and remove both forward and reverse records for dynamically-assigned hosts) and the tools which propagate changes from the network registration database (which maintain all the other records). Of course, more precise policies are possible. For example, a site like dyndns.org could allow a particular authenticated DDNS client to point its own name to any address it likes, but not to change any other name. I suppose LLMNR might have its uses, too. But I can't figure out what they are, and whether they are worth the significant amount of confusion and breakage which seem likely to result from widespread deployment of this protocol on the Internet. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ 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...)
--On torsdag, september 01, 2005 20:30:56 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: You choose in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be because he's here and he says so. What I'm missing in this story is how the application finds out who said so. So either you need to allow Harald said so for all applications or for none of them. That is not good. Yep. In the DNS case, the DNS server I asked said so. In the LLMNR and mDNS case, the machine that answered my multicast said so. Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in additional data?) would seem to be one possibility to prove that the data being presented was legitimate under DNS delegation rules, even when you don't have a present connection to the Internet. My imagination doesn't fly far enough at this time of night to figure out any relationship beteen a .local name and the term legitimacy. But it's late in the evening, so my imagination is not flying very far - perhaps mDNS works because they deliberately abandoned the idea of name ownership. YMMV. Harald ___ 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...)
On 2-sep-2005, at 0:17, Harald Tveit Alvestrand wrote: Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in additional data?) would seem to be one possibility to prove that the data being presented was legitimate under DNS delegation rules, even when you don't have a present connection to the Internet. Right. I'm looking forward to seeing a protocol that incorporates this notion. My imagination doesn't fly far enough at this time of night to figure out any relationship beteen a .local name and the term legitimacy. But it's late in the evening, so my imagination is not flying very far - perhaps mDNS works because they deliberately abandoned the idea of name ownership. Don't forget that the purpose of multicast DNS / Zeroconf / Rendezvous / Bonjour is service discovery. When you've discovered a service it's helpful to be able to refer to it by name, but the whole name lookup thing seems almost incidental. YMMV. Well, isn't the purpose of a standards organization to make sure that even though your milage may vary, at least you know whether those miles are 1609 or 1852 meters in length? ___ 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...)
On Sep 1, 2005, at 15:17, Harald Tveit Alvestrand wrote: --On torsdag, september 01, 2005 20:30:56 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: You choose in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be because he's here and he says so. What I'm missing in this story is how the application finds out who said so. So either you need to allow Harald said so for all applications or for none of them. That is not good. Yep. In the DNS case, the DNS server I asked said so. In the LLMNR and mDNS case, the machine that answered my multicast said so. Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in additional data?) would seem to be one possibility to prove that the data being presented was legitimate under DNS delegation rules, even when you don't have a present connection to the Internet. My imagination doesn't fly far enough at this time of night to figure out any relationship beteen a .local name and the term legitimacy. But it's late in the evening, so my imagination is not flying very far - perhaps mDNS works because they deliberately abandoned the idea of name ownership. the TBDS work presumed a shared, common name space (the DNS as we know it today) - where each node is imprinted with its FQDN and is tagged w/ an x509 cert. The DNS delegations are signed. a change w/ TBDS is that each node runs a DNS server, not just a stub resolver. so it can ask questions and cache answers and when it (the node) runs into an authoritative server for something higher in the heirarchy, it can flush the more specific data in favor of the authoritative stuff. This does not prevent random nodes from trying to spoof being who they are not, but w/ the extra data (signed delegations x509 certs) the receiving node does have somewhat more data on which to evaluate the viability of any given reply ... With TBDS, it is also possible to assert extensions to the namespace, but they would only be honoured by parties that share the same security/trust hooks e.g. if we both know the secret password then our use of the .piglet TLD works for us. Others ignore these queries. mDNS seems to have taken this idea but restricted it to a single extention, e.g. .local (and yes, there are many fine minefields here, but the project ran out of funding) YMMV. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Single DNS root
At 21:10 01/09/2005, John C Klensin wrote: --On Thursday, 01 September, 2005 02:49 +0200 JFC (Jefsey) Morfin [EMAIL PROTECTED] wrote: Dear Harald and Paul, May be time to stop 3683ing this issue. Major moves in the naming area are probable in the year to come (PADs - shared root under UN - National TLDs, CENTR move.); while an ICANN request of update of RFC 2826 stays unanswered or opposed for four years. Jefsey, Just to understand the relationship between your reality and mine, Dear John, No problem. What is a reality (back-ground, referent and context) is precisely the ultimate question of this RD. But you jump into something complex enough, at the core of an evolution the IETF does not consider much. what ICANN request for an update of RFC 2826 are you talking about? I quoted it in the mail. This is the ICP-3 document. This document is often confused as an anti-New.net pamphlet. This is key document which discusses: - the legitimacy of ICANN, rooting in the consensus we had in 1984, JonPostel documented in RFC 920 - the need of a unique authoritative root as documented in RFC 2826, plus harping on alt-roots, etc. - the development of the Internet technology based upon experimentation and the need of a community experimentation for the evolution of the DNS. The IETF is quoted there as both a possible experimentation leader and further standardiser. I have asked several times that IETF addresses that request. I was usually responded that IETF is ill suited to lead an experimentation. I therefore ran such a test-bed for two years, involving up to 30 machines (2002/2003) from all over the planet (dot-root project). The results of this experimentation lead to several conclusions/proposition validations. They are the base of my positions and several initiatives. Certainly there was some discussion within ICANN circles about whether 2826 meant what it said. But, of course, anyone can say just about anything in an ICANN meeting or on an ICANN mailing list as long as it is consistent with the organization's norms for appropriate behavior (just as with Internet Drafts and IETF mailing lists). Such a comment is not equivalent to an ICANN request. I am aware of one informal inquiry from an ICANN staff member as to whether the IAB was likely to have more to say on the subject. The informal response (from one of the editors of 2826 but with general sympathy from the IAB) was, if I recall, approximately which part of 'unique' are you having trouble understanding?. This was during the writing of ICP-3 and the fuss over alt(sic)roots. RFC 2860 deals with the past. Not with the evolution of the Internet. ICP-3 investigates the possibility of the end of the concept of unique authoritative root file. It takes advantage from your draft on classes: this a way to show where and how far to investigate and respond the question what does experimentation teach about the internet evolution?. This was also the time IDN started being considered. IMO a lot of things would have been different had we considered that well written document. ICP-3 also gives the criteria for such an experimentation we strictly followed (except in extending to what we named ULDs [upper/user level domains] to be able also to test real users behaviours in a consistent way with these criteria). In that area we experimented that: - the management of the current root file can be far more efficient, secure, TLD Manager directed and universally controlled than by ICANN or investigated by the CENTR. - the single authoritative root should be a notion to stay, but the file concept should develop into a structured matrix. We also identified that these notions could find an adequate solution in the evolution of the IANA concept itself to adapt to ISO 11179 conformant ideas to CRCs (Common Reference Center) organising a DRS (Distributed Registry System). The report I published - paid by Govs and international instances - was ... thick but it only partly covered our small budge. The AFRAC organisation we created to continue experimentation and development on the DRS part for France. It gives additional experience. ICP-3 document refers to classes (in using a Draft of yours). This is a more complex issue, we identified as a general problem (I documented in a mail a few weeks ago) of the Internet architecture. Several architectural parameters default to one. The problems of partitioning we face and started a balkanisation of the network, can be structurally solved without conflict and more easily in turning that parameters to multiple set. There is one class, one (may be a little more) group, one IPv6 plan, one namespace, one IANA, one language, one ICANN, one IP, etc. At least in my memory and reality, there has been no ICANN request for an update, much less one that has been unanswered or opposed. I argued that IETF should comment. This did not attract people. Yourself now ask,
RFC 4161 on Guidelines for Optional Services for Internet Fax Gateways
A new Request for Comments is now available in online RFC libraries. RFC 4161 Title: Guidelines for Optional Services for Internet Fax Gateways Author(s): K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide Status: Informational Date: August 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 23189 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-fax-gateway-options-08.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4161.txt To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an Internet Fax Gateway is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an offramp gateway provides facsimile data transmission from i-fax to GSTN fax; vice versa, an onramp gateway provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN. This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This document is a product of the Internet Fax Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4161.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4162 on Addition of SEED Cipher Suites to Transport Layer Security (TLS)
A new Request for Comments is now available in online RFC libraries. RFC 4162 Title: Addition of SEED Cipher Suites to Transport Layer Security (TLS) Author(s): H.J. Lee, J.H. Yoon, J.I. Lee Status: Standards Track Date: August 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 6 Characters: 10578 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-lee-tls-seed-01.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4162.txt This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4162.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
