Slashdot Mirror

They define it adequately in the draft itself, and refer to wikipedia.
It's not a particularly controversial or hard to parse format.

Sorry about double posting, but having spoke to some people in Freenode's #mumble channel, I got some more info...

They are looking at Opus.
Screenshot showing encryption. (Thanks dD0t)

be sure to check out the new FTP Working Group at the IETF if you're involved in FTP implementations.

we're working on new and old extensions like a HASH and RANGe command, and HOST.

just join up on the mailing list!

http://tools.ietf.org/wg/ftpext2/
https://www.ietf.org/mailman/listinfo/ftpext

be sure to check out the new FTP Working Group at the IETF if you're involved in FTP implementations.

we're working on new and old extensions like a HASH and RANGe command, and HOST.

just join up on the mailing list!

http://tools.ietf.org/wg/ftpext2/
https://www.ietf.org/mailman/listinfo/ftpext

Actually, TCP was first defined as an RFC in RFC 675...

Still, 10 years or 3 years, as you say FTP was clearly not originally specified to work over TCP...

Making only primary devices such as computers and routers externally addressable simplifies the problem,

So use a ULA prefix and a very simple firewall in those appliances allowing only fc00::/7 to connect them. No need for NAT whatsoever.

This is the license for the "old" SILK codec. The patent licenses for Opus has nothing to do with that. Please read them:

Xiph.Org IPR statement: https://datatracker.ietf.org/ipr/1524/
Broadcom IPR statement: https://datatracker.ietf.org/ipr/1526/
Skype IPR statement: https://datatracker.ietf.org/ipr/1525/

This is the license for the "old" SILK codec. The patent licenses for Opus has nothing to do with that. Please read them:

Xiph.Org IPR statement: https://datatracker.ietf.org/ipr/1524/
Broadcom IPR statement: https://datatracker.ietf.org/ipr/1526/
Skype IPR statement: https://datatracker.ietf.org/ipr/1525/

This is the license for the "old" SILK codec. The patent licenses for Opus has nothing to do with that. Please read them:

Xiph.Org IPR statement: https://datatracker.ietf.org/ipr/1524/
Broadcom IPR statement: https://datatracker.ietf.org/ipr/1526/
Skype IPR statement: https://datatracker.ietf.org/ipr/1525/

No, because the Microsoft way to embrace, extend, extinguish was to keep the "how to extend" part to itself and secret, like what they did with Kerberos.

Microsoft's extensions were executed within the Kerberos specification and documented in RFCs 3244 and 4757.

No, because the Microsoft way to embrace, extend, extinguish was to keep the "how to extend" part to itself and secret, like what they did with Kerberos.

Microsoft's extensions were executed within the Kerberos specification and documented in RFCs 3244 and 4757.

There was no standards process. It will probably now be rushed as a standard.

Aren't most standards in our industry derived from some defacto implementation? Most of the history of web standardization is a story of playing catch-up with vendors. Indeed, the first HTML client was completed several years prior to the first HTML specification. For some reason, it's way faster to write some code and get developer buy-in then it is to draft a standard and get industry buy-in.

Thanks for all the kind words on SPDY; I wish the magazine authors would ask before putting their own results in the titles!

Regarding standards, we're still experimenting (sorry that protocol changes take so long!). You can't build a new protocol without measuring, and we're doing just that - measuring very carefully.

Note that we aren't ignoring the standards bodies. We have presented this information to the IETF, and we got a lot of great feedback during the process. When the protocol is ready for a RFC, we'll submit one - but it's not ready yet.

Here are the IETF presentations on SPDY:
      http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf
and
      https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf

I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201

We love help- if you're passionate about protocols and want to lend implementation help, please hop onto spdy-dev@google.com Several independent implementations have already cropped up and the feedback continues to be really great.

Thanks for all the kind words on SPDY; I wish the magazine authors would ask before putting their own results in the titles!

Regarding standards, we're still experimenting (sorry that protocol changes take so long!). You can't build a new protocol without measuring, and we're doing just that - measuring very carefully.

Note that we aren't ignoring the standards bodies. We have presented this information to the IETF, and we got a lot of great feedback during the process. When the protocol is ready for a RFC, we'll submit one - but it's not ready yet.

Here are the IETF presentations on SPDY:
      http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf
and
      https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf

I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201

We love help- if you're passionate about protocols and want to lend implementation help, please hop onto spdy-dev@google.com Several independent implementations have already cropped up and the feedback continues to be really great.

If you're intent on securing your message for confidentiality, encrypt it. To secure for integrity, sign it.

This capability has been around since S/MIME (RFC 2630 in 1999.) It applies to content only, so headers are still exposed, and of course there is still no guarantee of delivery, but pretty much every email user today can sign and encrypt their messages if they want to. Standards for header authentication (for example RFC 4408) have not been as widely adopted.

In short, email is an old protocol - one of the earliest, in fact - and it has several shortcomings. But it's not correct to say that "email is inherently insecure."

If you're intent on securing your message for confidentiality, encrypt it. To secure for integrity, sign it.

This capability has been around since S/MIME (RFC 2630 in 1999.) It applies to content only, so headers are still exposed, and of course there is still no guarantee of delivery, but pretty much every email user today can sign and encrypt their messages if they want to. Standards for header authentication (for example RFC 4408) have not been as widely adopted.

In short, email is an old protocol - one of the earliest, in fact - and it has several shortcomings. But it's not correct to say that "email is inherently insecure."

Additionally, solar radiation conditions affect transmission in a predictable, cyclic manner. Depending on latitude, the medium may be unusable for a lengthy period, during which alternate arrangements must be made.

Yes, the RFC's method has definite flaws. We set up a test network, then waited patiently until 3:06AM for perfect wind & cloud conditions before beginning our benchmarks. Nobody ever received a damned thing. Not one bip [binary puff]. We finally gave up an hour later.

I think you'll find that Shibboleth is an implementation of SAML rather than SASL.

But in general I agree. I don't have 4 passwords to use on the internet, I have dozens (and have had to create two more just today). Whilst I wouldn't want all my online activity behind just one identity, any single sign-on systems that help me keep it below 100 are appreciated.

I'm seriously considering moving some of my websites to .xxx and not having porn on them (anybody want to register laughingsto.xxx?). Are there any restrictions to registering whatever you want on .xxx?

Oh, and for the record, RFC 3675 anticipated this whole mess.

Shouldn't be much longer ...

http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1

Well unless the CA's pay off Mozilla/Microsoft/Apple not to implement it.

Regarding point 4, if web browsers supported SRV records, then you could run many SSL websites on a single IP address; just run each instance on a different port, and include the port in the SRV record for the domain.

Additionally, if resolvers supported the "multiple questions per query" part of rfc1035, there would be no slowdown, as you could request the A and SRV records in the same request.

The explanation why name-based virtual hosting with SSL is impossible is here. One way to do it anyway is here. The reason why that is still not something people would use is that the browser side has to support it too. This page lists IE7 on XP as incompatible with the TLS extension.

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

You're the third person not to know about IPv6 Privacy Extensions.

Emphasis mine:

I'm sure RMS would be ok with a law that did away with copyrights and said that all code and culture that was distributed should be freely shareable.

You clearly haven't read enough RFCs! Otherwise, you would know that "should" means "maybe" which devolves into "fat chance, sucker!" as soon as the first asshole shows up.

IPv6 will give almost everybody practically static addresses, the ultimate undeleteable cookie. So the EU regulation will be futile very soon.

That problem has been solved by RFC 4941, otherwise known as the Privacy Extensions. Most OSes support it, though I believe some don't enable it by default. IIRC the iPhone is one of the devices that doesn't support it, but that should be fixable once IPv6 becomes more widespread.

Should have used old trusty RFC1149 Protocol

named PEC: (http://tools.ietf.org/html/draft-gennai-smime-cnipa-pec-08> ) which has the same legal validity as certified mail.
There's also a variant (CEC-PAC) to communicate with government offices only.

At times like this, I often turn to the RFC series, which is a trove of useless answers to questions like this. From "Terminology for Describing Internet Connectivity" (RFC 4084):

* Client connectivity only, without a public address.

            This service provides access to the Internet without support for
            servers or most peer-to-peer functions. The IP address assigned
            to the customer is dynamic and is characteristically assigned from
            non-public address space. Servers and peer-to-peer functions are
            generally not supported by the network address translation (NAT)
            systems that are required by the use of private addresses. (The
            more precise categorization of types of NATs given in [2] are
            somewhat orthogonal to this document, but they may be provided as
            additional terms, as described in Section 4.)

            Filtering Web proxies are common with this type of service, and
            the provider SHOULD indicate whether or not one is present.

Yeah, it's most useful anyway in a corporate setting, and then I'm in the habit of telling people to expect it. The only reason I'd use it outside of work is to send a bulk mail in which I put everyone on BCC. That though is incredibly rare.

I do the same but I do it because I respect *other* peoples privacy. Usually it's a joke or something funny that I want to send around. They chose to give me their email address not everyone else I know so that's when I bcc it. There are many other things that I use bcc for.

But I note that only people who have no business speaking about the direction of technology try to create a meme about it to hide their inadequate grasp of it. Maybe gmail doesn't support bcc but that's a choice of the email *client* not the email protocol. Perhaps this ill informed blogger should consult with RFC 2076 - Common Internet Message Headers or RFC 2822 section 3.6.3. Destination address fields before announcing that a particular piece of functionality is in demise, as long as people choose to write free software there will be an email client to support bcc. I just checked the RFC and it tells me support is still there and I can't see the people who spent all that time writing that functionality into sendmail, postfix, etc etc taking that support away anytime soon.

You don't need Vint Cerf to conclude this.

If there isn't an active IETF Working Group on the subject, the chances of getting a "IPv6Next" (which I think might actually be IPv9) within the next decade are pretty small.

... IPV9 already around. ;)

Why go with IPv64 when IPv9 is already perfectly suitable for the task ?

Not pedantic at all, simply correct.

See RFC 1392.

http://tools.ietf.org/html/rfc1392#page-21 (hacker)
http://tools.ietf.org/html/rfc1392#page-12 (cracker)

Not pedantic at all, simply correct.

See RFC 1392.

http://tools.ietf.org/html/rfc1392#page-21 (hacker)
http://tools.ietf.org/html/rfc1392#page-12 (cracker)

Thanks for pushing me to research a bit: http://tools.ietf.org/internet-drafts/draft-li-bgp-stability-01.txt

If you don't trust the app, inspect the source here and compile it yourself:
    http://code.google.com/p/google-authenticator/

If you don't trust the compiler, get a yubikey which implements the same standard.

If you don't trust a 3rd party vendor, implement something for RFC-4226 yourself:
    http://tools.ietf.org/html/rfc4226

If you still don't trust that, I suggest you get a different email provider :)

Couldn't the ISP's DNS return a bogus IPv4 address for somecorp.com and then rewrite packets sent to that address as IPv6 packets to somecorp.com's IPv6 address?

This is called NAT46 and is one of the myriad transition strategies available in both directions. It is much more complicated than NAT64, though, since you need a giant state table synchronized between a router and DNS server, and you need to "waste" some IPv4 space for the mapping, which is in short supply. (NAT64 only needs to keep state in the router, since you can embed the literal v4 address inside a v6 address.)

Why not just use RFC 1149? ;-)

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

That was the original idea. But of course you would need to convert those decimal numbers to hex. The current plan would make that address available as 0::FFFF:4C21:2D79.

Don't forget that IPv6 has -zero- encryption support

Actually IPsec is a mandatory requirement for all standards-compliant implementations of IPv6,

Mod parent up +1 Funny. After all, if the parent had actually *read* the RFC, they would know that the RFC explicitly states that:

"Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address."

That means that the spam filter is following the RFC. The + address is a convention of a number of email systems but Foo+Bar@domain.com and Foo@domain.com are unrelated email addresses according to RFC2822.

Not sure if .com supports it, but I do know many special characters should be available. IDN is mostly just unicode translated and some things not allowed because it looks to similair to other things. Example:

http://en.wikipedia.org/wiki/File:IDN-utopia-greek.jpg

Some wikipedia articles:

http://en.wikipedia.org/wiki/Internationalized_domain_name
http://en.wikipedia.org/wiki/Punycode

RFC's:
http://tools.ietf.org/html/rfc3492
http://tools.ietf.org/html/rfc3490

Not sure if .com supports it, but I do know many special characters should be available. IDN is mostly just unicode translated and some things not allowed because it looks to similair to other things. Example:

http://en.wikipedia.org/wiki/File:IDN-utopia-greek.jpg

Some wikipedia articles:

http://en.wikipedia.org/wiki/Internationalized_domain_name
http://en.wikipedia.org/wiki/Punycode

RFC's:
http://tools.ietf.org/html/rfc3492
http://tools.ietf.org/html/rfc3490

NAT-PT was obsoleted due to quite a few problems, see http://tools.ietf.org/html/rfc4966

Yes, I read that. None of those problems are important on a home network (except bittorrent, but I already mentioned that you can fix it by sending hostnames). A home user contacts a couple of hundred sites at most, so there are no problems with scalability.

NAT-PT was only intended as temporary IPv4 to IPV6 transition mechanism, not as "solution" anyway. So you'd have to do transition sooner or later anyway.

My point is that the home user need never transition to IPv6 at all. Ever. We do not need persistent internet addresses. We already have DNS for that. IPv6 is an ugly solution for a nonexistent problem. I hate it. I hate the API, I hate that the address doesn't fit into an integral type, I hate that sockaddr_in6 is not a power of 2 in size and the address is not aligned. The kernel API is a pain with it. The autoconfiguration protocol is a pain and much more complicated that DHCP. And finally, there is the plain fact that there is no way I'm running without NAT. NAT is the right thing to do, both as a layer of security, and as a reminder that the contents of my home network is nobody's damn business.

A much better solution is to keep IPv4 on the leaf networks and implement a translation protocol on the backbone. The internet is not a network of equally important hosts. You have content servers and you have users. The former is few in numbers and is easily handled by NAT-PT DNS proxy. The users don't talk to each other directly, but through some server, so don't need to be globally routable.

NAT-PT was obsoleted due to quite a few problems, see http://tools.ietf.org/html/rfc4966

Anyway, you would still need support for both IPv6 and NAT-PT on router appliance (and if you have working IPv6 on it, you can run dual stack quite easily on most OSs and many devices already). And NAT-PT was only intended as temporary IPv4 to IPV6 transition mechanism, not as "solution" anyway. So you'd have to do transition sooner or later anyway.

However, if you insist on leaving local network on IPv4 (which will actually make your problems worse as time goes by, but whatever, your choice) you can implement 4to6 (see http://tools.ietf.org/html/rfc2473) instead of NAT-PT.

But I really would recommend some other transition method - either classic Dual stack, or perhaps DSlite or NAT64+DNS64.

NAT-PT was obsoleted due to quite a few problems, see http://tools.ietf.org/html/rfc4966

Anyway, you would still need support for both IPv6 and NAT-PT on router appliance (and if you have working IPv6 on it, you can run dual stack quite easily on most OSs and many devices already). And NAT-PT was only intended as temporary IPv4 to IPV6 transition mechanism, not as "solution" anyway. So you'd have to do transition sooner or later anyway.

However, if you insist on leaving local network on IPv4 (which will actually make your problems worse as time goes by, but whatever, your choice) you can implement 4to6 (see http://tools.ietf.org/html/rfc2473) instead of NAT-PT.

But I really would recommend some other transition method - either classic Dual stack, or perhaps DSlite or NAT64+DNS64.

Bring back NAT-PT! It was prematurely obsoleted due to scalability concerns. Those concerns are indeed valid, but only for large networks. On a home network with a couple of users it is a perfectly viable solution. Put NAT-PT on a router appliance, give it an IPv6 address, and it will let the home network transparently pretend that IPv6 does not exist. Yes, there are a few obvious problems with the few protocols that send IP addresses, like bittorrent, but a simple client fix can easily send hostnames instead. Otherwise, it will just work, and nobody will have to care about IPv6 except ISPs.

Many of the transition problems arise from the insistence that everybody want IPv6. Normal people don't care about IPv6, don't want IPv6, and couldn't care less what it is. Instead of starting to convert from the bottom up, with users going IPv6 first on their home networks, and then the ISPs and backbones switching when everybody has moved, do it the other way around. Convert the backbones to IPv6 down to ISP level. Then the consumers can use NAT-PT appliances to pretend that that did not happen and keep on going without any disruption.

Yes. Try RFC 1149, otherwise known as IP over Avian Carriers (IPoAC). You might need to substitute a more common discrete winged media though, say, bat or bumblebees. Just make sure you train them well (or use some strong pheromones), or you'll be getting massive packet loss.

(The RFC actually describes the sending of datagrams written on slips of paper strapped to the leg of the carrier pigeon. A more practical method would be to load the carrier with a flash drive containing gigabytes rather than bits of data.)