Slashdot Mirror

There's an IETF group working on IPv6 over Low Power devices: 6LowPan (with RFC4944 already released). From what I know they are using header compression and adaptation to the normal IPv6 header to be able to use it over 802.15.4 (this is the "entry" MAC protocol, future objective is to be transparent to lower layers). A routing protocol is also under development in coordination with 6LowPan, the Routing Over Low power and Lossy networks (roll).

Don't know the status of Contiki regarding this.

The Rules: (or DA RULZ)

http://www.isoc.org/internet/conduct/cerf-Aug-draft.shtml

http://www.dei.isep.ipp.pt/~acc/docs/arpa--1.html

http://www.ietf.org/rfc.html

http://rfc.net/rfc2430.html

Traffic Shaping Example:

http://rfc.net/rfc3514.html

The Rules: (or DA RULZ)

http://www.isoc.org/internet/conduct/cerf-Aug-draft.shtml

http://www.dei.isep.ipp.pt/~acc/docs/arpa--1.html

http://www.ietf.org/rfc.html

http://rfc.net/rfc2430.html

Traffic Shaping Example:

http://rfc.net/rfc3514.html

But, but .. is it compliant with sections 2.1 and 2.12 of RFC1925?

My guess was that a law against bullying was established before the interweb came along, and now instead of changing that law, they made a new one. I totally agree with you though, having a law specifically against electronic bullying makes no sense. One could just use CPIP to bypass that law.

1. invent method for routing data via carrier pigeon. Check
3. implement method.
2. use pigeons to route data past backbone hubs.
3. ????
4. profit.

Wrong RFC. That would be RFC4366,

The next step will be for the British government to mandate the evil bit.

Well then, screw them... I mean, if they aren't going to follow the stinking RFC standards about smilies and emoticons then why do we even want their standards-breaking butts here anyway?

Hmm, my ISP (Charter Communications, in the US) already hijacks DNS for unknown hosts.

Not only does this break the RFC2308 specification, but they attempt to make a bit of extra profit from it, by employing a malware/spam like search page.

I have been talking quite a bit with an economist who was in Rio all this week at the IGF. His take is more of watching what the economic situation will be when artificial, monopoly based, scarcity is introduced into the system. I can't wait to hear his take on the brazillian brawl this week.

Specifically, what happens to IPv4 address allocation when there is no longer any freely available netblocks. (Pay special attention to pages 27&29, and watch the accompanying video). New allocations will come from returned address pools, so a queuing system will have to be implemented at the RIR level. Starting up a new ISP, or expanding your customer base and need more address space after 2010, and your request will go into a FIFO queue.

Now, economists see two distinct futures for a market based on scarcity. One is where cooperation and fairness ensure that everyone gets along, which is the current internet model, and the other is known as the "University of Chicago School of Free Market Uber Alles^W^W^W^WEconomics" government enforced monopoly, where a few select companies are allowed to charge whatever the market will bear with no real competition or alternatives. Maybe a US government sanctioned company called IPbay will become the sole broker to trade netblocks.

In the first scenario, the internet continues to function as it does now, companies needing new addresses will have longer and longer waits and will have to adjust their business plans accordingly. Into a system like this, where address space could be traded, stolen, pirated or worse, RIRs have no real powers to stop it falling into total anarchy. Except, the IETB, IANA, the RIRs, have a new tool in their arsenal to combat anarchy, called DNSSEC.

In the second scenario, one, or a very few, private companies based in the US, of course, take over the entire market for buying and selling IPv4 address space. Want to keep that nice /16 you are using? It will cost you $BIGNUM/month in rental fees, or we give it to someone else. Those controlling companies will also use DNSSEC to control who has the right to announce a prefix.

For router engineers, those who work with BGP and AS numbers on a regular basis, things have been pretty quiet until now. A few bogon filters, and you just generally believe whatever gets fed to you. The internet is mostly "best effort" and if some traffic doesn't reach it's goal, there isn't much that can be done beyond some simple tuning. There is some routing data in the routing registries, but it's rarely up to date and the accuracy depends on whatever random person did the update.

But in a few years, when companies start to get desperate for IPv4 address space NOW!, and can't wait for a proper allocation, they'll steal or buy a prefix. Companies with a large allocation not completely used will renumber internally, and sell the right to announce half their prefix to they highest bidder. Or companies will just find part of an unused block and announce it. Total anarchy! The most conservative estimates for 2012 with rampant de-aggregation and without DNSSEC is that the routing table will exceed 2,000,000 prefixes. Not much routing equipment out there today will be able to cope with that.

With DNSSEC, there will be cryptographically signed certificates [pdf warning]for every allocation from an RIR[quicktime warning]. When you build your routing table in BGP, you will verify every prefix for origin and valid neighbors based on certificates stored in the RIR whois/routing registry. This will prevent the anarchy part of stealing a prefix and announcing it in the wrong AS. This wil

One for the pirates and one for legitimate users. That would work. ;)

Actually, RFC 3514 implements this without having to create a new protocol.

These screwballs tried to hack a POCSAG pager to dump data to the AT&T Safari laptop in the late eighties or early nineties. When they failed to accomplish anything useful (because they were incompetent) AT&T went with the SkyTel Link, which was a superior pre-existing product which actually worked.

Wireless networking carrying all network traffic was developed at the University of Hawaii and was a precursor of the ARPA internet with the transport layer being the "ether". Other wireless ARPA subnets (PRNET and SATNET) were integrated into the internet on August 27, 1976, with a message originating in a mobile station connected via packet radio ot the landline ARPANET.

Information about the mobile network station originating that message has been preserved here. The first inter-network spanning message was, of course, an e-mail.

The various packet and satnet Class A domains are defined back to at least RFC790 issued in 1981, The infamous TCP:99 "metagram relay" port doesn't seem to appear until RFC820 in 1986,

Also of interest is Vint Cerf's RFC773 of October 1980.

http://rfc.net/rfc0773.html



Now GET OFF MY LAWN, ya snotty little whippersnappers.

This sounds a whole lot like RFC #3514 to me, except on a higher level, which makes the idea at least four years old.

This is nonsense.

The technical solution already exists today, it already works in both Firefox and IE and some other applications, and it is already used in i.e. the .nu and .se domains. It's up to each TLD to decide what profile of domain names they accept, and no modifications of the DNS protocol is needed.

The ICANN has nothing to do with this. Move along.

Apparently P2P apps implement some of this, and RFC3514 has covered some more since early 2003. I would just love it if that RFC torpedoed a patent like this.

Heh, how about that - I always thought 'carrier' grade refered to RFC 1149

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.

the proposed .tel TLD would allow individuals and companies to keep all of their contact information in an easily accessible location.

Wow! If only someone had thought of that before!

See http://rfc.net/rfc1123.html

I'm so tired of (ab)use of abbreviation 'IP' to denote something nonexistant.

There is only one true IP and it is STD5. Period. Discussion closed.

I think you are referring to multi-casting and that is available in IPv4. See RFC 2365 if you're curious.

RFC 1149: IP Datagrams on Avian Carriers

http://rfc.net/rfc1149.html

(If the link doesn't appear to work, please wait patiently for the pigeon to arrive. Thank you.)

When talking about network traffic a byte is eight bits. The router and statistics counter doesn't give a damn that you're using hardware with 7 bit bytes.

Pick a random IP related RFC and implement it using 7 bits wherever it says byte, see how well that works. Heck even RFC791 slips up and uses byte instead of octet once.

They'll be able to spot them if their eyes glow red.

I'm all for this, quite frankly we should rebuild TCP/IP with an easily-managed layer of security. RFC1149 provides an excellent example of an easily secured network, all the MPAA would needs is a suitably-qualified group of packet "hunters" to dispose of unwanted traffic.

-Matt

They must be using ICMP type 12 (from RFC792) which shows the original header + first 64 bits (8 bytes) of data from each packet. Interesting leak, but very small amount of data. http://rfc.net/rfc792.html

You need to update your firewall to support RFC3514. http://rfc.net/rfc3514.html

All will bow down before S. Shenker and J. Wroclawski.

3514 it!

Actually, this is a well documented issue if the display uses IPv4. (Scroll down to item #3).

That's easy. Check the evil bit. Discard all packets that have it set.

The .exe bit kind of gives it away.

"Sorry but MIT, Apple, etc, as much as I respect their contributions to the human race, do not need a Class A. Allow for the redistribution of the IPs and we should be good to go for quite some time."

I didn't realise these guys were sitting on so many damn IPs. At least they are probably using a chunk of them. I can't imagine what El Lilly and dastardly megacorp Halliburton are doing with a class As.

I've heard of the evil bit before but not the evil network...

You'd think the DNS root servers, Akamai, and the like would be filtering them, too.

Check out RFC3514 for more information about the "Evil Bit", which is a portion of the IP header used by the computers and servers of cyber-terrorists.

Just tie some red LEDs to the RFC 3514 dataline.

-

We already have an RFC for the security flag in the IPv4 header (AKA "Evil Bit").

There is a 1994 RFC here: http://rfc.net/rfc1606.html. Everything else Google came up with was in Chinese and, thus, just as unusable!

I'm not quite fond of AOL's patent on "evil points" either.

You mean AOL hold a patent on the evil bit? But then it's no wonder that virus and worm epidemies are that rampant, no worm author will set the evil bit if he knows AOL might sue him for patent infringement!

RFC3514

Easy by monitoring for traffic with the evil bit set which will either be originating from hell or going there :)

Generally, anything listed in STD 1 is considered fairly important. The lowest RFC numbers I see there are 768 (UDP), 791 (IP), 792 (ICMP), and 793 (TCP), all of which are quite thoroughly important, fundamental to the internet. 821 and 822 are vital for email. Some of the RFCs not listed in STD 1 do have some importance, however, and it's possible that there's an important low-numbered one I'm missing.

Hmm. I know that TCP over avian carriers is old news.
What's the next free RFC number? I'd like to propose TCP over mail runners.

Not sure what you were looking for specifically, but the user:pass@host scheme is defined in RFC 1738.

And, no, they're not breaking the spec. It's optional:

Some or all of the parts ":@", ":", ":", and "/" may be excluded.

They're just being dumb. As usual.

DNS, however, is pretty centralized.

Despite whatever misinformation VeriSign is blowing, DNS is realatively decentralized. The A-root is no more important than B, C, D, E, or F.

Not only is VeriSign becoming more and more adept at using the media to create the image that they own the internet, it seems that more and more tech writers have never cracked an RFC, or seem to know where to look this shit up.

(BTW, that would be here. Or in your/usr/share/doc/RFC if you're running Debian and have installed the apprpriate doc-rfc packages.)

rfc2014 The IRTF focuses on longer term research issues related to the Internet while the parallel organization, the Internet Engineering Task Force (IETF), focuses on the shorter term issues of engineering and standards making.

It'll be interesting to see what short-term solutions to spam they can come up with.

Even with syn cookies and the various types of protections shut off, FreeBSD and Linux are many, many times more robust in handling bad traffic.

Must be that RFC 3514 compliance. (Sorry, couldn't resist. :)

There is a standard, it's detailed in RFC 1459. The trouble is AOL and ICQ spent so much time to instill upon people that ICQ or AIM == online chatting.

When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds.