Slashdot Mirror

This is why IPv6 is a much better network (layer 3) protocol for VoIP as it supports mobility natively, allowing TCP and UDP sessions to be maintained when roamning from one network to the next.

In fact, the Internet Society point out that IPv6 is necessary for mobile and wireless internet.

If you have XP Service Pack 2, and are behind a router, the ICMP vulernability is a non-issue. Your router responds to pings, not your computer.

You do know that ICMP is more than just pings, right?

http://www.ietf.org/internet-drafts/draft-gont-tcp m-icmp-attacks-03.txt

kybred

You can overcome the 100 foot limitation by tunneling it over traditional phone lines, or even VOIP lines, although you may require a speakerphone at the other end. Another tunneling option might be this http://www.ietf.org/rfc/rfc1149.txt, but I suspect there may be some latency issues.

and another one: MPLampS
RFC 3251 - Electricity over IP

Can you believe the slashdot overloards rejected this as a story! http://www.ietf.org/internet-drafts/draft-lohsen-i p-burrito-00.txt

RFC 748 was written by the same guy who wrote RFC 4042, issued today.

I also agree that the recent April Fools RFCs aren't all that funny. The Evil Bit last year was pretty lame.

RFC 748 was written by the same guy who wrote RFC 4042, issued today.

I also agree that the recent April Fools RFCs aren't all that funny. The Evil Bit last year was pretty lame.

Isn't April Fools Day just the best? =] For a 'full' list of sites pulling pranks today check out this list here

Here is a sample:

kellyosbourne.org - Sanctuary records group shut us down
nukefreezone.net - Making fun of atrios.blogspot.com
weebl.jolt.co.uk - Replaced with Cats-By-Mail
telecom.co.nz - Click 2 Brick
ytmnd.com - (NSFW) hacked by teens for christ
wingus.ampedhost.com - Site converted into Mingus' Gently-Used Furniture store. Oh dear. Why won't he be kind?
homestarrunner.com - Now a pay service.
whirlpool.net.au - Australia's biggest Luddite to head Australia's largest telco
thinkgeek.com - Fake product listings.
theregister.co.uk - Bush twins to join Air Force tech unit in Iraq
creativebits.org - Site purchased by Microsoft
ocremix.org - Now partnered with EA (or something like that). Called EA ReMix.
spacedaily.com - Bush Cancels Space Shuttle Program
planet.gnome.org - Switched sites with planet.kde.org
planet.kde.org - Switched sites with planet.gnome.org
ietf.org - RFC: Efficient Transformation Formats of Unicode
beejaysworld.de - Gentoo dropping livecds for x86
nature.com - Apollo bacteria spur lunar erosion
antwrp.gsfc.nasa.gov - Water On Mars
smh.com.au - (Free Reg Req) SMEGmail offers 1 terabyte storage
smh.com.au - (Free Reg Req) Linux looks to Hilton for exposure
thetoque.com - Canada Builds Own Missile Defense Shield
onion.com - U.S. Dog Owners Fear Arrival of Africanized Fleas
chron.com - Bush Twins in Maxim
ask.com - Jeeves has been replaced by a robot
animenewsnetwork.com - Viz Unlicenses Naruto
uninventthewheel.co.uk - New BMW technology to get around the EU ban on right hand drive cars in Europe.
newgrounds.com - changing to numagrounds.com
neopets.com - neopets adds 50 new pets
www.firstloox.org - The Loox is being recalled
packages.gentoo.org - Adobe doesn't sell products for Linux
pc.ign.com - Microsoft World of Wordcraft (Extremely Obvious)
spamusement.com - Page full of spoof banner ads
gentooexperimental.org - Gentoo using the NT kernel
moddb.com

For a full list of sites that pulled April Fools Day Pranks this year check out this list here -

Here is a sampling:

dotget.net - Microsoft to put P2P software .GET into next version of Windows
kylewenda.com - the government records your phone calls... scary
rfc-editor.org - RFC for "Requirements for Morality Sections in Routing Area Drafts"
planet.gentoo.org - Various things, CFLAGS, etc
fark.com - Many Jokes (keep reloading): BOOBIES!, Logged in as admin, North-Central Kentucky Bunghole-Discharge, page from 1999, BEER
2600.com - Formal Attire required for 2600 meetings today
forumsector.com - Changed the name to Nascar Sector
wikipedia.org - Britannica taking over Wikimedia
google.com - Google releases Google Gulp
kellyosbourne.org - Sanctuary records group shut us down
nukefreezone.net - Making fun of atrios.blogspot.com
weebl.jolt.co.uk - Replaced with Cats-By-Mail
wingus.ampedhost.com - Site converted into Mingus' Gently-Used Furniture store. Oh dear. Why won't he be kind?
homestarrunner.com - Now a pay service.
whirlpool.net.au - Australia's biggest Luddite to head Australia's largest telco
theregister.co.uk - Bush twins to join Air Force tech unit in Iraq
creativebits.org - Site purchased by Microsoft
ocremix.org - Now partnered with EA (or something like that). Called EA ReMix.
spacedaily.com - Bush Cancels Space Shuttle Program
planet.gnome.org - Switched sites with planet.kde.org
planet.kde.org - Switched sites with planet.gnome.org
ietf.org - RFC: Efficient Transformation Formats of Unicode
beejaysworld.de - Gentoo dropping livecds for x86
nature.com - Apollo bacteria spur lunar erosion
antwrp.gsfc.nasa.gov - Water On Mars

Slashdot would be remiss if they didn't put up the link.

I suspect RFC 4042 will make a cameo on the Slashdot homepage today as well.

Slashdot would be remiss if they didn't put up the link.

I suspect RFC 4042 will make a cameo on the Slashdot homepage today as well.

Slashdot would be remiss if they didn't put up the link.

I suspect RFC 4042 will make a cameo on the Slashdot homepage today as well.

Slashdot would be remiss if they didn't put up the link.

I suspect RFC 4042 will make a cameo on the Slashdot homepage today as well.

For a full list of sites that pulled April Fools Day Pranks this year check out this list here Here is a sampling: dotget.net - Microsoft to put P2P software .GET into next version of Windows
kylewenda.com - the government records your phone calls... scary
rfc-editor.org - RFC for "Requirements for Morality Sections in Routing Area Drafts"
waferbaby.com - amusing php error
planet.gentoo.org - Various things, CFLAGS, etc
fark.com - Many Jokes (keep reloading): BOOBIES!, Logged in as admin, North-Central Kentucky Bunghole-Discharge, page from 1999, BEER
2600.com - Formal Attire required for 2600 meetings today
forumsector.com - Changed the name to Nascar Sector
wikipedia.org - Britannica taking over Wikimedia
google.com - Google releases Google Gulp
kellyosbourne.org - Sanctuary records group shut us down
nukefreezone.net - Making fun of atrios.blogspot.com
weebl.jolt.co.uk - Replaced with Cats-By-Mail
telecom.co.nz - Click 2 Brick
ytmnd.com - (NSFW) hacked by teens for christ
wingus.ampedhost.com - Site converted into Mingus' Gently-Used Furniture store. Oh dear. Why won't he be kind?
homestarrunner.com - Now a pay service.
whirlpool.net.au - Australia's biggest Luddite to head Australia's largest telco
thinkgeek.com - Fake product listings.
theregister.co.uk - Bush twins to join Air Force tech unit in Iraq
creativebits.org - Site purchased by Microsoft
ocremix.org - Now partnered with EA (or something like that). Called EA ReMix.
spacedaily.com - Bush Cancels Space Shuttle Program
planet.gnome.org - Switched sites with planet.kde.org
planet.kde.org - Switched sites with planet.gnome.org
ietf.org - RFC: Efficient Transformation Formats of Unicode
beejaysworld.de - Gentoo dropping livecds for x86
nature.com - Apollo bacteria spur lunar erosion
antwrp.gsfc.nasa.gov - Water On Mars

....I'd like to remind ppl of RFC 3514

Like this?

How about the tried and tested Carrier Pigeon? Or maybe posting DVDs through the snail mail?

I think the parent is more referring to the 2003 April fools RFC : The Security Flag in the IPv4 Header

You are assuming that every packet that comes down your internet connection will have a destination IP address matching

No, I assume that my NAT box will drop any packets whose address don't match it. That is the case with my own NAT, although I suppose others could function promiscuously, although that would be contrary to the definition of NAT. (And it would be quite inefficient, as flooding the ethernet hubs inside NATs with all their neighbors' non-matching packets) If you think that many NATs disobey that definition, then you might submit corrections to pages like this and especially this.

your router's public IP address.

You are assuming I even HAVE a router. Router != NAT... routers expose the addresses of machines behind them, NATs hide these.

1. You are effectively placing the security of your LAN into the hands of your ISP.

1. For most people, who are (as I said) sadly clueless, that security is better than if they were plugging Windows XP directly into the internet.

2. The ISP already has its hands on security for most LANs. As the ISP, they are in a fine position to man-in-the-middle and replace any software you download with trojaned versions. Those security-conscious people who make sure that everything is downloaded encrypted are safe, but they are outside the class of user I was discussing.

In this situation other users can simply add a route to your LAN's address via your outside IP address and viola, full access to your LAN.

Once again, relies on the assumption that a Network Address Translator will pass through untranslated packets.

IIRC, ISO 8601 allows a whole bunch of optional syntax that can confuse things. Also, the text of ISO 8601 isn't freely available. Why not campaign for RFC 3339 full-date format dates instead?

1. Indeed, you are right that the patent is NOT AT ALL IPv6 related. So both PUBPAT, ZDNet and Slashdot are wrong here.
2. It is related to IPv4 link-local addresses. Indeed, the 169.254/16. address you mention. You're correct there. Now, please read RFC 3927 for all details.
3. As you can see in Appendix A of RFC 3927, these "IPv4 link-local addresses" where implement in Windows 98 and Mac OS 8. You missed the boat completely here.
4. This technology is NOT "owned" by MS as you claim.
5. However, both Microsoft AND Apple too(!) do claim IPR over this technology.
6. It is VERY interesting to note that both Apple's patents were submitted March 21, 1985, and have thus expired last week (!).
7. Microsofts patent is so new (filed 1998) it's laughable. There is VERY, VERY mucht prior art. Take Mac OS 8 (released 1997).

• RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses.

• Microsoft's claims, U.S. Patent No. 6,101,499
• Apple's claims, U.S. Patent Numbers 4,661,902 and 4,689,786
• Patent 6,101,499, filed April 8, 1998
• Patent 4,661,902, filed March 21, 1985
• Patent 6,101,499, filed March 21, 1985

1. Indeed, you are right that the patent is NOT AT ALL IPv6 related. So both PUBPAT, ZDNet and Slashdot are wrong here.
2. It is related to IPv4 link-local addresses. Indeed, the 169.254/16. address you mention. You're correct there. Now, please read RFC 3927 for all details.
3. As you can see in Appendix A of RFC 3927, these "IPv4 link-local addresses" where implement in Windows 98 and Mac OS 8. You missed the boat completely here.
4. This technology is NOT "owned" by MS as you claim.
5. However, both Microsoft AND Apple too(!) do claim IPR over this technology.
6. It is VERY interesting to note that both Apple's patents were submitted March 21, 1985, and have thus expired last week (!).
7. Microsofts patent is so new (filed 1998) it's laughable. There is VERY, VERY mucht prior art. Take Mac OS 8 (released 1997).

• RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses.

• Microsoft's claims, U.S. Patent No. 6,101,499
• Apple's claims, U.S. Patent Numbers 4,661,902 and 4,689,786
• Patent 6,101,499, filed April 8, 1998
• Patent 4,661,902, filed March 21, 1985
• Patent 6,101,499, filed March 21, 1985

1. Indeed, you are right that the patent is NOT AT ALL IPv6 related. So both PUBPAT, ZDNet and Slashdot are wrong here.
2. It is related to IPv4 link-local addresses. Indeed, the 169.254/16. address you mention. You're correct there. Now, please read RFC 3927 for all details.
3. As you can see in Appendix A of RFC 3927, these "IPv4 link-local addresses" where implement in Windows 98 and Mac OS 8. You missed the boat completely here.
4. This technology is NOT "owned" by MS as you claim.
5. However, both Microsoft AND Apple too(!) do claim IPR over this technology.
6. It is VERY interesting to note that both Apple's patents were submitted March 21, 1985, and have thus expired last week (!).
7. Microsofts patent is so new (filed 1998) it's laughable. There is VERY, VERY mucht prior art. Take Mac OS 8 (released 1997).

• RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses.

• Microsoft's claims, U.S. Patent No. 6,101,499
• Apple's claims, U.S. Patent Numbers 4,661,902 and 4,689,786
• Patent 6,101,499, filed April 8, 1998
• Patent 4,661,902, filed March 21, 1985
• Patent 6,101,499, filed March 21, 1985

Interestingly enough, Apple also claims IPR on IPv4 Link-Local addresses (which, _finally_ have been standardized this month in RFC 3927). However, those patents have been filed in March 1985, meaning that they just expired (If I understand correctly that patents expire 20 years after their filing).

http://www.ietf.org/ietf/IPR/apple-ipr-draft-ietf- zeroconf-ipv4-linklocal.txt

On ethernet it gets even better, since RFC 2464 (page 3) defines a way to derive a globally unique interface identifier from the MAC adress. The great thing about Ipv6, implicit in your post, is that multiple adresses on the same interface and in the same network works a lot better than with IPv4. That combined with the larger adressspace allows much more flexibility to put organisational and geographical structures into the routing topology (I seem to recall that the suggested prefix size for organisations/customers of ISPs is /48, leaving 16 bits of prefix to be used internally by that "user").

It took awhile to find it, but this turned up under IETF's IPR disclosures page: http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt

Reading the patent claims this doesn't look so much like IPv6 (and certainly not a fundemental part of IPv6 - it resembles IPv6 stateless address autoconfiguration, but only vaguely). What it looks like is IPv4 linklocal addressing, which has shipped in both MacOS and Windows for several years, and is a draft that is either just about to be approved or has already been approved as a standard. See draft-ietf-zeroconf-ipv4-linklocal-17.txt The really unfortunate thing is that linklocal addresses are quite useful on isolated networks, but are really harmful to applications unless they're turned off when a computer has a "real" address assigned by manual configuration or DHCP. And from a quick reading the patent would appear to apply to any implementation that turns off linklocal addresses under such conditions.

The present invention overcomes the limitations in the prior art by ascertaining the absence of a network IP address server, such as a DHCP server, automatically generating an IP address, testing the IP address to determine uniqueness, and periodically determining if an IP address server subsequently becomes available on the IP network. In this embodiment, the invention may be used in a network that has or does not have an IP address server. Furthermore, it will give priority to the IP address server whenever present so that the generated IP address is only used when necessary.

I read the article, which states some guy as claiming that the inventors withheld RFC's. Perhaps you can point out the RFC's which would be considered relavent prior art.

I checked here which seems to list RFC's pertaining to IPv6, but didn't see much which would be considered all that relevant to this patent.

This "exploit" isn't very interesting and the author really doesn't seem to have a good grasp of the HTTP protocol design, the end-to-end model, or the internet in general.

I'd be very careful before I blindly changed all my redirects to 301s. The semantics behind a 301 and 302 are VERY different and unless you want people to replace the original URI with the target in your 301s, forever, you might be entering a world of hurt.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

This is a common theme in the high-tech world; Joe Hacker figures out a problem and a 'solution'. Problem is, they don't understand all the implications of the solution. That doesn't stop them from yelling loudly about the solution. Without a comprehensive explanation of the impact of the 'solution' you might be just causing yourself harm in other areas down the road.

Education and thorough analysis are always a good idea when you are dealing with complex systems that might have emergent behaviors. This is certainly one of the bigger pet-peeves at the IETF and with the IESG.

This "exploit" isn't very interesting and the author really doesn't seem to have a good grasp of the HTTP protocol design, the end-to-end model, or the internet in general.

I'd be very careful before I blindly changed all my redirects to 301s. The semantics behind a 301 and 302 are VERY different and unless you want people to replace the original URI with the target in your 301s, forever, you might be entering a world of hurt.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

This is a common theme in the high-tech world; Joe Hacker figures out a problem and a 'solution'. Problem is, they don't understand all the implications of the solution. That doesn't stop them from yelling loudly about the solution. Without a comprehensive explanation of the impact of the 'solution' you might be just causing yourself harm in other areas down the road.

Education and thorough analysis are always a good idea when you are dealing with complex systems that might have emergent behaviors. This is certainly one of the bigger pet-peeves at the IETF and with the IESG.

This is nonsense.

Firstly, he is suing 8 years after the fact.
Why did he not sue the paper at the time he got fired by the UN.
Why did he wait for 8 years, move to another country, and then sue?

Secondly, if having access to an archive, in this case on-line, makes the publisher liable for libel lawsuits, then what is to stop people moving to other jurisdictions and suing a publisher over and over again, just because the archive tarnishes their reputation in their hew home town.

I agree that what the paper did was wrong, it initially cost the guy his job, but that was 8 years ago!

This does not really affect free speech directly.
You should be able to sue anyone for libel if you can prove being adversly affected by the lies made.

But it does affect freedom of information.
This will mean that anyone maintaining a publicly accessible archive of old articles will be liable for any lies said in those articles, even if they are later repudiated.

The judge needs to exert that Canadian common sense and realise that if a person looks in an archive and finds some information they should have the sense to check it's validity.
[Should I sue ietf for maintaining obsolescent RFC's?]

This decision is likely to make organisations, especially news organisation and caching services [like google et. al.], less likely to open up their archives.

Which is a bad thing(TM).

I just had to do some research to find out what "bulk data" meant. So for all you other network engineers, here's what I'm assuming this change brings...

By bulk data they're setting the packets DiffServ, I presume according to RFC 2597. I still use good old IP Precedence rather than DiffServ, but after seeing RFC 2597 I have to say Assured Forwarding looks like a great standard for setting up DiffServ. Cisco has a decent article on DiffServ and QoS which has a great table showing off Assured Forwarding's model for traffic control.

The recommended setting for Bulk Data is AF11. "Excess" bulk data, that is bulk data beyond whatever thresholds you've configured, is set to AF12 or AF13. So class 1 data (bulk and excess bulk) gets a certain share of bandwidth, with the excess bulk more likely to get dropped in the event of congestion.

By volunteering to mark BitTorrent traffic as AF11, there's always a chance that more sites that block BitTorrent will be more likely to just QoS it into a happy corner.

I'll let you networking folks do your own searches for more information. I've been fortunate in my current workplace that congestion is rarely an issue--since we've never had much network congestion (100 Meg to the desktop, Gig to the closet, Gig links to our remote sites, Gig Internet pipe, 4 Gig core backbone) QoS hasn't been a priority. But I'm happy to see where DiffServ is going.

Sadly, I recently had to shut down BitTorrent at our site because of a few jerks downloading movies. IRC, P2P, BitTorrent... when 99% of their use is illegal, many times it's the Legal department and not IT that decides the course of action.

It would be cooler for them to use NEMO (Network Mobility) which defines a system where nodes within the network are fixed with respect to a given router, and where it is the routers that are mobile.

(In a technical and physical sense, this is exactly what they have.)

In terms of coverage, the ideal would be for a consortium of rail providers to get together and construct a uniform system across all countries in Europe. This likely won't happen, unless the German experiment is a success, but if it did, it would define THE de-facto standard for such networks, globally, and not just for trains.

(Airlines have looked at wireless systems, but AFAIK there is no real standard defined, even if such systems have ever been built. Again, though, a Mobile IP system is stupid, as you're hardly going to jump out of one aircraft and land in another. At least, not unless you're a stuntman, and then you probably won't be concentrating on XTank or BZFlag enough to care if the network connection stays up.)

"When appropriate, we improve the kernel and share the changes with open source community"

Not too mentiun tcpmux (check your ientd.conf man page). DNS SVC records are a related idea.

ISOC Official Page
IETF Official Page
IESG Official Page
IRTF Official Page
IAB Official Page
RFC Editor Official Page
ICANN Official Page
IANA Official Page
W3C Official Page
W3C encyclopedia article
ICANN encyclopedia article
IANA encyclopedia article

ISOC Official Page
IETF Official Page
IESG Official Page
IRTF Official Page
IAB Official Page
RFC Editor Official Page
ICANN Official Page
IANA Official Page
W3C Official Page
W3C encyclopedia article
ICANN encyclopedia article
IANA encyclopedia article

• ISOC Official Page
• IETF Official Page
• IESG Official Page
• IRTF Official Page
• IAB Official Page
• RFC Editor Official Page
• ICANN Official Page
• IANA Official Page
• W3C Official Page
• W3C encyclopedia article
• ICANN encyclopedia article
• IANA encyclopedia article

• ISOC Official Page
• IETF Official Page
• IESG Official Page
• IRTF Official Page
• IAB Official Page
• RFC Editor Official Page
• ICANN Official Page
• IANA Official Page
• W3C Official Page
• W3C encyclopedia article
• ICANN encyclopedia article
• IANA encyclopedia article

ISOC Official Web Page

IETF Official Web Page

IESG Official Web Page

IRTF Official Web Page

IAB Official Web Page

RFC Editor Official Web Page

ICANN Official Web Page

IANA Official Web Page

W3C Official Web Page

W3C encyclopedia article

ICANN encyclopedia article and IANA encyclopedia article

ISOC Official Web Page

IETF Official Web Page

IESG Official Web Page

IRTF Official Web Page

IAB Official Web Page

RFC Editor Official Web Page

ICANN Official Web Page

IANA Official Web Page

W3C Official Web Page

W3C encyclopedia article

ICANN encyclopedia article and IANA encyclopedia article

ISOC Official Page IETF Official Page IESG Official Page IRTF Official Page IAB Official Page RFC Editor Official Page ICANN Official Page IANA Official Page W3C Official Page W3C encyclopedia article ICANN encyclopedia article IANA encyclopedia article

ISOC Official Page IETF Official Page IESG Official Page IRTF Official Page IAB Official Page RFC Editor Official Page ICANN Official Page IANA Official Page W3C Official Page W3C encyclopedia article ICANN encyclopedia article IANA encyclopedia article

It is off topic, but your message reminded me of the group of Linux enthusiasts in Bergen, Norway, who succesfilly sent a ping using Carrier Pigeon Internet Protocol.

Pity Wu went and broke it by whacking a minefield of patents around it. Now hardly anyone wants to touch it and those that are interested are scared off by the other sharks who are circling that pond. So another potentially interesting protocol becomes unusable for 20+ years because of simple greed.

Pity Wu went and broke it by whacking a minefield of patents around it. Now hardly anyone wants to touch it and those that are interested are scared off by the other sharks who are circling that pond. So another potentially interesting protocol becomes unusable for 20+ years because of simple greed.

(essentially, create the most convolunted network set-up you can NOT using Ethernet).

Can you say "Carrier Pigeons"?

I wonder what the OpenPGP response will be. The spec (http://www.ietf.org/rfc/rfc2440.txt; see section 9.4) doesn't describe these algorithms.

Point to point over carrier pigeon!