Slashdot Mirror

Yeah, right. We've been hearing about how we should all be using XHTML and XML for ages. And yet... the web is still running on HTML 4.01.

I think that if you look a little closer, you'll find that the web isn't "running on" XHTML or HTML 4.01, but rather a bizarre concoction of tag soup that happens to make popular browsers behave a certain way.

serving XHTML as "text/html" is wrong

Perhaps according to you, but not according to RFC 2854, which defines the text/html media type.

I haven't actually checked to see if the new IE7 supports XHTML properly

It doesn't.

XHTML doesn't really solve anything.

It doesn't so long as it's a minority. When the overwhelming majority of the web uses XHTML, its draconian error handling that it inherits from XML will simplify browsers considerably. This has already happened to a certain extent with the mobile web.

You can style XML documents with CSS, which means you could conceivably have a document that describes the contents of the page in a fairly "semantic" manner

That's completely wrong. Sure, you could make up your own semantics that you associate with the element types you use in your ad-hoc XML format, but nobody else would know about those semantics. That's why you use a common, specified XML format... like... XHTML, where the semantics are understood.

XML isn't a super-format that magically gives you semantics. XML solves the syntax problem and stays well away from the semantics problem. Semantics are addressed at a higher level.

With XML and CSS, it uses essentially the exact same semantics that HTML and CSS do

Generic XML has essentially no semantics whatsoever. It certainly doesn't have the same semantics as HTML.

So you basically mean that an avian carrier brought the necessary IP datagrams to the Slashdot web server?

The obvious question is then, was it a european rock dove, or a ...

Err, I mean, did it use the experimental QoS extension as well?

So you basically mean that an avian carrier brought the necessary IP datagrams to the Slashdot web server?

The obvious question is then, was it a european rock dove, or a ...

Err, I mean, did it use the experimental QoS extension as well?

Realizing the humor meant to be delivered in your post, one must not forget the fundamental truths of networking - Section 3 of RFC 1925:

"With sufficient thrust, pigs fly just fine."

This is Slashdot, you should have linked directly to the RFC
http://www.ietf.org/rfc/rfc1149.txt

I'm feeling lucky

Version 5 of IP was assigned to an experimental protocol called ST2 (Internet Stream Protocol, version 2), which is described in RFC 1819 and, AFAIK, was IPv4 with QoS for voice and data over multicast or somesuch.

HTH

The Set-Cookie header (which is one of the ten most-used headers) is present on about two orders of magnitude more pages than the Set-Cookie2 header (despite the former being considered insecure).

No, they should switch to ATOM 1.0 and don't mess it up. ATOM seems to be more suitable for Photocasting anyway.

What the hell is Atom and who supports it?

Atom is "an XML-based document format that describes lists of related information known as "feeds"" ... with the primary use case of "the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents", as specified in RFC 4287. And it's supported by... well, pretty much everything out there.

If you read the RFC, you will also see that Atom is superbly well-specified. Back in the Atom 0.3 days, I implemented both an RSS feed and an Atom feed, and ever since I've stuck to implementing solely Atom feeds, as information about RSS is scattered everywhere, and you need to specify, for example, half a dozen mutually-incompatible and differently-formatted date elements just to be certain that the correct date of an entry is understood everywhere. And that's the easy part.

Atom is the IETF standard syndication format (RFC 4287), and is supported by a lot of software (i.e. there's 67 feed readers listed as supporting Atom, so it's hardly some obscure format).

$ telnet jabber.org 5222
Trying 208.245.212.98...
Connected to jabber.org.
Escape character is '^]'.
C: <?xml version='1.0'?>
C: <s:stream to='jabber.org' xmlns='jabber:client' xmlns:s='http://etherx.jabber.org/streams' version='1.0'>
S: <stream:stream xmlns='jabber:server' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xmlns:db='jabber:server:dialback' id='86D84E441A15' version='1.0'><stream:error><bad-format xmlns='urn:ietf:parms:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Invali d stream header</text></stream:error></stream:stream>Connec tion closed by foreign host.

$ telnet jabber.org 5222
Trying 208.245.212.98...
Connected to jabber.org.
Escape character is '^]'.
C: bad header
S: </stream:stream>Connection closed by foreign host.

C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>

So if one set of monkeys set out to write an operating system, can we assume that another set of monkeys would write one too. Further more, would it be likely that both set of monkeys would eventually write the same lines of code? I would say "yes". Especially if we use the "Infinate monkeys typing away at keyboards to reproduce Shakespear's works" theory. See also: http://www.ietf.org/rfc/rfc2795.txt

Therefore, SCO has no case.

Did u still have the Reverse time-capsule? I would like to send Gray's Sports Almanac 1950-2000 to my father...

Regarding the use of the CRL distribution point extension, a URI that points to a DNS alias can help alleviate the risk.

"OSPF" was likely a botched reference to OCSP (Online Certificate Status Protocol), defined in RFC 2560.

Finally, read the PKIX spec on certificate management, RFC 3280. It will give you a much more detailed understanding of how PKI should work than any vendor docs. This level of understanding is critical if you start playing the role of CA.

If you do your homework, and understand how things work, OpenSSL is an adequate tool.

Regarding the use of the CRL distribution point extension, a URI that points to a DNS alias can help alleviate the risk.

"OSPF" was likely a botched reference to OCSP (Online Certificate Status Protocol), defined in RFC 2560.

Finally, read the PKIX spec on certificate management, RFC 3280. It will give you a much more detailed understanding of how PKI should work than any vendor docs. This level of understanding is critical if you start playing the role of CA.

If you do your homework, and understand how things work, OpenSSL is an adequate tool.

Yeah, you and RFC 3339 (and their dog).

The mime type thing is a "should" not a "must" in the guidelines

Which guidelines are we talking about? I'm aware a W3C member published a Note saying that; just because it appears on the W3C domain, it doesn't mean it's the W3C's official position, and the Note states this.

You shouldn't be paying attention to non-normative guidelines and notes. You should be paying attention to the specifications. And the specifications are quite clear - RFC 2616 declares the media type contained in the Content-Type header to be authorative and not ignorable, and RFC 2854 clearly states that the only form of XHTML suitable for transmission as text/html is XHTML 1.0 following the compatibility profile (a.k.a. Appendix C.).

therefore IE has support for XHTML.

No, this is not the case. Just because it displays something, it doesn't mean it supports XHTML. Hey, I can get 'cat' to "display" a JPEG file in an incorrect way - does that mean that it is a JPEG parser?

Does Internet Explorer enforce the mandatory error handling? No. Does it enforce the mandatory lowercase DOM element type names? No. Does it use the XHTML CSS rules? No, it uses the HTML CSS rules. Does it understand xml:lang? No. Does it imply <tbody> elements inside <table> elements? Yes - which is correct for HTML but incorrect for XHTML. Does it support the XHTML content model for <script> and <style> elements? No, it uses the HTML content model.

In every way I can think of in which XHTML differs from HTML, Internet Explorer gets it wrong. No, it doesn't support XHTML.

The mime type thing is a "should" not a "must" in the guidelines

Which guidelines are we talking about? I'm aware a W3C member published a Note saying that; just because it appears on the W3C domain, it doesn't mean it's the W3C's official position, and the Note states this.

You shouldn't be paying attention to non-normative guidelines and notes. You should be paying attention to the specifications. And the specifications are quite clear - RFC 2616 declares the media type contained in the Content-Type header to be authorative and not ignorable, and RFC 2854 clearly states that the only form of XHTML suitable for transmission as text/html is XHTML 1.0 following the compatibility profile (a.k.a. Appendix C.).

therefore IE has support for XHTML.

No, this is not the case. Just because it displays something, it doesn't mean it supports XHTML. Hey, I can get 'cat' to "display" a JPEG file in an incorrect way - does that mean that it is a JPEG parser?

Does Internet Explorer enforce the mandatory error handling? No. Does it enforce the mandatory lowercase DOM element type names? No. Does it use the XHTML CSS rules? No, it uses the HTML CSS rules. Does it understand xml:lang? No. Does it imply <tbody> elements inside <table> elements? Yes - which is correct for HTML but incorrect for XHTML. Does it support the XHTML content model for <script> and <style> elements? No, it uses the HTML content model.

In every way I can think of in which XHTML differs from HTML, Internet Explorer gets it wrong. No, it doesn't support XHTML.

Because if ever there were a software paradigm worthy of patenting, NTP would be it.

Yea...I've been there.

I give them Kudos for trying. It looks like there is progress. But it's slow.

http://ops.ietf.org/multi6/

I was in a meeting with one of the main people involved with IPv6 deployment on I2. One of the sad things is that the multihome problem has been known for some time and it was assumed that SOMEBODY would solve the problem but the years just ticked on by.

I really can't see the gov moving forward unless this problem is solved....OR every gov agency will end up with it's own provider independant address block.

If you are interested in keeping track of what is going on in this area the IETF has a working group that is fairly active trying to figure this problem out.

http://ops.ietf.org/multi6/

There are some interesting solutions. Some look like hacks, but there are smart people thinking about it.

Connecting to more than one ISP without needing a provider independent address block is exactly what the IETF shim6 working group is trying to do.

besides, the 6bone is obsolete as described in http://www.ietf.org/rfc/rfc3701.txt?number=3701
The 6bone was a test network. it has served it's useful purpose, but now isn't needed anymore, as the production IPv6 network is currently undergoing deployment.

Something tells me that the developers who worked on this haven't even heard of RFC 2616.

It's not an official site, though, just a compilation of DNSSEC information. It actually seems to be very comprehensive, obviously the compiler put a lot of effort into it. Maybe a bit crowded layout on the home page, yes, but lots of info. But here's the direct link to RFC 4033 if that helps.

Eric
Read my Invisible Fence Guide

Uh ... yeah. But the point of the article was to test a tri-core system. Everyone knows that a quad system works. Heck you can buy one from Apple today if you want, and they're probably not the only ones.

But I doubt anyone has ever used a tri-core system, and that's why they wrote the article. Saying "why didn't they just use two dual-cores" is akin to reading a magazine about tuner cars and saying "why don't they just buy a Lambo?"

I think their ultimate point was to say something about the feasibility of triple-core, single-chip products -- that is three cores on one wafer, as a sort of stopgap until they can squeeze the transistors enough to put four cores on -- but in reality it isn't much of a comparison because the problems that they have with their two-chip tri-core that lead to the crashing probably wouldn't be present with a purpose-fabricated single-chip tri-core (because one assumes the chip designers would use three identical processors and would go to lengths to make them talk well to each other).

It's arguably a bit of a pointless exercise ... but then again, this is Slashdot. Nothing is a pointless exercise here.

So lets say that of the oh, call it 200 patent licenses necessary to build and sell a laptop computer that roughly 50% are false. The laptop in question costs $1,200 of which $200 is parts, and another $100 labor, and yet $100 more is shipping. So $800 / 200 = $4.00 per license.

But as I said, assume half of the licenses are for bogus patents. That'd mean we're paying about $400 more for a laptop than we should actually have to.

I've seen some pretty wild patents. And the USPTO is just handing them out without any real validation. Reminds me of the RFC for TCP/IP via Carrier Pigeon. http://www.ietf.org/rfc/rfc1149.txt?number=1149

hi, there, why is the parent at 0?

The above link is great. I'll link there again.
http://www.ietf.org/rfc/rfc3675.txt

The IETF tried and failed to regulate morality like this in 2003. It was a brilliant but doomed plan. What makes you think ICANN can do better? There was a brilliant RFC [3514] http://www.ietf.org/rfc/rfc3514.txt crafted to improve the efficiency and efficacy of network security screening / content filtering by requiring evildoers and ne'er do wells to mark a special IP security flag known as the 'evil bit' in packet headers containing malicious content.

In IPv6 there was to be an malicious content extension header that required evil people/organizations/companies to mark the severity of the evil in the packet with a 128-bit rating scale for severity.

The new scheme failed (of course) as the idea was not adopted by certain evil enterprises that posed as corporations run by high-level government officials. These corporations wanted (and had the political backing to do so) to mask their evil intentions so they failed to mark the 'evil bit' or marked the 'good bit' and disguised their content as in the interest of the common man, in "the service of the Lord", or as necessary in the fight against global terrorism.

Good thing you don't have a clue what you're talking about.

When it comes to DNS, there is nothing in RFC 1034 nor RFC 1035 that says that Verisign can't have unregistered .com names point to a website they control. What Verisign did may be slimey, but please RTFS before claiming that Verisign broke the standard.

This is like the people who think that any DNS server that acts differently than BIND somehow breaks the standard.

When it comes to DNS, there is nothing in RFC 1034 nor RFC 1035 that says that Verisign can't have unregistered .com names point to a website they control. What Verisign did may be slimey, but please RTFS before claiming that Verisign broke the standard.

This is like the people who think that any DNS server that acts differently than BIND somehow breaks the standard.

If ICANN wants to play down the influence of the US government, something that it could do is to provide rationale for what it is doing that come from a neutral and respected source. For example, the US Gov't says .xxx is bad. ICANN agrees. People are in uproar. ICANN then says *why* they agree with the US Gov't and state reasons that are neutrally-rooted as to why. For example, they can cite this thing by the IETF (on last check, a fairly neutral group, not tied with the US Gov't): http://www.ietf.org/rfc/rfc3675.txt

The XXX domain name itself is the singular most offensive thing being pushed on the internet

It's quite common these days for non-Americans to pin just about anything as a mistake of the US government. Not that I blame people for doing so because we have had quite a number of our diplomatic blunders in the past years... but to let this tainted image result in the assumption that the US government does the wrong thing all the time is just as incorrect as assuming that the US government does the right thing all the time.

In any case, just because religious conservative groups oppose the .xxx domain doesn't automatically mean that those who dislike religious conservatives (me=atheist) must then automatically take the opposite side--there are, believe it or not, instances when two opposing sides can take the same stance on the same issue (though their reasons for doing so may certainly differ).

There are a lot of issues to consider, and to save myself the trouble, I'll just paste a link to this IETF document, RFC3675.

http://www.ietf.org/rfc/rfc3675.txt

The IETF, on last check, isn't religiously-motivated, nor are they politically affiliated. ;) Hope this helps.

In fact, there's a RFC out there covering the IP adressing issues. Have fun.

10 years?? Try 23 years :)

And, oh yeah, lots of ideas on how to replace SMTP have been proposed. None of them have caught on.

I just read through CP80's "technical briefing" which I'd strongly recommend /. readers review (it's located at: http://www.cp80.org/solutions/ ). Treating the matter seriously (which isn't easy), there are a few observations:

Viability: CP80 isn't. When you misunderstand the very basics of the subject material from the start (such as this nonsense: "Ports & Protocols = Internet Channels")a few minutes with RFC 1700 would be a good start for CP80's technical advisors, if they have any). Consider the following CP80 quote:

There are over 65,000 Internet channels available on the Internet today. These channels are already used to categorize content and services.

No they're not. They're used to correspond to applications that operate at a known port. This is much lower in the OSI model, where content filtering typically requires application awareness (OSI layer 7).

ISP Administration: CP80 wants ISPs to offer you channels (as if the believe ISPs create the content, which you'd have to do in order to control the content at the appropriate layers), presumably 80 & 443 for "clean content", perhaps 81/444 for rated PG (sorry hosts2 nameserver and snpp), 82/446 for R and 83/447 for X (working around microsoft-ds at 445 for the moment). Should we go down this path, this probably will be the necessary incentive for providers to move residential broadband completely to an opt-in protocol/port model and quit blocking ports. We'll just enable the few basics - your "web channels" (ugh), a mail channel that only goes to us and perhaps a couple of others necessary for audio/video streaming and such. We'll push all through proxies to make sure you're not tunneling something other than the desired protocol (and still, there will be ways around this). It's a radical departure at significant expense and unfortunately doesn't quite work (as most things that ignore Internet architecture do). Coordination between all ISPs, NSPs, OS and software vendors, standards bodies and content providers would be rather necessary and mandatory.

There /is/ a potential solution that addresses the unlikely mandatory compliance aspect and approaches the content filtering on an optional basis (usable for those that wish to integrate it) and I'll post and draft it out this morning so there's evidence of prior art (we know how the SCOG folks have a difficult time understanding how intellectual property works). I'd be willing to push it further into a public commons patent application e.g. under ODSL's patent commons (just so CP80 doesn't make the same mistake SCOG did by thinking they owned other people's IP and get congressional support behind misappropriated property).

An effective approach is to use a shim protocol, similar to how MPLS is implemented (and wedged), that would insert a content header immediately ahead of the IP datagram. The datagram would specify content settings and either be processed by equipment (CPE, firewalls, routers, PCs, etc.) that are Content-Shim aware or ignored by those that aren't. Service providers could implement it and push administration of the filtering to the end-user (though this assumes content providers are using the shim protocol as well as they push out traffic). Done at this level, it is independent of port management issues and other unworkable nonsense.

Contact me if you'd like to work on a content shim on sourceforge with the prototype code under GPL and intellectual property donated to ODSL patent commons.

*scoove*
(scoove-at-yahoo.com)

So someone has finally found a practical use for IP over Avian Carriers?

SSLv3, of course.

http://wp.netscape.com/eng/ssl3/ssl-toc.html

Or the later draft-freier-ssl-version3-02

Those drafts, and more stuff, is linked to from the Netscape SSLv3 page.

There's also RFC 2256 for TLS 1.0.

Actualy your incorrect, the /64 can be the public IP's on your cable modem etc (remember it's a L2 bridge) same goes for your cell phones etc. Your descibing one possible addressing scheme that is not required. Per http://www.ietf.org/rfc/rfc2462.txt providers are free to use a statefull addressing scheme. A statefull scheme could be seen by the provider to provide accounting. Nowhere in the IPv6 spec does it require that ISP's assume a router at the customer end rather they are free to assume a single end station and have there gear enforce that assumption.

You have the .xxx backwards - it was actually a good idea, shot down by the US government because it offended their christian ethics. ICANN could have stood up for its independence - instead it just confirmed it was little more than a department of the US government.

It seems that the good folks at IETF also think it was a bad idea. RFC3675

Go read RFC 3041 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", dated January 2001.

"Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node."

The two reasons there's so much bloat in IPv4 routing tables are that customers want to have their own provider-independent address space (so they're not tied down to a single provider) and want to multi-home to two different ISPs, advertising their address space on both ISPs so that if either connection fails, there are still routes to their address space. This means that every ISP out there needs table entries for the multi-homed customer's address space, even though the customer might only need one or two IP addresses, and the routing protocols often have calculations that need N**2 or at least N log N space, so it's especially annoying. (By the way, there's work on upgrading BGP from 16-bit ASNs to 32-bit ASNs to deal with the increasing numbers of multi-homed customers.)

IPv6 was supposed to fix this by providing enough address space that customers in the old swamp could be reallocated to provider-aligned space, but the customer-ISP politics problem is still there, and the need for reliable multihoming is still there. Browsers and DNS caching make the problem much worse, because DNS-derived IP addresses are persistent - if www.example.com's connection 1.1.1.1 fails, you can't just use DNS to tell the end users to use 2.2.2.2 instead, because DNS caches mean the update might not appear for days, and browsers and some other applications don't look up DNS entries on every packet either, so multi-homed customers really need to do rerouting to work around failures. That kind of speed is ok for network renumbering when you're changing ISPs with a week of advance preparation, but it's not fast enough for routing around failures.

There's an ugly project called shim6> that's supposed to work around the renumbering and routing issues, and it avoids NAT by replacing it with something IMHO almost if maybe not quite as nasty. AFAICT, the working group's not really finished with it, and it requires host software because it's a routing shim in the end-device's protocol stack.

At Tuesday's IETF meeting in Vancouver the vote for consensus was many for and none against elevating the IPv6 Protocol Standards from "draft Standard" to "Internet Standard" and make them part of the everyday production Internet. The IPv6 WG is even shutting down as it has accomplished its mission and designed a good working protcol. The wired and wireless networks provided for the engineers at the IETF is running IPv6 and we are regularly using it to get information from our working group colloboration sites like: www.v6ops.euro6ix.net/

Don't fear, the IETF V6 Operations (V6OPS) team and the IPv6 Forum will continue work to better clarify how to deploy IPv6 and to help build new network services around the new features. Most of the new network services groups in the IETF are basing new services on the features of IPv6 - early examples are Mobile IPv6 (MIPv6) and Network Mobility (NEMO) both of which are being extended to offer IPv4 access through IPv6 tunnels in order to get IPv4 native service through IPv4 NAT.

If you actually have useful comments or design alternatives for IPv6, bring it up in IETF working group mailing lists [http://www.ietf.org/html.charters/wg-dir.html%5D. If you don't understand because of FUD, please read up on our North American IPv6 Task Force website website [ www.nav6tf.org/ ] or the similar European/Asian sites.

It's not like the TLD was a good idea to begin with.

Yeah, America would never try to pass legislation regulating good taste on the Internet - nothing like the Communications Decency Act or the Child Online Protection Act

this has nothing to do with new protocols or a global firewall.

Fourth and finally, there are technical standards that must be formally established and coordinated to ensure the Internet's interoperability.

"What, you want Cuba running the Internet?" No, I don't.

Then what is your solution? The UN routinely appoints despot regimes to chair the human rights subcommittee. ITU is under the UN ... you don't see the problems with that? Such as depot regimes making it difficult to use cheap alternatives to the gov't telecom monopolies?

The article discusses the standards the Internet uses. Currently these standards are issued by IETF under the auspices of the Internet Society. IETF is an truly international organization where the people with ideas and time have the influence in terms of authoring or editing standards, chair working groups, and directing actitivies, all achieved by a credo of "rough consensus, running code". It is a system that prizes technical excellent above politics. The same system that told the USA to piss off when the gov't attempted to cripple encryption over the the network in order to "protect us." Under your vision this would be replaced with each national government voting on standards; the same people who gave us OSI standards that were stillborn. The nerds would lose control to Castro, Mugabe, and the Ayatollah, not to mention the regulators of democratic regimes. Get ready for a new internet protocol with gov't backdoors in the standards.

Next week IETF meets in Vancouver. I expect it will be one of the last IETF meetings I'll attend, thanks to visionaries like you.

The Internet is global, and no one nation should have a chokehold over a global system.

"What, you want Cuba running the Internet?" No, I don't.

Then what is your solution? The UN routinely appoints despot regimes to chair the human rights subcommittee. ITU is under the UN ... you don't see the problems with that? Such as depot regimes making it difficult to use cheap alternatives to the gov't telecom monopolies?

The article discusses the standards the Internet uses. Currently these standards are issued by IETF under the auspices of the Internet Society. IETF is an truly international organization where the people with ideas and time have the influence in terms of authoring or editing standards, chair working groups, and directing actitivies, all achieved by a credo of "rough consensus, running code". It is a system that prizes technical excellent above politics. The same system that told the USA to piss off when the gov't attempted to cripple encryption over the the network in order to "protect us." Under your vision this would be replaced with each national government voting on standards; the same people who gave us OSI standards that were stillborn. The nerds would lose control to Castro, Mugabe, and the Ayatollah, not to mention the regulators of democratic regimes. Get ready for a new internet protocol with gov't backdoors in the standards.

Next week IETF meets in Vancouver. I expect it will be one of the last IETF meetings I'll attend, thanks to visionaries like you.

The Internet is global, and no one nation should have a chokehold over a global system.

At present, IPv6 mobility depends on a lot of fiddly detail. However, here are some links on how IPv6 mobility works under Linux and how it is currently intended to work:

• Mobile IPv6 for Linux - Includes initial support for "network mobility" (move whole networks around, not just machines)
  
• A study on transient addressing in Mobile IPv6
  
• British Telecom presentation on Mobile IPv6 using a home base system
  
• IETF working group for Mobile IPv6
  
• Historical Notes: Mobile IPv6 for Linux, in the days of the 2.1 kernels!
  

Quick summary: The user's machine registers with their home router (the home base). When they move to a different network, they notify their home router, which then sets up a transitory IP address on the remote network. The home router then cascades back up the routers the message that the fixed IP address of the mobile machine should now be routed to the transitory IP address, optimizing the routing. When an entire network moves, it notifies its home router in the same way, the only difference being that because you're migrating the router, you also migrate all of the machines attached to it - but none of the machines need to know this or be set up to handle it.