Slashdot Mirror

"Online companies will certainly also make use in future of a controversial feature called IPv6, designed by the Internet Engineering Task Force (IETF). At present, the anonymity of most Internet users is more or less protected because service providers generally assign a different IP address each time someone logs on. But IPv6 includes a new, expanded IP address, part of which is the unique serial number of each computer's connection hardware. Every data packet sent will carry a user's electronic fingerprints.

All of the people involved in developing these standards are "techno-geeks" who really know and care about security. The cryptography and protocols used in X.509 PKI are as strong as anything else out there. If you're really untrusting and paranoid, then you don't have to trust any other CAs, you can run your own.

The chief spokes-monkey declared the official communications protocol of Ximian to be the Infinite Monkey Protocol Suite. He then screeched, beat his chest and threatened to pelt feces at users of inferior protocols like SMTP.

Emerald fits into a subset of the network monitoring that is coming of age as we speak. The IETF has already begun to try and standardize protocols for use in this area...check out the Intrusion Detection Working Group for more info (the results produced by the IDWG would standardize the transfer from producers to consumers mentioned in the article).

Emerald fits into a subset of the network monitoring that is coming of age as we speak. The IETF has already begun to try and standardize protocols for use in this area...check out the Intrusion Detection Working Group for more info (the results produced by the IDWG would standardize the transfer from producers to consumers mentioned in the article).

The Internet Engineering Task Force (IETF) publishes all its standards (the RFCs) for the Internet in American Standard Code for Information Interchange (ASCII). You can also submit the document in PostScript, but the ASCII is the primary reference.

ASCII is searchable, printable, indexable, and forward compatible essentially forevermore. Everyone can display it correctly, anywhere. There is no better format for any kind of International standard. The IETF debates the question of superceding ASCII as the standard format about every other year, but we've yet to identify any other format that has ASCII's advantages.

HTML might one day replace ASCII in this capacity, but it needs to be stable for longer than it has been, and the HTML generators out there never generate correct HTML (ever looked at web pages in iCab? It has a built-in syntax checker, and even slashdot comes up with errors, all the time). Until those problems are fixed...

Well, I'm not quite sure why the FCC thinks they'd know about this area, but I'm pretty sure they're just overseeing the merger, and not drafting the standard. It's a little creepy, but not as creepy as letting The Secret Service handle Computer Crime.

I wish E-mail programs were interoperable; as it is, I see a lot of MIME headers that break elm. But usually that's just spam; only occasionally is it from real people (users of OutLook) that don't know how to send *text*...

These guys wrote RFC2778 and RFC2779; it seems to be designed from an "agent" perspective. I suppose that's the new, hot trend nowadays, but it seems a little heavyweight for just a chat client. However, they're working on it and I'm not, so I suppose I can't complain. :)

Does anyone know about any other RFCs related to this?
---
pb Reply or e-mail; don't vaguely moderate.

See RFC2916. This describes how to map E.164 numbers (telephone numbers) in the DNS. The primary purpose is so that you can email your phone (for example), but there is nothing to stop this system mapping a phone number to a WWW page. Unfortunately this RFC uses the existing reverse-DNS .arpa domain so the phone numbers are written BACKWARDS! Not very friendly.

The solution to California's power problems?

Electricity Over IP.

All the state needs to do is hack into some of New Jersey's many Nuclear or trash burning power plants and everyone can have lights on their house for Christmas and Intel can continue to make faulty chips.

-gerbik

there are not frequent drop-outs in the RF connection

the system does not temporarily suspend connectivity for one reason or another

the wireless data system is not built on top of one not intended for voice

alternatives to TCP are used instead

TCP was not designed to handle temporary dropouts characteristic of mobile data systems. When the subscriber is mobile, they are subject to temporary loss of packets through fading, multipath, and low signal strength. A big problem occurs when you are in marginal coverage areas. TCP's retransmission backs off by doubling the amount of time between retries. 0.5, 1, 2, 4, 8, 15, 30, 60, up to 120 seconds. If you happen to briefly come back into coverage, TCP does not know this, and happily continues to count down the retry timer. Then it fires, but you're out of coverage again, and it doubles the back-off time again, and you can be in great coverage, but no data will be sent until the next transmit opportunity. The backoff algorithm was intended to back off hosts to prevent collapse of the network due to congestion, but since it cannot sense the presence of the network, this "feature" causes a problem in mobile data networks.

To make matters worse, some networks give preference to voice callers and can clamp off the datastream in preference to them. Most carriers realize the impact of this, however, and provide a minimum channel allotment for data.

Data systems designed as overlays on voice systems (CDPD, for example) suffer the problem that voice can be deciphered by the human ear despite noise and dropouts, but data cannot. Therefore, a cellular footprint that is adequate for voice will be too small for data, and coverage holes will exist. Often these are inside of buildings where walls and leaded windows attenuate the signal.

The problem is mitigated by ensuring that signals are strong wherever there are users, but the cost and scarcity of frequencies and cell sites make this solution impractical.

Fixed systems do not generally have these problems because they don't move in and out of coverage and are less susceptible to multipath. Dumb mistakes, though, like installing the system in the woods in winter can cause failure in spring when the leaves grow on the trees and block the signal.

Alternatives to TCP. WAP and HDML employ their own reliable protocols over UDP because of problems with TCP on mobile wireless networks described above. The use of an alternative, T/TCP RFC 1644, has been proposed but it really only addresses transactions where all the data can fit into a single packet.

Even if a new protocol tweaked for wireless were designed to stand along with TCP and UDP in the transport layer, you face the challenge of getting it adopted as part of the stack of systems everywhere.

there are not frequent drop-outs in the RF connection

the system does not temporarily suspend connectivity for one reason or another

the wireless data system is not built on top of one not intended for voice

alternatives to TCP are used instead

TCP was not designed to handle temporary dropouts characteristic of mobile data systems. When the subscriber is mobile, they are subject to temporary loss of packets through fading, multipath, and low signal strength. A big problem occurs when you are in marginal coverage areas. TCP's retransmission backs off by doubling the amount of time between retries. 0.5, 1, 2, 4, 8, 15, 30, 60, up to 120 seconds. If you happen to briefly come back into coverage, TCP does not know this, and happily continues to count down the retry timer. Then it fires, but you're out of coverage again, and it doubles the back-off time again, and you can be in great coverage, but no data will be sent until the next transmit opportunity. The backoff algorithm was intended to back off hosts to prevent collapse of the network due to congestion, but since it cannot sense the presence of the network, this "feature" causes a problem in mobile data networks.

To make matters worse, some networks give preference to voice callers and can clamp off the datastream in preference to them. Most carriers realize the impact of this, however, and provide a minimum channel allotment for data.

Data systems designed as overlays on voice systems (CDPD, for example) suffer the problem that voice can be deciphered by the human ear despite noise and dropouts, but data cannot. Therefore, a cellular footprint that is adequate for voice will be too small for data, and coverage holes will exist. Often these are inside of buildings where walls and leaded windows attenuate the signal.

The problem is mitigated by ensuring that signals are strong wherever there are users, but the cost and scarcity of frequencies and cell sites make this solution impractical.

Fixed systems do not generally have these problems because they don't move in and out of coverage and are less susceptible to multipath. Dumb mistakes, though, like installing the system in the woods in winter can cause failure in spring when the leaves grow on the trees and block the signal.

Alternatives to TCP. WAP and HDML employ their own reliable protocols over UDP because of problems with TCP on mobile wireless networks described above. The use of an alternative, T/TCP RFC 1644, has been proposed but it really only addresses transactions where all the data can fit into a single packet.

Even if a new protocol tweaked for wireless were designed to stand along with TCP and UDP in the transport layer, you face the challenge of getting it adopted as part of the stack of systems everywhere.

Any kind of plan involving a single identifier to reach a person anywhere would be accomplished>through creative use of DNS, and could involve actual names and words. The accounts themselves might possibly use a email-like name@provider kind of system. But I dream.

Well, it looks someone already tought about that... It's called SIP (Session Initiation Protocol) (RFC 2543) I know it allows IP phone addresses like sip://user@host and support call forwarding and other nice stuff... and its much much simpler than H.323

See RFC2916 This describes how to map E.164 numbers (telephone numbers) in the DNS. The primary purpose is so that you can email your phone (for example), but there is nothing to stop this system mapping a phone number to a WWW page. Unfortunately this RFC uses the existing reverse-DNS .arpa domain so the phone numbers are written BACKWARDS! Not very friendly.

Here is a link to the framework description - anyone interested in this topic should DEFINATELY read this - as it addresses almost all of the problems of NATs in a very elegant fashion that can be implemented at the IP Stack layer, transparent to applications.
http://www.ietf.org/internet-drafts/draft-ietf-nat -rsip-framework-05.txt

This IETF I-D includes a novel hack (see part 3) using https.

A few things worry me a bit. First there's the part of the RACE working draft where they mention that if you don't follow all the MUST and MUST NOT statements "exactly", otherwise it's "likely to cause damage to the Internet"

Then there's the issue of the chairman of the IETF basically calling this premature...

"Getting this work done right is more important," he said, "than getting it done quickly."

A few notes...

The Internet Society probably isn't too happy about this. They released a statement on November 8th encouraging NSI to back off and let the IETF IDN WG do its job.

Also, there are companies that are already currently operating in this market, including WALID, which is taking registrations for Arabic domain names (AND RESOLVING THEM), and will soon be adding Hindi, Tamil, and two Chinese scripts before moving into other markets.

No, they've just familiarized themselves with RFC 2324!

Links:

Cisco - IP+ATM Solutions

IETF MPLS Charters

actually IPv6 can be written in Base85
see RFC 1924

this from the RFC :
Why 85?
2^128 is 40282366920938463463374607431768211456. 85^20 is 387595310845143558731231784820556640625, and thus in 20 digits of base 85 representation all possible 2^128 IPv6 addresses can clearly be encoded.

It's funny you should mention the TCP SYN attacks on Panix, because I actually did E-mail a description of this problem to the CERT a full three years before it was actually used as a denial of service attack. I also wrote to the IETF main mailing list a more general observation about denial of service attacks, and the need for all ISPs to do ingress filtering of packets based on IP source address in order to have a first approximation of DoS attack source (who you then go and stomp).

The CERT didn't get it. They did nothing about it until Panix was attacked.

The responses on the IETF list mostly moaned about the cost of adding all those filters to all those CPE routers, and how ingress filtering would stomp one mode for mobile IP...

Three years later, people were a whole lot more interested in dealing with this.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

And an old but, but a classic, RFC #748 which details several "new" Telnet options to facilitate random data/service losses.

I should probably point out that all of those were submitted on April 1st and are actual RFCs that are archived on the Internet Engineering Task Force's webpage. I've got a longer list, should anyone care, but I've got to pick and choose...

The only point to this is that some real RFC's turn out to be hoaxes, in a way! Hope people find those funny. If not, then you should try and implement TCP/IP as described in RFC #1217. Either that or try RFC #2549 - it was discovered that Linux could not implement it because penguins can't fly.

So it is completely up to the network admin how to trade simplicity for privacy. draft-ietf-ipngwg-addrconf-privacy-03 contains a must-read evaluation of the privacy concerns.

-Marcel

BTW: The IP address is longer than the MAC/EUI-64 address to simplify routing. It would be plainly impossible for every router in the world to keep track of each of the several hundred million hosts around.

Check the Internet Draft "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" draft-ietf-ipngwg-addrconf-privacy-03.txt

This actually depends on a multitude of factors. First would be the fact that if the protocol was released free of patent restrictions, the barrier to it's introduction would be extremely low, the the momentum to get it accepted above all others would be much more substancial.

Second, look at http://www.ietf.org/ipr.html, and count the number of protocols that are patent protected and also widely in use. Of the few that are, many have cluases giving royalty-free use of the patent to implement the specification as described by the RFC (e.g. MD2,4,5 and RFC1319, 1320, and 1321, etc). If these were not freely implementable, I doubt they would've reached the kind of audiences it's reached right now. I think the LZW and GIF illustrate this concept very nicely. For years Unisys didn't try to defend it's patent on LZW compression, and during that time, the GIF format grew in popularity like wildfire. Now, after their annoucements of their intention for enforcing their intelectual property rights, there has been growing distaste of GIF.

The other problem I have with all of this is, I don't believe in software patents in general. In an industry where the barrier to entry is exceedingly low, it doesn't make sense to give big business this kind of growing power. In the hardware manufacturing arena, the equipment needed to develop and bring an invention to market is extremely high, but in the software industry, you can easily get all the equipment you need to make tomorrow's "killer app" in less than a thousand dollars, assuming you don't have to license patents from a million big businesses. I find it difficult to believe that in an era where big business is fourishing, we need to have lawmakers sharpen the weapons they use to keep lowly consumers in line. "Promoting the useful arts" with patents and copyrights has become "putting your competitors out of business via lawsuits".

An algorithm ID is already defined for AES in OpenPGP (RFC2440).

It might be nice publicity stunt to release a special version of GnuPG (1.0.4?) with AES support within seconds of the official announcement.

----

• 1. WAP is documented very well. Their document's are as wonderfull as those one might wade through at the
• IETF. WAP is proprietary and deviates from known standards in places it should have and others it shouldn't have. WAP also includes some very nice stuff which will no doubt make it's way back into IETF such as SOME of the WTLS (WAP TLS) work.

  2. Umm. I don't think anything bars you from running WAP over faster carriers - except the existence of the infrastructure to enable them. WAP speed will always be limited by the underlying carrying technology. What kind of voice bandwidth do you think you get on your Verizon Star-Tac? [It seems like everyone in mountain view has a Star-Tac]

  3. HTTP relies on TCP. TCP as it stands is problematic for unreliable connections (ask folks in china what it's like to surf). WAP uses WDP/WTP instead of TCP/HTTP. BFD. I agree they should've modded TCP/HTTP and TLS to suit their needs. The fact of the matter is that while I find the methods a bit distasteful - they are private companies with a plain economic agenda who had to develop variants of existing technologies. They did so and are now working to fold their mod back into the IETF - a much better place for standards to live once they're deployed. I think it is OK to develop proprietary protocols, deploy them, and then release them to the public for modification. This is one of the easiest way for society to benefit from private money's expenditures and I think we should encourage corporate entites which do so!

  The so called "NG WAP" will be based entirely (?) on IETF protocols. There is a bunch of support for this goal within the WAP forum which now has representatives from thousands of companies including all the key players. There is alot of work being done to ensure this can happen. WAP might pull it off :-) Or Not. I don't really care either way as I'm sure I'll have a G3 phone as soon as someone rolls it out where I am - and I'm guessing it'll be able to surf - WAP or otherwise.

  I've been to 4 WAP forum events - they are as boring as can be most of the time. Everyonce in a while RSA and Certicom have a party - but that's another story.

For the IETF, IPR handling is outlined quite clearly in RFC 2026, section 10.

In short, patents are allowed, as long as they are licensed on non-discriminitory terms. Most standards bodies have similar stipulations.

from http://www.ietf.org/i nternet-drafts/draft-manning-dsua-03.txt

169.254.0.0/16 has been ear-marked as the IP range to use for end node
auto-configuration when a DHCP server may not be found. As such, network
operations and administrators should be VERY aggressive in ensuring that
neither route advertisements nor packet forwarding should occur across
any media boundaries. This is true for the Internet as well as any
private networks that use the IP protocols. End node administrators
should be aware that some vendors will auto-configure and add this
prefix to the nodes forwarding table. This will cause problems with
sites that run router discovery or deprecated routing protocols such as
RIP.

Actually, they didn't buy anything. This range is registered with IANA as the link-local IP address range, from which a machine can assign itself a temporary IP, for use during configuration. The range for that is 169.254/16. The definition for how this range is used in IPv4 as part of an ad hoc network is located here. It's also used in IPv6 in RFC 2462.

Unfortunately, there is still no coherent architecture for mirroring and for mirror sites to register their collections with the sites which they mirror. In fact, we lack even a common (de facto) standard for recording this replication information in a machine readable for-mat. Some progress was made on this a few years ago by the Internet Engineering Task Force s [1] working group on Internet Anonymous FTP Archives, with the creation of the so-called IAFA Templates [2]. These provided a simple machine readable format for recording per-resource or collection metadata, which could easily be created by hand or programatically. Although support for IAFA templates was integrated into some software packages, e.g. the ALIWEB search engine [3] and the ROADS resource discovery sys-tem [4] , this approach never became successful on a large scale. The World Wide Web Consortium s Resource Description Format (RDF) [5] and the Dublin Core metadata effort [6] may eventually provide a viable machine readable interchange format.

Currently, the database underlying the freshmeat.net weblog [7] is perhaps the closest thing we have to a genuine mirror registry - though it focuses almost exclusively on soft-ware packages and operating system distributions, and only offers limited mirror informa-tion. RDF is also being used in this capacity as part of rpmfind.net [8], although mirror information is very limited in this case too. The Internet Engineering Task Force s Uni-form Resource Names effort [9] is also relevant here, since it would be very useful if there were persistent and location independent names for these collections of replicated resources.

[1] http://www.ietf.org/ Internet Engineering Task Force website
[2] http://info.webcrawler.com/mak/projects/iafa/ IAFA Working Group & IAFA Templates homepage
[3] http://aliweb.emnet.co.uk/ ALIWEB website
[4] http://roads.opensource.ac.uk/ ROADS website
[5] http://www.w3.org/RDF/ World Wide Web Consortium Resource Description Format (RDF) homepage
[6] http://purl.org/dc/ Dublin Core website
[7] http://freshmeat.net/ freshmeat.net website P. Lenz & Andover Advanced Technologies, Inc.
[8] http://rpmfind.net/ rpmfind.net website
[9] RFC 1737, Functional Requirements for Uniform Resource Names K. Sollins & L. Masinter December 1994

And at the end somewhat less relevant to the topic.

This kind of metadata should be extremely valuable for implementation of the URIs and particularly for the I2C(s) (URI tp URC). Quote from the RFC 2483:

"Uniform Resource Characteristics are descriptions of resources. This request allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resource's URLs. The description might be a bibliographic citation, a digital signature, or a revision history. This memo does not specify the content of any response to a URC request. That content is expected to vary from one server to another."

Freenet is good, it came up with some pretty neat ideas, but it would be better if it had been developped and thought out in advance in the context of an IETF working group, if the specifications had been released as a Request For Comments, and, in other words, if it had paid a little more attention to existing Internet standards instead of being Yet Another anti-censorship system.

For example, why did Freenet have to come up with their own key scheme instead of using the official standard of Uniform Resource Names (URNs) defined by RFC2141 (the previous link was an example of a URN)?

I have this dream of a true world-wide distributed database founded on recognized Internet standards. It would use URNs as keys. (In particular, it would allow arbitrary Unicode character data.) It would use the ubiquitous RDF format as "semantic sugar" (pardon the expression) of its communications. It would borrow ideas from HTTP (the best Internet communications protocol we have so far) for the protocol, and Usenet and Freenet for the distribution mechanisms, as well as the public key distribution system and trust web, and the everything system. It would use public-key cryptography as the basis for its trust graph, so as to make data authentification possible and tampering impossible. Certificates and signatures would be distributed along the network itself. It would employ secret sharing mechanisms to split the risks of carrying certain data. It would be impossible to tamper with, impossible to censor, and extremely difficult to break. It would replace the lousy and obsolete DNS system (and also alleviate somewhat the power of "root registrars" in the DNS), and possibly The Web itself. And, to make my dream even more of a dream, it would be simple to implement.

Hmmm.... Nice project, for the year 2100 or so. Anyone care to start an IETF working group?

• http://www.ie tf.org/internet-drafts/draft-iab-nat-implications- 09.txt
• ht tp://www.ietf.org/internet-drafts/draft-ietf-nat-p rotocol-complications-04.txt
• 
  
  They're interesting reads, if you're interested in how NAT breaks end-to-end transparency and its place in the Internet of now & the future.

• http://www.ie tf.org/internet-drafts/draft-iab-nat-implications- 09.txt
• ht tp://www.ietf.org/internet-drafts/draft-ietf-nat-p rotocol-complications-04.txt
• 
  
  They're interesting reads, if you're interested in how NAT breaks end-to-end transparency and its place in the Internet of now & the future.

Mobile Ad-HOC Networking is being worked on by the MANET group of the IETF.

If done well, then it seems that we could bring back a little freedom back to the internet.

If a wireless network became popular enough, then we could see free(as in speech and maybe pretty cheap), cooperative, wireless networking popping up in metropolitan areas.

Mobile Ad-HOC Networking is being worked on by the MANET group of the IETF.

If done well, then it seems that we could bring back a little freedom back to the internet.

If a wireless network became popular enough, then we could see free(as in speech and maybe pretty cheap), cooperative, wireless networking popping up in metropolitan areas.

This mixed with the anti-terrorism acts of the 1990s could result in arrests and detainings by association. If someone (anyone) sent you an email that stated intent to subvert, collapse, or overthrow, it could be construed as _your_ intent, thereby making you a party to a terrorist group. And all of your associations could be placed in the same group. The CIA could send out spam to anyone who would dissent and then arrest them on the grounds that they were of a particular association. Egads!

Why not just outsource your code to an infinite number of moneys? They could write it for you instantaneously, and you wouldn't even have to give them specs. :-)

Hey, it's not like I'm the only one who ever thought of this...

It looks like the same policy as the IEEE, standards may use patented inventions but the patent holder is required to license the patent under openly specified, reasonable, non-discriminatory terms.

I and a friend here were under the impression that if one uses an IETF standard, e.g. RFC 1341 which defines Base64 encoding, one is obligated to allow others to use it freely. I can't find an explicit statement of that yet on the IETF pages, but if this is the case it would seem that Digital Convergence would be the ones in violation.

As far as I understand SSL, you must use virtual interfaces to host SSL web servers. How does the policy change affect these servers?

Yes, but every virtual interface has a different IP address. And ARIN sells IP's not NIC's ;-)
The reason is explained in many articles above, but the vhost part in the mod_ssl FAQ is also very good.

Also, TLS is supposed to fix that. Which browsers implement TLS correctly?

It's not whether TLS or not, it's whether the browser can make use of the upgrade mechanism in TLS.
And equally important is the question which webservers implement this? Last time I checked mod_ssl did not.

As far as I understand SSL, you must use virtual interfaces to host SSL web servers. How does the policy change affect these servers?

Yes, but every virtual interface has a different IP address. And ARIN sells IP's not NIC's ;-)
The reason is explained in many articles above, but the vhost part in the mod_ssl FAQ is also very good.

Also, TLS is supposed to fix that. Which browsers implement TLS correctly?

It's not whether TLS or not, it's whether the browser can make use of the upgrade mechanism in TLS.
And equally important is the question which webservers implement this? Last time I checked mod_ssl did not.

It's fairly simple - the browser request makes a GET, then follows by passing a series of headers:

GET / HTTP/1.0
Host: hostname.domain.tld
User-agent: Mozilla
<blank line to terminate request>

Then expects the return from the server.

So, when you run off to http://slashdot.org/comments.pl, it's performing:

GET /comments.pl HTTP/1.0
Host: slashdot.org
User-agent: Mozilla
<blank line to terminate request>

Both HTTP 1.0 and 1.1 implement this, if you want to read the RFC 1945 and RFC 2068 for information on HTTP 1.0 and 1.1 respectively.

It's fairly simple - the browser request makes a GET, then follows by passing a series of headers:

GET / HTTP/1.0
Host: hostname.domain.tld
User-agent: Mozilla
<blank line to terminate request>

Then expects the return from the server.

So, when you run off to http://slashdot.org/comments.pl, it's performing:

GET /comments.pl HTTP/1.0
Host: slashdot.org
User-agent: Mozilla
<blank line to terminate request>

Both HTTP 1.0 and 1.1 implement this, if you want to read the RFC 1945 and RFC 2068 for information on HTTP 1.0 and 1.1 respectively.