Slashdot Mirror

The RFC you mention is 2142 http://tools.ietf.org/html/rfc2142.

Another one which is worth mentioning here is the much more recent RFC 5965 http://tools.ietf.org/html/rfc5965 which describes a format for email reports which could both be human- or machine-read. This could help speed up the processing of the complaints, and cluster those about the same address.

However, the big problem would be to get operators to actually use these formats, cooperate, or recognise an external auditing entity.

The RFC you mention is 2142 http://tools.ietf.org/html/rfc2142.

Another one which is worth mentioning here is the much more recent RFC 5965 http://tools.ietf.org/html/rfc5965 which describes a format for email reports which could both be human- or machine-read. This could help speed up the processing of the complaints, and cluster those about the same address.

However, the big problem would be to get operators to actually use these formats, cooperate, or recognise an external auditing entity.

Here is the rfc in question: http://tools.ietf.org/html/rfc5321

It requires the server to accept mail for postmaster, it does not require it to deliver it to anyone.

Simplest way to bridge networks would be to use IP Encapsulation within IP.
You know, that little field where the IP stack says wether the payload is an ICPM, UDP or a TCP packet? Set it to 4 and put the packet you want to bridge over to the other network in the payload.
RFC2003

How do donkeys compare to pigeons?

NAT-PT was officially deprecated the last I looked (see: http://www.ietf.org/rfc/rfc4966.txt ), but I would be interested in a list of products that support it as I have a few IPv4 clients that will NEVER see a native IPv6 stack written for them.

That is the old internet 4. You want the new and better internet 6: http://tools.ietf.org/html/rfc4193

Can I get "an Internet"?

RFC 1918 explains how to set up your own internet.

None of these solutions are particular desirable.

Sorry to answer my own post again, but the first page I found was a bit outdated. It turns out the problem was addressed in RFC 5155, which introduced NSEC3 records that chains hashed values of the domains rather than the domains themselves. It also involves salting to counter dictionary attacks. You can still estimate the size of a zone by requesting a bunch of random subdomains and see what the distance between the hashes are, but at least you cannot find out what the exact subdomains are, and the solution is much simpler than one which would hide the size of the zone. If you consider the exact size to be secret, you can always add more hashes to make the zone look bigger than it is.

It will even get you free internet if you use RFC 1149.

Why yes! Ingenious!

Most importantly we already have the (theoretical) framework in place - RFC 3514 - it only needs minor extension with "PLZ_ANON" bit .

And IRCwas a two-way messaging protocol that started out as a replacement for NTALK, a network-based variant of TALK(1)+FINGER. An IRC system is constructed by a peer-to-peer network consisting of a number of IRC Servers, configured into a tree-based topology designed by the server administrators, and stemming from their choice of which peers to connect together.

IRC clients even had a /NOTIFY command for monitoring presence (or WATCH list) command. Clients had usermodes they could set on themselves such as /mode yournickname +i (Invisible)

There was a concept of switching channels with a JOIN CHANNELNUMBER command, with the default channel being 0, later an ability to subscribe to any number of channels using a JOIN #CHANNELNAME command.

Knowledge packets were transmitted to a channel in the IRC protocol using the IRC PRIVMSG command; abbreviated in most IRC clients to /msg, or simply typing theknowledge packet into a dedicated window for the channel and using 'enter' to transmit.

Knowledge packets (command buffers) were limited to 512 bytes per message.

Users connecting to IRC subscribe under a certain nickname, their client transmits a USER and NICK command to select the nickname to subscribe as. Users could publish private messages to other online users using the PRIVMSG command with the recipient's nickname as the destination. e.g. /msg NICKNAME (message here)

In addition to simple private messages, there was a concept of publish NOTICE using a /notice NICKNAME or /notice CHANNEL name command, and channels had a topic configurable with a /TOPIC command, and channel permissions configurable using a /MODE command.

Channel ownership was granted to the first subscriber to the channel. In the late 1990s IRC developers introduced IRC networks with bolted on registration services for persistence storage of nickname and channel name ownership and permission control.

It became a rich protocol with almost every capability of modern IM clients. Though some limitations, and many capabilities modern IM clients still don't have.

Stuart Cheshire, the Apple guy behind the mDNS and DNS-SD (a.k.a. Bonjour) Internet-Drafts, is currently involved in the Port Control Protocol (PCP) Internet Draft: http://tools.ietf.org/html/draft-ietf-pcp-base-13.

“The Port Control Protocol allows an IPv6 or IPv4 host to control how
      incoming IPv6 or IPv4 packets are translated and forwarded by a
      network address translator (NAT) or simple firewall, and also allows
      a host to optimize its outgoing NAT keepalive messages.”

Some people seem to live in la-la-land.

That's certainly been true of the IETF for NAT (specifically, they're in "la-la-la-I'm-not-listening-la-la-la land"), but also for IPv6.

Some of their suggestions are totally brain-dead. E.g. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-09

This is now RFC 6092, but your comments are still valid. It's a pretty scary read, things like:

By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound SYN packet

because, you know, port-scanners have to be given a chance too. There's a bunch of other longing-for-the-good-old-days 1980s hippie-isms in there as well, the only thing missing is a requirement that we all hold hands and sing kumbaya:

Someone's SYN-flooding lord, kum-ba-ya, ...

Some people seem to live in la-la-land.

That's certainly been true of the IETF for NAT (specifically, they're in "la-la-la-I'm-not-listening-la-la-la land"), but also for IPv6.

Some of their suggestions are totally brain-dead. E.g. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-09

This is now RFC 6092, but your comments are still valid. It's a pretty scary read, things like:

By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound SYN packet

because, you know, port-scanners have to be given a chance too. There's a bunch of other longing-for-the-good-old-days 1980s hippie-isms in there as well, the only thing missing is a requirement that we all hold hands and sing kumbaya:

Someone's SYN-flooding lord, kum-ba-ya, ...

That's last year's similar effort. This article's talking about the new WG proposal under the same name, described at http://www.ietf.org/mail-archive/web/homegate/current/msg00821.html

Some people seem to live in la-la-land. I don't care about the difference between SPI and NAT, but some people do, all in the interest of "end-to-end connectivity". Some of their suggestions are totally brain-dead. E.g. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-09
> In managed, enterprise networks, virtual private networking tunnels
> are typically regarded as an additional attack surface. and they are
> often restricted or prohibited from traversing firewalls for that
> reason. However, it would be inappropriate to restrict virtual
> private networking tunnels by default in unmanaged, residential
> network usage scenarios.

Hello?!?! WTF should my home network be any less secure than a network at an office???

> Therefore, this document recommends the DEFAULT operating
> mode for residential IPv6 simple security is to permit all virtual
> private networking tunnel protocols to pass through the stateful
> filtering function. These include IPsec transport and tunnel modes
> as well as other IP-in-IP protocols.

WTF?!?! So when some manufacturer makes a bunch of fridges or toasters or washer/dryers that respond to default UserIDs and passwords over a VPN, they'll accessable to the outside world *BY DEFAULT*.

It gets worse. http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security-01 says...

>The intention is to provide an example of a security model which allows most traffic,
> including incoming unsolicited packets and connections, to traverse the CPE...

Ex-bleeping-scuse me. This SPI "security" is a joke. You'll pry NAT out of my cold dead fingers.

> ...unless the CPE identifies the traffic as potentially harmful based on
> a set of signatures (and other correlation data and heuristics)

IDIOTS!!! One of the basic rules of internet security is to enumerate good, *NOT* to enumerate evil. There are new exploits being created all the time. You simply can't keep up with a list of exploits. You're a lot better off deciding what minimal stuff to allow through.

> that are kept up to date on a regular basis.

Oh boy. My ISP's router/modem will come with a 90-day trial subscription to Macafee/Norton/whatever. And when I'm watching a movie on Netflix, or whatever, I'll get get a popup warning me that the free anti-virus subscription expires tomorrow and that I *MUST SIGN UP NOW*. And the router/modem will have a quad-core processor, but still be dog slow, because it'll be continuous ly scanning packets, and looking through a list of a gazillion exploits. And just like craplets on new PCs, it'll be almost impossible to uninstall. Like I said, you'll pry NAT out of my cold dead fingers.

I haven't been a NAT fanboi, but if the internet hippies at IETF get their way, NAT will indeed be the safest way to go.

Some people seem to live in la-la-land. I don't care about the difference between SPI and NAT, but some people do, all in the interest of "end-to-end connectivity". Some of their suggestions are totally brain-dead. E.g. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-09
> In managed, enterprise networks, virtual private networking tunnels
> are typically regarded as an additional attack surface. and they are
> often restricted or prohibited from traversing firewalls for that
> reason. However, it would be inappropriate to restrict virtual
> private networking tunnels by default in unmanaged, residential
> network usage scenarios.

Hello?!?! WTF should my home network be any less secure than a network at an office???

> Therefore, this document recommends the DEFAULT operating
> mode for residential IPv6 simple security is to permit all virtual
> private networking tunnel protocols to pass through the stateful
> filtering function. These include IPsec transport and tunnel modes
> as well as other IP-in-IP protocols.

WTF?!?! So when some manufacturer makes a bunch of fridges or toasters or washer/dryers that respond to default UserIDs and passwords over a VPN, they'll accessable to the outside world *BY DEFAULT*.

It gets worse. http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security-01 says...

>The intention is to provide an example of a security model which allows most traffic,
> including incoming unsolicited packets and connections, to traverse the CPE...

Ex-bleeping-scuse me. This SPI "security" is a joke. You'll pry NAT out of my cold dead fingers.

> ...unless the CPE identifies the traffic as potentially harmful based on
> a set of signatures (and other correlation data and heuristics)

IDIOTS!!! One of the basic rules of internet security is to enumerate good, *NOT* to enumerate evil. There are new exploits being created all the time. You simply can't keep up with a list of exploits. You're a lot better off deciding what minimal stuff to allow through.

> that are kept up to date on a regular basis.

Oh boy. My ISP's router/modem will come with a 90-day trial subscription to Macafee/Norton/whatever. And when I'm watching a movie on Netflix, or whatever, I'll get get a popup warning me that the free anti-virus subscription expires tomorrow and that I *MUST SIGN UP NOW*. And the router/modem will have a quad-core processor, but still be dog slow, because it'll be continuous ly scanning packets, and looking through a list of a gazillion exploits. And just like craplets on new PCs, it'll be almost impossible to uninstall. Like I said, you'll pry NAT out of my cold dead fingers.

I haven't been a NAT fanboi, but if the internet hippies at IETF get their way, NAT will indeed be the safest way to go.

http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security-01 has some interesting ideas. At least it is a starting point - we don't want to end up with the same situation as for IPv4 where everything has to be piggybacked on inside-initiated HTTP connections.

The idea is to come up with a standard for what home routers for IPv6 ought to look like. We'd like to preserve end-to-end transparency, which current home routers break, but at the same time we'd like to avoid creating serious security risks for people who are accustomed to the current home router security model. Support for things like DNSSEC and multihoming are also on the proposed charter.

Home Networking working group description is here.

Indeed. CALEA, as applied to digital communications, came into force in May 2007. At that point, all US network providers were required to file a report of comprehensive intercept capability or face a $10,000/day fine from the FCC. For this to be achievable, network devices with this capability had to be widely available well ahead of the deadline, and indeed they were. That in itself looks like prior art to me.

You'll notice that RFC 3924 has a section dedicated to VOIP. It was published in October 2004. You'll also notice that while this RFC discusses decryption of intercepted traffic, there is not even a mention in the Microsoft patent.

When color came along, the vertical sync frequency shifted ever so slightly, to 59.97Hz (and the horizontal shifted from 15.75 kHz to 15.734 kHz). These frequencies prevented interference issues with the newly added color components of the transmitted signal, while still being within the working range of the existing B/W sets, allowing older sets to receive color programs in B/W.

[pedantic] You're wrong.

The frequency was shifted to about 59.940052328623757195185766614338Hz.

Not a nice round number, but analog electronics don't care about numbers, nor their shape.

Reference.
[/pedantic]

More than 10 years ago I proposed that a TLD be officially reserved for _standard_ local private use. Basically something similar to RFC1918 but for TLDs.

I proposed it to the ICANN (emailed to icann@icann.org, Esther Dyson and Vint Cerf) and later the IETF: http://tools.ietf.org/html/draft-yeoh-tldhere-01

No luck, and I'm not rich enough to buy it (and give it to the world). Maybe Google can?

Already exists: use .local

More than 10 years ago I proposed that a TLD be officially reserved for _standard_ local private use. Basically something similar to RFC1918 but for TLDs.

I proposed it to the ICANN (emailed to icann@icann.org, Esther Dyson and Vint Cerf) and later the IETF: http://tools.ietf.org/html/draft-yeoh-tldhere-01

No luck, and I'm not rich enough to buy it (and give it to the world). Maybe Google can?

I mentioned Qualys' SSL Labs nice test utility in another comment.

The fix is to ask your vendor for a patch for CVE-2009-3555 which implements RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. Responsible vendors will have implemented support for RFC 5746 by now so you may already be patched.

I completely agree. It needs to be fixed not dumped. This reminds me of WebSockets Experiment comparing Upgrade and CONNECT handshakes. Microsoft didn't say they wanted websockets abandoned. If there isn't OpenGL support in other browsers HTML5 canvas will be better in IE than any other browser. In other words, convincing everyone OpenGL support is evil and scary when IE gets HTML5 canvas support it would put them in the front of graphically rich web interfaces.

Exactly. After all, Bin Laden was using a hardened variant of IPoAC, the transmission method most resilient to wire tapping. His implementation further reduced attack vectors by 50% (namely, bread crumbs baiting), leaving his communications vulnerable only to the (curiously old) "shoot the carrier" approaches.

Fine, so please tell me how would a home Linux/Windows 7/OS X machine get its DNS settings from the ISP? Or are you claiming that getting stuff like DNS configured is an "odd corner case" that only a few users would ever need?

OK you might say use router advertisements instead of dhcpv6, but those would be even newer and thus support my point about bugs even more (they're probably still writing the RFCs - some are dated Nov 2010 e.g. http://tools.ietf.org/html/rfc6106 ). You going to bet that the implementations won't be full of bugs?

And are there even Windows/OSX/Linux clients that handle those router advertisements? Are they stable and secure? Are there already carrier grade routers that would support them? Nov 2010 isn't that long ago.

So how is IPv6 cheaper and more scalable than IPv4 as the OP claimed?

Currently with IPv4, "good case scenario" - home user plugs laptop to device from the ISP (or selects the device's SSID), and stuff works - DNS, gateways, netmasks, addresses all get set up automatically. Ask yourself what happens with an IPv6-only "good case" scenario? Is all the tech there already?

If it isn't, then all the talk about "the world had 10 years to move" is bullshit.

That's like saying you had 10 years to move in to a house when they were still discussing part of the foundation's design in Nov 2010. Just because they successfully tested the mock up rooms and doors at their own test sites doesn't mean much.

Getting people to move from nothing to a shack is easy. But when they have a house that mostly works and is just a bit short of space, it is stupid to expect them to move to a building with lots of space but not ready.

Nope - there are two pressing problems with IPv4: Address exhaustion and routing table explosion. IPv6 fixes one of them and helps with the other

Nope. If IPv6 is a good answer to address space limitations, why are we not already using it?

if there was a solution to multihoming that was neater than SHIM6 and didn't require BGP then it would have completely fixed the routing table growth, but you can't have everything.

I did mention location and host id splitting -- you may not agree but do keep up ;)

This is a standards effort coordinated between the IETF and W3C; see:
    http://datatracker.ietf.org/wg/rtcweb/charter/
    http://www.w3.org/2010/12/webrtc-charter.html

While Google is certainly involved, it's a lot more than them, with folks from many companies (including Skype, at least pre-MSFT) participating; see:
    http://rtc-web.alvestrand.com/home/participants

I wonder what exactly they are trying to achieve by this experiment

The purpose of the experiment is to see what problems actually appear.

If there is a fallback to IPv4 then it there be just a delay.

I expect Google know this - they recently implemented happy eyeballs in Chrome, and I believe similar functionality is also in Safari.

How will Google know about any of that?

See IPv6 in Google - A Case Study (PDF) for an idea as to what Google are already measuring, and how.

If you only get link-local addresses, you're not fully set up. You need to either use an RFC3068 anycast tunneling, or set up an explicit tunnel.

Assuming you go the anycast route (since that's what Comcast being ready for IPv6 would imply), once your router is configured properly your systems should autoconfigure themselves with globally routable IPv6 addresses starting with 2002.

It's a URL using the "data" scheme, not a script.

Collections of active IP addresses will be readily available tomorrow, just as rainbow tables and collections of active email addresses are today.

That depends. I suggest reading RFC 5157.

Machines that serve up public services (web servers, FTP, or anything that appears in a public DNS record) will still be heavily attacked. But machines configured via DHCP (where the assigned addresses are not sequential) or which are using the privacy addresses will be harder to find through guessing.

And in the case of the privacy addresses, those are typically only good for a few days. So the collected address list will not be much good for those end-users machines.

Would worms like Sasser have gotten as far if the search space was 1/1000th as sparse as it currently is? What if we could move that even two more orders of magnitude to only 1 in 100,000 addresses having active machines on the local network? Contrast that to probably at least a 30-50% utilization on current IPv4 networks.

There are several mechanisms. The standard for the format of an email message is an "rfc". There is the ISO. There are standards such as that for PDF files, published by Adobe. If there is a standard for a GUI, I'd be interested to learn about it.

What keeps me from doing IPv6 tunneling is an utter lack of clarity on the migration path from there. When my ISP finally does give me a 16-bit subnet in the v6 address space, I expect that I will have to go through all of that configuration again from the start and also end up spending days debugging the tiny bits of the tunneling configuration and software that didn't come out cleanly.

RFC 3068 is ten years old, so assuming your router is not more than ten years obsolete setting up IPv6 should be practically automatic.

I enabled tunneling by clicking a button then selecting two drop-downs to pick 6to4 (RFC 3068) tunneling. When my ISP starts offering native IPv6, I'll deselect tunneling.

If it's more complicated than that, you ought to be asking yourself why you're using such awful router software.

There also isn't DHCP with IPv6, hence the sarcastic comment...

Yes there is, defined as RFC 3315. Do your homework next time.

Now RFC1149 for 'IP over avian carriers' needs an addendum. IETF go!

I disagree. We should all get on board with a ready backup plan based on RFC4838. Every town should have an implementation of Delay-tolerant Networking, just in case...

NASA has already began testing an implementation of RFC1149 for use in space.

Our local DTN could use shortwave radio, and/or CB with repeaters, etc.

Alas, I fear we will only begin to build the network after it is needed... On a related note: I want the right to bear technology lumped in with the right to bear arms if my strong encryption system is going to be considered munitions.

Now RFC1149 for 'IP over avian carriers' needs an addendum. IETF go!

I disagree. We should all get on board with a ready backup plan based on RFC4838. Every town should have an implementation of Delay-tolerant Networking, just in case...

NASA has already began testing an implementation of RFC1149 for use in space.

Our local DTN could use shortwave radio, and/or CB with repeaters, etc.

Alas, I fear we will only begin to build the network after it is needed... On a related note: I want the right to bear technology lumped in with the right to bear arms if my strong encryption system is going to be considered munitions.

Now RFC1149 for 'IP over avian carriers' needs an addendum. IETF go!

The term "internet" to describe global network using tcp/ip as protocol was coined in very famous RFC done in 1974. I suggest shooting yourself in the butt with a valium dart, it would be uncommon but not unheard of to speak of the ARPANET.

http://tools.ietf.org/html/rfc675

The term was from 1974, but ARPANET or NSFNET (expansion of arpanet to universities) would have been term widely used or recognized in 1985 by users. http://tools.ietf.org/html/rfc675

If I were the movie music industry I'd be supporting the transition to IP v6, as it reduces the ambiguity.

It doesn't have to, and nothing prevents you from manually assigning your own made-up IPv6 address to hosts on your network. I have a lot of FreeBSD machines, each running a lot of jails. The main interface gets its address from autoconfig but each of the aliases for the virtual machines comes from piping /dev/random into md5sum and inserting a colon after every 4 nibbles.

For that matter, there's nothing stopping you from putting an address-randomizing NAT on your gateway so that outgoing connections seem to come from a random distribution of your home /64 block. What subset of those 18*10^18 fictional hosts corresponded to your laptop at 2:43 AM yesterday morning?

Only 256 per house? That sounds like a tiny amount. According to RFC6177 the current recommendation is that each house should be given more than a single /64 subnet so they can establish different subnets. A /48 used to be the recommended size, but /56 is being considered. Even if you get only a single /64 subnet for your house, that loney subnet still contains as many IP addresses as the entire ipv4 address space squared. The extra subnets are only really for practical routing reasons.

Rendesvous/Bonjour

that was the IETF

Apple went to the music labels

more like Apple directed a music label

and then tried to drop DRM when it was limiting growth.

Apple isn't a replacement for Microsoft, Canonical isn't a replacement for Apple, and Microsoft isn't a replacement for anything. They're all software application companies with some overlap but singular overall.

First of all WebM is no standard, what standardizations committee governs it.

I didn't say it was a standard that came out of a standards body. Not all standards do.

IP networking was first documented in 1974. Over the next few years it came into wide use as a standard, and computers and equipment using IP networking were able to talk to each other. But it wasn't formally standardized until 1981. By your definition of a standard, IP networking wasn't "a standard" until 1981, right? Yet curiously, it still worked before 1981.

Between 1974 and 1981, IP networking was a de facto standard. Perhaps in your mind that isn't any kind of standard at all, but I assure you that computers were able to talk to each other.

Likewise, I can watch a WebM video in my web browser, and neither the video nor the web browser care whether or not a formal standards body wrote a bunch of documents describing the format.

It is a legitimate complaint to say that WebM needs better specification documents, or more specifically, VP8 needs better specs. (I believe that both the Matroska container format and the Vorbis audio coder are well-documented.) Right now, the standard for VP8 is basically "if the VP8 decoder can decode it, it's legal VP8, and by the way here is the code for the VP8 decoder".

But to say that the specification documents need to be improved is not the same thing as saying that WebM isn't any kind of a standard. As I said, my web browser plays WebM videos just fine. If I download them, my media player plays them just fine too.

A standard doesn't need to be from a formal standards body to be useful. It doesn't even need to have a good specification document. It just needs to work well, and WebM works well as a standard.

steveha

Some streaming protocols, like HTTP live streaming, can work well with common techniques like content delivery networks and transparent caching to allow content distributors or ISPs to reduce network load by moving popular content closer to the endpoints.

It's weird that we haven't seen a gpg encryption option for TLS yet though, there's no technical difficulty I can see.

Actually there is support for using gpg keys for TLS key exchange, see RFC 6091 for reference. It is supported by GnuTLS and described on their website, but not in widespread use as far as I know.

Here, I'll do a better job of inventing the next Internet protocol. IPv5

You can't, it already exists. See http://www.apps.ietf.org/rfc/rfc1819.html

48 bit addresses (add two bytes to the left of existing IPv4 addresses, otherwise use precisely the same packet header, four whole bytes longer, six if somebody wants to add more checksumming or the like while we're at it).

Doesn't work with my existing 2wire home router nor does it even work with a router running IOS. I had the unique advantage of testing various compatibility tricks with ipv4 when I was writing my own TCP/IP stack for AROS. Since it requires a software update with the routers, may as well go IPv6 instead, specification was first released in 1998 and has a much broader widespread support already. Phones support it, every PC OS in the last ten years appears to support it. It's just network providers that need to sufficiently upgrade their infrastructure.

Given NAT, it is actually very unlikely that we will really need more than two extra bytes

I have been behind double NATing already. No.

I believe it's enabled by default on Windows. On Linux, you enable it by putting

net.ipv6.conf.all.use_tempaddr=2

in your /etc/sysctl.conf