Slashdot Mirror

RFC 3514 was meant as a joke. This time it looks like people are discussing it for real. Let's go ahead and add a "Captain Justice" HTTP header that would command all the bad guys to immediately stop being evil.

You're right, and I omitted that consideration from my post. (You're misunderstanding the allocations though -- APNIC have 2001:0400::/23, which is 2001:0400:0000:: through to 2001:05ff:ffff::. They also have 2400::/12, which is 2400:0000:0000:: though to 240f:ffff:ffff::. Also, if you look at the list of allocations, they've obviously been left the whole of 2400:0000:0000: up until 25ff:ffff:ffff:: to expand into. Even the smaller /23 block has room for more than 65,536 corporations, let alone the /7 reserved block.)

The allocations are being done sparsely like this in the interest of route aggregation. The idea is to issue an ISP a /32, for example, but then skip the next 7 /32s. This means that the ISP can expand right up to a /29 while continuing to take up only a single routing table entry. If you want to put a negative spin on it, you could claim that this is only "12.5% efficient", or that it "wastes 87.5% of addresses", but this is not true: the gaps are being used to minimize routing table fragmentation.

How does this affect my assessment? RFC 3194 is required reading here. It defines the "H-density ratio", as a means of measuring how painful address allocation is becoming in a network with a hierarchical structure. Even if we take the low-end 80% used in that RFC, that would still be 70 billion /48s, or 10 per person on the planet. It's reasonable to expect some people to admin more than 10 networks and thus need more than 10 /48s, but I feel that it's unreasonable to expect that to be true of every single person on the planet.

For comparison, it looks like IPv4 passed its HD ratio of 80% (51 M hosts) in about 2000 or so. Clearly a network can continue operating beyond 80% if necessary; it just means that you have to start sacrificing route aggregation for a higher allocation percentage.

(Once again, I did these calculations for the 45-bit space in 2000::/3. The "we can start over in one of the other five /3s" argument is just as valid here too.)

Can you think of any reason they can't implement exactly the same limits with IPv6 that they currently have with IPv4?

ISPs will give you an address block, not just one address. IPv4/32 --> IPv6/56 (most likely). What you won't get is a /128. And as for why? Well...

• a whole lot of RFCs, including http://tools.ietf.org/html/rfc4941, which is turned on by default in Windows.
• Also, economically, you can only charge a premium for a scarce resource if it is indeed scarce. IPv6 addresses are not a scarce resource.
• Handing out a single IPv4 address only works in practice because customers can use IPv4 NAT (NAT44). IPv6 NAT (NAT66) does not exist.
• Residential gateways (cf standard TR-124 of Oct 2010) as now being built assume an address block, not a single address.
• It would cost the ISPs more to do this than to do the sane, obvious and standards compliant thing, for no likelihood of extra revenue

That's theory...what about practice?

If you hang out on the IETF v6ops list, which representatives of all the world's major ISPs do, you will see that none of them have any intention of offering customers a single /128.

http://www6.ietf.org/rfc/rfc3315.txt

Autoconf currently doesn't assign a prefix delegation.

There is SEND: http://tools.ietf.org/html/rfc3971

But only the implementations are Cisco, Linux and BSD. So not an option in practice.

It wasn't at all clear to me from your question what you expected .here to be for... your comparison to E911 made me think you were talking about regional resources, i.e. stuff within tens of miles, and it was really unclear to me how that would be useful, much less how it could be defined or implemented. But the analogy with RFC 1918 makes it much clearer... you're talking about subnet-local resources.

That's really easy to build on top of IPv6, and you don't need a new .TLD to do it. Just define some canonical link local addresses. For example this draft RFC suggests defining fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 and fec0:000:0000:ffff::3 as canonical local DNS servers. I think the current plans are to handle local DNS differently, with local multicast addresses, but you get the idea. With such a large address space it's easy to carve out bits of it that have specific canonical purposes. So there could be a fixed address for any sort of defined local resources, e.g. print servers. In addition, it would be a simple matter to pick an address for a "local resource registry". Hosts that provide specific services could contact this address to register their services and hosts that desire specific services could contact it to get a list of what's available.

For identifying nearby hosts with names, the .local TLD already exists. Given a canonical way for hosts to reach a local DNS server, they should automatically register themselves whenever they join a network, so <yourhostname>.local can always be used to reach your machine. If in addition to that hosts registered their willingness to be advertised through a local resource registry it would be easy to discover the existence of a host and then resolve it through DNS. Many sites would probably configure their DNS resolvers to use ".local" as a default domain so in practice you'd really only need to type the hostname.

IPv6 opens up a wealth of opportunities to create far better solutions to these problems than we ever had with IPv4.

It's not "lazy developers", it's right there in the IPv6 standard. It's pretty much the standard way of forming IPv6 interface identifiers (basically, the lower 64 bits of most IPv6 addresses). Generating interface identifiers randomly to protect privacy is a later invention.

It's not "lazy developers", it's right there in the IPv6 standard. It's pretty much the standard way of forming IPv6 interface identifiers (basically, the lower 64 bits of most IPv6 addresses). Generating interface identifiers randomly to protect privacy is a later invention.

It was apparently the only character thought to be unencumbered for this purpose at the time.

But it clearly wasn't, even at the time. It's too late now of course. It sounds ridiculously trivial, but it causes conflicts and ambiguity fucking everywhere an IPv6 address features in a script or config file or parameter, which has now led to the invention of using square brackets as additional quasi-standard outer delimiters for IPv6 (see: URLs, postfix config, shorewall (now - initially they picked something else), etc., etc.) - but unfortunately only most of the time, not always. If it was globally agreed "IPv6 address literal? let it begin with [ and end with ]", even if they kept the unfortunate colons, then you could at least write them unambiguously as part of larger strings featuring colons for other purposes, like so many command line args, config files and urls do.

At the very least, if you're implementing IPv6 support, please be aware of the de-facto conventional choice of [ and ] for extra outer delimiters, don't go inventing different ones like shorewall initially did (then fixed, to their credit).

Do you think there should be a .here TLD, reserved officially for local use in an analogous way to the way that the RFC1918 IP addresses are reserved officially for private use?

Currently many are coming up with their own adhoc TLDs for local use. In my opinion this is suboptimal. Having a standard official TLD would allow more interesting things to "organically grow" on it.

See also: http://tools.ietf.org/html/draft-yeoh-tldhere-01

Most of my MX records point at a CNAME,

Doesn't that ever cause you problems? MX records must not point to a CNAME RR.

For your next project/requirements, you might be able to just refer to RFC 2119 to define these terms.

Sorry but the IETF does a much better job of documenting than any patent office ever did. See: http://tools.ietf.org/html/rfc1866 - HTML 2.0 documented in all it's glory.

Just was reading http://tools.ietf.org/html/draft-lear-iana-timezone-database-04 apparently it looks like Arthur Olson was planning to retire. IETF was planning to take on the custody of the role and host the list? I wonder if this is related?

Try using UTF-8 (1998 technology) if you really want to marvel at the backwardness of Slashdot's comment handling.

But at least the site is stuffed full of AJAX now. So full of AJAX I had to enable NoScript here in order to make it usable.

With sufficient thrust, pigs fly just fine.

You know, the issue here is not the browser. It's the HTTP protocol - it was simply designed for nothing else but static content. The number of kludges and patches you need to implement basic session handling and interactvity is getting ridiculous. Do we even have a RFC for cookies, for example?

The only flaw with HTTP is that it is stateless. It is also its greatest strength.

I'd hardly call cookies 'number of kludges and patches' though. Ah, here is the RFC: http://www.ietf.org/rfc/rfc2109.txt

Not necessarily... see RFC 2817.

Tepples listed one good use for PDFs (natively paginated documents, such as IRL slideshows/presentations)

The impression I got from the top-level post was that documents SHOULD NOT* be natively paginated and SHOULD be authored for scrollable media. Slideshows/presentations allegedly lead to PowerPoint syndrome.

a PDF viewer that almost invariably supports both continuous scrolling and single-page viewing.

In theory, yes. But in practice, people still distribute PDFs with two-column layouts intended for printing. And even with one-column layouts, continuous scrolling still leaves a two inch gap between the text at the bottom of one page and the text at the top of the next.

Unless someone is using a PDF viewer implemented in Flash *shudder*

That was FlashPaper, Macromedia's competitor to Acrobat before Adobe bought Macromedia. Nowadays, even though PDF technology has nothing to do with Flash technology, they're associated in people's minds under the banner of "Adobe products".

* In the sense of RFC 2119.

The service Google is talking about here tracks the physical location of Wifi hubs by SSID, and because of regulatory pressure they're letting the Wifi hub users opt out.

If only IEEE 802.XX devices like wifi access points had some sort of address that was guaranteed to be unique to that particular physical device. You could then even print that address on some sort of physical sticker and affix it to the device so that the owner could discover that address and communicate to third parties.

Oh, the things you could do!

I feel obliged to point out that 'abc.com' is an actual domain name. They've actually reserved example.com for just such uses as this. This way, if there actually is a |john|.|smith|at|abc|.|com| he won't get scraped up by a spambot from your illustration.

You have to "open" email, just to see who it's sent too.OOPS. TOO LATE.

No, at least in theory, you don't. SMTP literally has an "envelope"; it should be all the server looks at to relay/deliver messages.

Already possible. IPv6 Privacy extension. http://tools.ietf.org/html/rfc4941

How could such a gaping vulnerability be missed?!

It is a vulnerability and it hasn't been missed: http://tools.ietf.org/html/rfc4255

SSH should have done x509 from it's inception with self-signed as default. No worse than current state of things with a great opportunity to do better.

I'm still waiting for /. to start supporting IPoAC... RFC 1149 came out 21 years ago and was built on well established technology. It was updated over 12 years ago and the latest, IPv6-compatible version came out this spring.

I'm still waiting for /. to start supporting IPoAC... RFC 1149 came out 21 years ago and was built on well established technology. It was updated over 12 years ago and the latest, IPv6-compatible version came out this spring.

I'm still waiting for /. to start supporting IPoAC... RFC 1149 came out 21 years ago and was built on well established technology. It was updated over 12 years ago and the latest, IPv6-compatible version came out this spring.

Mod parent up. The domain system was meant to be strictly hierarchical, with most entities registering domains at the third or even the fourth level.

The perversion of system into a quasi-flat namespace centered around second-level domains came about because the planned high-level directory service for the Internet never materialized. These days most people use search engines to do much the same thing, albeit at the cost of standardization and protocol / vendor independence.

If certificates could have multiple signers, we could nix the authority of any one CA and still keep the cert.

An analogous change would be to enable multiple signatures on a single certificate. Recall that a single X.509 certificate contains a public key, a subject, and a signature binding the two together from a CA. There's no reason (in principle) that we couldn't declare a certificate as a public key, a subject, and a set of signatures, each from a different CA. It turns out that there is a proposal for this kind of alternate, multi-signature certificate (using the OpenPGP standard), which i'll talk about later.

I mentioned earlier that there is an alternate proposal — OpenPGP Certificates instead of X.509 certificates — which allows multiple signatures per certificate. The proposal is designed to be implementable in parallel with existing X.509 certificates. However, it is not widely implemented or adopted yet.

http://lair.fifthhorseman.net/~dkg/tls-centralization/

That is, if we're bothering with CAs in the future, instead of notaries (e.g. Perspectives or Convergence) or some other technology.

By the time Microsoft was ready to deal with IPv4, next-generation technologies were already being developed because the sustained demand was too great. IPv6 stacks were actually being released for Windows before Microsoft's IPv4 stack was integrated - and that's even after Microsoft took most of their network code from the BSD tapes.

I'm going to have to say you're wrong.

Windows 95, released in August 1995, integrated an IPv4 stack. The first IPv6 RFC, RFC1883, was posted in December 1995. It was replaced in December 1998 with RFC2460.

By the time Microsoft was ready to deal with IPv4, next-generation technologies were already being developed because the sustained demand was too great. IPv6 stacks were actually being released for Windows before Microsoft's IPv4 stack was integrated - and that's even after Microsoft took most of their network code from the BSD tapes.

I'm going to have to say you're wrong.

Windows 95, released in August 1995, integrated an IPv4 stack. The first IPv6 RFC, RFC1883, was posted in December 1995. It was replaced in December 1998 with RFC2460.

3. Can you be a bit more specific about what you proposed in 1993 ?

There is a Secure Remote Password protocol that allows you to authenticate both server to you and yourself to server at the same time. There's also a RFC 5054 aimed to incorporate it to TLS, unfortunately without any client support AFAIK.

HTTP gives plenty of leeway and in fact was designed with caching in mind. So long as the involved parties do not violate the protocol, I'm ok with it.

This initiative is not going to be changing http at all. The client may end up at a different replica of the http service, but each of them is equally valid. The only difference is how fast you get the answer.

The DNS protocol must also be honored to the extent that deviations from same have not been expressly authorized.

The protocol was designed in an extensible way. If the client supports this particular extension it will send the extra information along to the server in a way that the server will simply ignore if it doesn't support the extension. If the server supports the extension and sees this extra information from the client it may pass along extra information to the client. If the client doesn't support it, then the server will never see this extra information from the client and thus not return the extra information to the client either. So if only one of the two support the extension, then everything will work out exactly the way it did before the extension was introduced. I don't know where to find the final version of the spec. I know where to find an expired draft. The protocol probably hasn't changed much since that draft. However in the draft the option code is listed as TBD, has IANA assigned an official option code for this extension?

Speaking of squid, its 2011, is squid ever gonna support ipv6? There's not much software out there that doesn't support v6, and squid is probably the most famous.

Hell, I'd be happy if it used HTTP 1.1! It's only been a standard since June 1999.

Request-Range? I'm not familiar with that request-header field. Searching now, I can't find it in RFC 2616 either. Could you point to where you heard about it?

Junk mail predates SMTP. It's described as a problem in RFC 706, Nov 1975

Did i somehow miss a magical size limit in SMTP

It sure seems that way, see rfc2821 - servers weren't actually required to support individual messages larger than 64k for a long time, though were encouraged to do so of course. 64k is not really a lot of binary data, but is quite a lot of plain text.

message content
      The maximum total length of a message content (including any
      message headers as well as the message body) MUST BE at least 64K
      octets. Since the introduction of Internet standards for
      multimedia mail [12], message lengths on the Internet have grown
      dramatically, and message size restrictions should be avoided if
      at all possible. SMTP server systems that must impose
      restrictions SHOULD implement the "SIZE" service extension [18],
      and SMTP client systems that will send large messages SHOULD
      utilize it when possible.

Plus, SMTP AFAIK still doesn't require 8-bit cleanliness, meaning everything sent by SMTP gets encoded inefficiently into 7-bit ASCII, which is incredibly wasteful.
 

Thanks to what some would call an unfair advantage in the UNIX-centric nature of the entire internet protocol suite, UNIX gained an early lead in internet sites (this was before the "web", you know)

So what about it was "UNIX-centric"? (No, "protocols like FTP were text-based, so they were UNIX-centric" isn't it - Dating back at least as far as RFC 454, in 1973, when UNIX was about 2 years old and not very ARPANETted, a text-command-based FTP was being proposed.)

Even though Apple and Google were taking UNIX systems, stripping the userspace, and replacing it with strange "mobile-optimized" front-ends,

At least for Apple, the "userspace" you're referring to presumably refers to the UI, rather than, say, the system library, which, in iOS is very much like the Mac OS X system library, i.e. it's what a UNIX person would call a libc (even if it's called libSystem). For Google, it's a bit different blah blah blah Dalvik blah blah blah, but at least as I read What is the NDK?, it sounds as if they're offering at least some low-level UNIX APIs to native applications:

[The NDK] provides a set of system headers for stable native APIs that are guaranteed to be supported in all later releases of the platform:

• libc (C library) headers
• libm (math library) headers

...

So what is this? We've seen 3 decades+ of growth, and now... it all ends here. Is there such a thing as "peak UNIX"? Cause this sure looks like it from here. The world has moved on, Moore's law has finally given us enough computing power to generate all the shiny bling we need to blind ourselves to what's under the hood.

"What's under the hood" is still UNIX (in the "even if you're not supposed to call it UNIX", i.e. the "little if any of it is based on AT&T UNIX code and it wasn't certified by running it against the Single UNIX Specification validation suite, but it's still recognizably UNIX in its the low-level APIs", sense) for the two fastest growing smartphone OSes, the top tablet OS (same as one of the two smartphone OSes), and at least one of the other tablet OSes (same as the other smartphone OS). Most application developers for those OSes probably don't end up using any of the low-level UNIX APIs in their code, however.

No, I'd say that you should use RFC 6214 instead.

DANE

So where in the patent application do they mention a new protocol? They do mention an existing protocol....

In the other patent application they mention "a new document-format-preferred key (as a MIME media type), which enables the printer to specify a "preferred" document format out of all of the document formats that are supported by the printer", which is a new IPP key, and also mention "a new "URF-supported key" to a discovery protocol and a transport protocol. More specifically, some embodiments have added a new URF-supported key to the discovery protocol as part of a Bonjour(TM) TXT record, and have also added an analogous URF-supported key to the transport protocol as a new printer description attribute for the IPP protocol", where URF is presumably the Universal Raster Format mentioned in other comments. It also mentions "a new device-independent bitmap container for printer data".

If the patent is granted, I suspect licensing it to put into your printer will be easy and cheap, to encourage lots of printers to support it, but licensing it to put into, for example, your smartphone OS might not be quite so easy or cheap.

So, the printer manufacturer's choice is:
1. License PostScript from Adobe.
2. License this new protocol from Apple.

So where in the patent application do they mention a new protocol? They do mention an existing protocol....

So, rather than have a "driver" the computer has to know a new means of interrogating the capabilities of the printer

Or an existing means of interrogating the capabilities of the printer (which they call out by name in the patent application).

and then convert files to a format that the printer can handle... Right?

Yup, or ask some server "in the cloud" to do it, as the patent application says.

DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:

For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.

Could you address those?

Yeah, I'll give it a shot.

First off "the right solution to the TLS security problem" is a problem. "TLS security" is not a single (the) problem but a multifaceted problem. DNSsec addresses (doesn't totally solve - none do - but does address) one of those facets (tying the cert to the domain owner). The fact that a malicious state level actor controls both DNS (and their ccTLD DNSsec signing) and the certificate authorities just leaves you in almost the same spot except I would argue that DNSsec has a leg up there. Not perfect, but better and more verifiable.

Controlling the CA, they can spoof a MITM certificate claiming to be you. Now, you have to validate all your certificates from an outside point of view. Or they issue the certificate and key to you (bad BAD practice done by many CAs for TLS E-Mail certs - they should NEVER have possession of the private key) and you will never be able to tell if they are abusing your cert or not. That's bad. That's real bad.

With DNSsec, you give them your public key signing key (ksk). They either properly sign it and publish it or they don't. You can verify this in the public DNS (plenty of public query servers and looking glasses and historical sites for DNS - aot site certs where you're on you own). You use your private ksk to that public key to sign your zone signing public keys (zsk) and you publish that public key yourself, which you can then also verify. Then you sign your records with the private key of your zone signing key. All of this should be confirmable from the public DNS but, in the case of a malicious state actor, you may still have to confirm it from an outside view (a looking glass or secure remote server) but you only need to verify that THEY properly published YOUR ksk public key and that they are not blocking DNSsec. You never give them your private key (never underestimate the power of what Bruce Schneier calls "rubber hose cryptography" - they beat the bejesus out of you till you give them the bloody key).

Is it bullet proof? In the face of a malicious state actor, nothing is bullet proof. We can only try to make it tougher for them.

DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:

For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.

Could you address those?

You have to write it as http://[2001:4860:8006::6a]

They made a RFC about this new syntax for IPv6 literals: http://www.ietf.org/rfc/rfc2732.txt

The problem is without the [] you would need to count :'s to find the optional port part of the URL.

The only mailing lists that matter in terms of making decisions on internet infrastructure are the publicly viewable ones over at the IETF, like those of the Transport Layer Security working group. The poster could be complaining about a group of script kiddies with their own mailing list in Nebraska for all we know.

• Multipath TCP (Internet draft). This should allow load-balancing or failover between two hosts where at least one has multiple IP addresses (is multi-homed), including the case where one end has and IPv4 and and IPv6 address or has multiple IPv6 addresses from multiple networks (including, for example, 6to4 and Teredo).
• TCP Crypto (Internet draft). A way to encrypt the TCP stream, not as an application running over TCP (as is SSL) but as an option in TCP itself. Redundant if either every protocol is SSL-ized or if IPsec is universally deployed, but perhaps useful at present.

These extensions are deployable now, on TCP/IPv4 and TCP/IPv6 equally. (There is no "TCPv6". RFC 1705 mentions TCPv6, but that was only an "informational" memo written when people were still talking about "IPng".)

• Multipath TCP (Internet draft). This should allow load-balancing or failover between two hosts where at least one has multiple IP addresses (is multi-homed), including the case where one end has and IPv4 and and IPv6 address or has multiple IPv6 addresses from multiple networks (including, for example, 6to4 and Teredo).
• TCP Crypto (Internet draft). A way to encrypt the TCP stream, not as an application running over TCP (as is SSL) but as an option in TCP itself. Redundant if either every protocol is SSL-ized or if IPsec is universally deployed, but perhaps useful at present.

These extensions are deployable now, on TCP/IPv4 and TCP/IPv6 equally. (There is no "TCPv6". RFC 1705 mentions TCPv6, but that was only an "informational" memo written when people were still talking about "IPng".)

• Multipath TCP (Internet draft). This should allow load-balancing or failover between two hosts where at least one has multiple IP addresses (is multi-homed), including the case where one end has and IPv4 and and IPv6 address or has multiple IPv6 addresses from multiple networks (including, for example, 6to4 and Teredo).
• TCP Crypto (Internet draft). A way to encrypt the TCP stream, not as an application running over TCP (as is SSL) but as an option in TCP itself. Redundant if either every protocol is SSL-ized or if IPsec is universally deployed, but perhaps useful at present.

These extensions are deployable now, on TCP/IPv4 and TCP/IPv6 equally. (There is no "TCPv6". RFC 1705 mentions TCPv6, but that was only an "informational" memo written when people were still talking about "IPng".)