it's not that much of an apple vs. microsoft thing. microsoft and apple both have employees working with the IETF zeroconf working group - and at least some of the specs have both an apple employee and a microsoft employee as authors.
(I say employee because IETF doesn't recognize vendor representatives - all participants are supposed to use their best technical engineering judgement regardless of their employer's interest.)
the difference between ms and apple here is that apple is shipping rendezvous code before the specs are finalized, even though there are several known problems with those specs (especially the name lookup protocol).
options are often good, but the current linklocal spec is optional only for the implementor of the IP stack. users have no choice about whether it's enabled (at least, not as a matter of standards compliance), hosts are exposed to additional security risks, programs are forced to deal with linklocal addresses even though they mess things up, and networks can't disable it even when it causes problems.
hopefully these things will be fixed before the specs are approved as standard, but so far the working group has steadfastly resisted any fixes that would actually make linklocal optional.
yea, imagine a dozen machines at a LAN party (or in an airport terminal or in any other random place) automatically connecting to each other and spreading viruses around. the current linklocal address spec (currently awaiting review for final approval) insists on having linklocal addresses enabled all the time, and by default - and for some reason the working group insists on it being that way!
for that matter imagine zeroconf breaking apps that expect addresses to be routable and stable.
oh, but I forgot - having kewl broken technology out the door is more important than actually doing the engineering that is required to make it work well.
I don't think that spam is a right any more than driving around in a loudspeaker-laden truck that is playing incessant advertisements in the middle of the night is a right. and I don't think that spammers have any more right to privacy than others who disturb the peace or engage in petty theft. the public has a greater interest in having the names of accused be in the public record than in keeping their names secret. (this actually helps discourage false accusations by the government)
having said that, it's also clear that having a way to identify the source of a potential spam would create serious privacy concerns - what's to stop that method from being used to identify the source of any email? nor does "identifying the spammer" seem to be as useful as "marginalizing the spammer" - i.e. making sure that spammers are likely to have to pay so dearly that it's not profitable for them. strictly speaking, we may not need to identify them to achieve this result.
so what we really need is a way to marginalize real spammers without sacrificing others' privacy rights in the process.
Anytime you read that IETF is about ready to approve something as a standard, take it with a grain of salt unless it comes from the IETF chair or the area director responsible for that group. Such statements are usually propaganda from people who are trying to encourage premature adoption, or at best they are wishful thinking. It's not unusual for working groups to produce drafts which they think are ready for approval, but which actually contain serious technical problems that need to be resolved. Fixing those problems can require months or even years.
In particular, the fact that The Storage Networking Industry Association has completed its comments on the draft doesn't have any bearing whatsoever on IETF standardization.
Someone mentioned the security issue. I haven't followed the iSCSI discussions but security is definitely an issue that was identified before the group was formed, and one which is particularly difficult to solve for iSCSI because of performance concerns. I'll be interested to see how they've addressed it. I'd consider it extremely unlikely for IETF approve the standard without due consideration of security. And saying "it's going to be behind a firewall, so it doesn't have to be secure" has traditionally not been considered sufficient.
keith, can rendezvous-based packets be routed across a wan using multicast routing (like dvmrp or pim) to enable applications to function?
no, mDNS/LLMNR is supposed to use link-local multicast scope for queries, and linklocal IPv4 is not supposed to be routed. however another problem with rendezvous/zeroconf is that (at least in the current specs) it's not clear that mDNS/LLMNR and linklocal IPv4 have the same scope - so you could end up finding IP addresses via mDNS that aren't usable to you, or conversely you could end up having local hosts that are accessible but which you can't find using mDNS even though they support it.
zeroconf breaks applications in several ways, for instance:
v4 linklocal addresses are unstable and subject
to change at any time without notice to the parties
using them
they don't work well on machines with multiple network interfaces.
existing apps don't know to avoid using linklocal addresses when they're not appropriate, and in general neither apps nor hosts have any good way to tell whether a linklocal address associated with a host is accessible without trying it and waiting for the connection to time out, or connecting and then verifying if it's really the right host (since the host you really want to talk to might be on a different network).
nobody has figured out how to ensure consistency between multicast DNS and real DNS, so different machines talking to each other can have different ideas of what a DNS name means or even whether a name is valid at all. so applications that pass DNS names around (like the web or email or anything that uses URLs) and rely on consistency of DNS may break in strange new ways if some of the hosts are using multicast DNS and others aren't, or if the hosts using multicast DNS are on different network links.
DNS-based service discovery is even less well understood.
zeroconf will be really nice when we figure out how to make it work well without breaking apps. It's unfortunate that Apple is trying to deploy a technology widely that has several serious known flaws and claim that it is a standard before those flaws are fixed.
people seem to forget that the US is becoming a fairly small portion of Internet users. but some folks in Congress think that we own the Internet.
if ICANN is corrupt we can at least take some comfort in realizing that it has very little power. I wish we could say the same about the US government, which is corrupt but has tremendous power to do harm.
HP-UX is the second worst UNIX I've ever been forced to use (SCO being the worst). I used to go into screaming fits every time I had to log into a HP-UX box because the damn thing didn't even support tty modes correctly.
At least OSF/1-Tru64 (at one time) had good release engineering. But it started going downhill fast once DEC started massive layoffs.
Not being able to copy a CD onto my computer doesn't violate my right to free speech in any way whatsoever.
perhaps not. but if the mechanism that prevented you from copying a CD had any legitimate uses under the First Amendment, then that mechanism would be suspect. for instance, if you wished to comment on a popular song and you wanted to rip a short excerpt of that song from a CD to use as an example, this would be a legitimate exercise, and a copy-prevention mechanism shouldn't prevent you from doing that.
1. part of the purpose of Fair Use is to preserve the public's First Amendment right to discuss copyrighted works. The fact that some of these rights are explicitly recognized in copyright law doesn't mean that Fair Use is inherently limited to what is in the current law.
2. where there is a conflict between the Constitution's provision for copyrights and the First Amendment, the First Amendment should be presumed to override the original language, because the very purpose of an amendment is to modify the Constitution.
none of this means that people can copy whatever they wish and claim Fair Use. on the other hand, laws that impose criminal penalties on reasonable exercises of the First Amendment should be shot down at the earliest opportunity.
there are several problems with ISPs requiring specific software to be installed: first, this essentially requires you to be running one of their "approved" operating systems; second, this exposes their customers to potential security threats that they cannot analyze (whether or not the ISP is malicious)
however, it might be reasonable to define a standard suite of basic diagnostic tools and expect customers to have those tools on hand. one such tool could gather basic information from the customer's computer and put it on a screen so that the customer could read it over the phone to an ISP. (or print it out and fax it) e.g.
link auth type (ppp over modem, PPPoE, etc)
ppp phone number (if applicable)
link-level login name
results of last authentication attempt
ip address of local end of ppp link
ip address of remote end of ppp link (if applicable)
default router address
results of ping to default router
dns server addresses
dns default domains
web proxy addresses
email submission server addresses
pop/imap username
pop/imap server addresses
email return address
etc.
the same tool could attempt to do some basic DNS queries, and make rudimentary connections to POP, IMAP, SMTP, etc. servers and web proxies (if applicable) - so that when the results are reported to the ISP the ISP can easily determine which things work and which don't, and to isolate the problem to some degree.
then the customer wouldn't be required to run a specific vendor's software, and the ISP would be able to get basic information quickly without having to lead the customer through a dialogue with the application. of course, this assumes that such basic diagnostics could be deployed.
Re:it's amazing how they worry about one root serv
on
The Root of All E-Mail
·
· Score: 1
it's also amazing how articles critizing ICANN are enthusiastically accepted, whereas articles critizing VeriSign are labelled as trolls.
I've gotta hand it to the VeriSign folks - they're masters at pulling wool over people's eyes.
it's amazing how they worry about one root server
on
The Root of All E-Mail
·
· Score: 0, Troll
and completely fail to worry about the company that runs it. an attack on the net by VeriSign is much more likely to succeed than an attack on the root servers by terrorists.
oh wait. the attack already happened, and that's why VeriSign retains effective control over the root and manages to impose a tax on every.COM,.ORG, or.NET domain name.
if you shut down ICANN, you need to create something in its place that represents all of the stakeholders. there are politically powerful folks who stand to make a lot of money from ICANN failing, and leaving unregulated monopolies to control TLDs. they will use all of their influence to oppose a replacement for ICANN being formed unless it favors them. it was difficult enough to form ICANN last time around; a replacement would be even more controversial.
the folks who believe we can have stable DNS with an arbitrary number of self-appointed roots and TLDs are deluded. if that happens the most likely result is that different countries will have their own root servers that are mandated by their governments (in order to ensure name stability within each country), but there will be conflicts between countries about the meanings of some names.
the browser isn't the only internet application that uses DNS names, not by a long shot.
not all net apps are interactive. should
a MTA have to ask someone to disambiguate a DNS root conflict everytime it wants to route an email?
if you don't have stable IP addresses (and you don't), and you don't have a single DNS root, how do you specify which root servers to use? what's to keep root X from providing bogus results in response to queries for the addresses of other roots?
Cultures vary widely about what they consider obscene, indecent, prurient, or suitable only for adults. There are enough disputes over domain names already - the last thing we need
is to deal with arguments over an.XXX TLD that tries to apply to everywhere on earth.
OTOH, Any country can create.XXX.CC (where CC is the country code) if it wants to do so.
This doesn't cause too many problems on a small scale. But if everybody picked his own root, it would be a disaster.
If you want domain names (and URLs) to work reliably and consistently from one location to another, there needs to be some mechanism to sort out conflicts over the meaning of a name. That job is inherently fraught with controversy, because it will pit people with
vastly different interests, cultures, and expectations against one another. I don't particularly like the result of UDRP, but the bottom line is that dispute resolution is a difficult job no matter how it's done.
On the other hand if everybody picks his own root (or his own root search path) then
URLs won't have the same meaning from one client to another, and instead of having ICANN handle disputes about who owns a TLD or SLD, we'll have the same disputes being handled by people trying to tell random users to change their root servers. or by interception proxies forced on users by ISPs. In some parts of the world there will be government edicts insisting that a particular root be used, with different roots required in different parts of the world.
Granted that ICANN is seriously screwed up and that its current proposal is not a step in the right direction. But having one authority responsible for dispute resolution at the TLD level makes a lot more sense than inviting wide variation in the meanings of DNS names.
it's pure text-based, but it supports tables
and a mouse (in xterm, anyway). and it's *fast*.
no java, javascript, cookies, or any of that crap. so it's not good for everything, but
when you just want fast access to stuff that
is mostly text, or if you're trying to read a site that is too busy (maybe because it's slashdotted), it's a winner.
Most OS vendors (both free and $$$) are shipping IPv6 today in their latest versions - the biggest holdout being Apple (and I have heard that MacOS 10.2 will support it)
A technology called 6to4 lets any host with a
single IPv4 address act as a router for up to 2**80 IPv6 hosts and use the existing IPv4 network to route the packets. When routing to other hosts using 6to4, the packets go directly to their destinations; when routing to other IPv6 hosts, the packets go to the nearest router that can relay between the two. (using an IPv4 anycast address). See RFCs 3056 and 3068 for details on how it works. 6to4 isn't as widely supported as native v6 (yet) but it already seems to work with NetBSD, FreeBSD, Linux, and Win/XP, and M$ provides code you can download to use 6to4on some other M$ systems.
No additional support is needed from the network, though there is less overhead if the network is upgraded to support v6 natively.
I use IPv6 every day to communicate between my home and work machines, over an IPv4 network.
Slashdot Mirror
it's not that much of an apple vs. microsoft thing. microsoft and apple both have employees working with the IETF zeroconf working group - and at least some of the specs have both an apple employee and a microsoft employee as authors.
(I say employee because IETF doesn't recognize vendor representatives - all participants are supposed to use their best technical engineering judgement regardless of their employer's interest.)
the difference between ms and apple here is that apple is shipping rendezvous code before the specs are finalized, even though there are several known problems with those specs (especially the name lookup protocol).
options are often good, but the current linklocal spec is optional only for the implementor of the IP stack. users have no choice about whether it's enabled (at least, not as a matter of standards compliance), hosts are exposed to additional security risks, programs are forced to deal with linklocal addresses even though they mess things up, and networks can't disable it even when it causes problems.
hopefully these things will be fixed before the specs are approved as standard, but so far the working group has steadfastly resisted any fixes that would actually make linklocal optional.
yea, imagine a dozen machines at a LAN party (or in an airport terminal or in any other random place) automatically connecting to each other and spreading viruses around. the current linklocal address spec (currently awaiting review for final approval) insists on having linklocal addresses enabled all the time, and by default - and for some reason the working group insists on it being that way!
for that matter imagine zeroconf breaking apps that expect addresses to be routable and stable.
oh, but I forgot - having kewl broken technology out the door is more important than actually doing the engineering that is required to make it work well.
having said that, it's also clear that having a way to identify the source of a potential spam would create serious privacy concerns - what's to stop that method from being used to identify the source of any email? nor does "identifying the spammer" seem to be as useful as "marginalizing the spammer" - i.e. making sure that spammers are likely to have to pay so dearly that it's not profitable for them. strictly speaking, we may not need to identify them to achieve this result.
so what we really need is a way to marginalize real spammers without sacrificing others' privacy rights in the process.
Anytime you read that IETF is about ready to approve something as a standard, take it with a grain of salt unless it comes from the IETF chair or the area director responsible for that group. Such statements are usually propaganda from people who are trying to encourage premature adoption, or at best they are wishful thinking. It's not unusual for working groups to produce drafts which they think are ready for approval, but which actually contain serious technical problems that need to be resolved. Fixing those problems can require months or even years.
In particular, the fact that The Storage Networking Industry Association has completed its comments on the draft doesn't have any bearing whatsoever on IETF standardization.
Someone mentioned the security issue. I haven't followed the iSCSI discussions but security is definitely an issue that was identified before the group was formed, and one which is particularly difficult to solve for iSCSI because of performance concerns. I'll be interested to see how they've addressed it. I'd consider it extremely unlikely for IETF approve the standard without due consideration of security. And saying "it's going to be behind a firewall, so it doesn't have to be secure" has traditionally not been considered sufficient.
(FWIW, I'm a former IETF area director)
actually there are several drafts you should look at:
t -ietf-zeroconf-reqts-11.txtn s-12.txt
draft-ietf-zeroconf-ipv4-linklocal-07.txt
draf
draft-ietf-dnsext-md
and I think there's another one somewhere about
DNS service discovery, but I don't recall it offhand.
keith, can rendezvous-based packets be routed across a wan using multicast routing (like dvmrp or pim) to enable applications to function?
no, mDNS/LLMNR is supposed to use link-local multicast scope for queries, and linklocal IPv4 is not supposed to be routed. however another problem with rendezvous/zeroconf is that (at least in the current specs) it's not clear that mDNS/LLMNR and linklocal IPv4 have the same scope - so you could end up finding IP addresses via mDNS that aren't usable to you, or conversely
you could end up having local hosts that are accessible but which you can't find using mDNS even though they support it.
i.e. this is nowhere nearly ready for prime time
no, the .local TLD isn't in the current proposal,
it's been removed.
see draft-ietf-dnsext-mdns-12.txt
zeroconf breaks applications in several ways, for instance:
zeroconf will be really nice when we figure out how to make it work well without breaking apps. It's unfortunate that Apple is trying to deploy a technology widely that has several serious known flaws and claim that it is a standard before those flaws are fixed.
to install spyware in those older operating systems, like they've done with XP and win2k.
45% of the machines sold do not come with windows
unless the buyer actually wants to pay for it.
people seem to forget that the US is becoming a fairly small portion of Internet users. but some folks in Congress think that we own the Internet.
if ICANN is corrupt we can at least take some comfort in realizing that it has very little power. I wish we could say the same about the US government, which is corrupt but has tremendous power to do harm.
HP-UX is the second worst UNIX I've ever been
forced to use (SCO being the worst). I used to
go into screaming fits every time I had to log
into a HP-UX box because the damn thing didn't
even support tty modes correctly.
At least OSF/1-Tru64 (at one time) had good
release engineering. But it started going downhill fast once DEC started massive layoffs.
RIP DEC. We didn't know how good we had it...
perhaps not. but if the mechanism that prevented you from copying a CD had any legitimate uses under the First Amendment, then that mechanism would be suspect. for instance, if you wished to comment on a popular song and you wanted to rip a short excerpt of that song from a CD to use as an example, this would be a legitimate exercise, and a copy-prevention mechanism shouldn't prevent you from doing that.
1. part of the purpose of Fair Use is to preserve the public's First Amendment right to discuss copyrighted works. The fact that some of these rights are explicitly recognized in copyright law doesn't mean that Fair Use is inherently limited to what is in the current law.
2. where there is a conflict between the Constitution's provision for copyrights and the First Amendment, the First Amendment should be presumed to override the original language, because the very purpose of an amendment is to modify the Constitution.
none of this means that people can copy whatever they wish and claim Fair Use. on the other hand, laws that impose criminal penalties on reasonable exercises of the First Amendment should be shot down at the earliest opportunity.
however, it might be reasonable to define a standard suite of basic diagnostic tools and expect customers to have those tools on hand. one such tool could gather basic information from the customer's computer and put it on a screen so that the customer could read it over the phone to an ISP. (or print it out and fax it) e.g.
- link auth type (ppp over modem, PPPoE, etc)
- ppp phone number (if applicable)
- link-level login name
- results of last authentication attempt
- ip address of local end of ppp link
- ip address of remote end of ppp link (if applicable)
- default router address
- results of ping to default router
- dns server addresses
- dns default domains
- web proxy addresses
- email submission server addresses
- pop/imap username
- pop/imap server addresses
- email return address
- etc.
the same tool could attempt to do some basic DNS queries, and make rudimentary connections to POP, IMAP, SMTP, etc. servers and web proxies (if applicable) - so that when the results are reported to the ISP the ISP can easily determine which things work and which don't, and to isolate the problem to some degree.then the customer wouldn't be required to run a specific vendor's software, and the ISP would be able to get basic information quickly without having to lead the customer through a dialogue with the application. of course, this assumes that such basic diagnostics could be deployed.
it's also amazing how articles critizing
ICANN are enthusiastically accepted, whereas
articles critizing VeriSign are labelled
as trolls.
I've gotta hand it to the VeriSign folks -
they're masters at pulling wool over
people's eyes.
and completely fail to worry about the company that runs it. an attack on the net by VeriSign is much more likely to succeed than an attack on the root servers by terrorists.
.COM, .ORG, or .NET domain name.
oh wait. the attack already happened, and that's why VeriSign retains effective control over the root and manages to impose a tax on every
if you shut down ICANN, you need to create something in its place that represents all of the stakeholders. there are politically powerful folks who stand to make a lot of money from ICANN failing, and leaving unregulated monopolies to control TLDs. they will use all of their influence to oppose a replacement for ICANN being formed unless it favors them. it was difficult enough to form ICANN last time around; a replacement would be even more controversial.
the folks who believe we can have stable DNS with an arbitrary number of self-appointed roots and TLDs are deluded. if that happens the most likely result is that different countries will have their own root servers that are mandated by their governments (in order to ensure name stability within each country), but there will be conflicts between countries about the meanings of some names.
OTOH, Any country can create .XXX.CC (where CC is the country code) if it wants to do so.
If you want domain names (and URLs) to work reliably and consistently from one location to another, there needs to be some mechanism to sort out conflicts over the meaning of a name. That job is inherently fraught with controversy, because it will pit people with vastly different interests, cultures, and expectations against one another. I don't particularly like the result of UDRP, but the bottom line is that dispute resolution is a difficult job no matter how it's done.
On the other hand if everybody picks his own root (or his own root search path) then URLs won't have the same meaning from one client to another, and instead of having ICANN handle disputes about who owns a TLD or SLD, we'll have the same disputes being handled by people trying to tell random users to change their root servers. or by interception proxies forced on users by ISPs. In some parts of the world there will be government edicts insisting that a particular root be used, with different roots required in different parts of the world.
Granted that ICANN is seriously screwed up and that its current proposal is not a step in the right direction. But having one authority responsible for dispute resolution at the TLD level makes a lot more sense than inviting wide variation in the meanings of DNS names.
RFC 2826 still says it pretty well.
no java, javascript, cookies, or any of that crap. so it's not good for everything, but when you just want fast access to stuff that is mostly text, or if you're trying to read a site that is too busy (maybe because it's slashdotted), it's a winner.
http://artax.karlin.mff.cuni.cz/~mikulas/links/
Most OS vendors (both free and $$$) are shipping IPv6 today in their latest versions - the biggest holdout being Apple (and I have heard that MacOS 10.2 will support it)
A technology called 6to4 lets any host with a single IPv4 address act as a router for up to 2**80 IPv6 hosts and use the existing IPv4 network to route the packets. When routing to other hosts using 6to4, the packets go directly to their destinations; when routing to other IPv6 hosts, the packets go to the nearest router that can relay between the two. (using an IPv4 anycast address). See RFCs 3056 and 3068 for details on how it works. 6to4 isn't as widely supported as native v6 (yet) but it already seems to work with NetBSD, FreeBSD, Linux, and Win/XP, and M$ provides code you can download to use 6to4on some other M$ systems.
No additional support is needed from the network, though there is less overhead if the network is upgraded to support v6 natively.
I use IPv6 every day to communicate between my home and work machines, over an IPv4 network.
Certainly not in the US, where the best we can generally hope for is to be able to cast a vote for the lesser of two evils.