Slashdot Mirror

OK, let's move the credentials up into the scheme-specific-part as specified in the RFC

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

Or instead of username/password, we can make it some kind of hash.

Yes, that's correct. That still doesn't make it OK to access URLs that are being passed around in private communications.

And good call on ignoring the username/password thing in a completely contrived example. It could just have easily been a hash or some other url based tracking mechanism. Though, of course, the URL spec does actually specify allowing username and password right there in the scheme-specfic-part in the RFC. http://www.ietf.org/rfc/rfc1738.txt

IANA has recently reserved the IP block 100.64.0.0/10 for use with carrier grade NAT.

That's interesting. I didn't know about that block. I'll keep that in mind as I might get involved with deployments, where this is applicable. I looked up the relevant RFC, which is RFC 6598. I find it interesting that this was taken out of ARIN address space. With ARIN being next in line to run out, this block must have accelerated depletion for ARIN.

That there is a /10 allocated for the purpose doesn't necessarily mean there will be millions of users behind a single CGN. A medium sized ISP could use this /10 to assign one address to each customer without having duplicated addresses within their own network, even if they plan to deploy multiple CGN devices to service their customers. That way customers of that ISP can communicate with each other as well as the ISPs own servers without going through CGN. It can also make management easier.

I am curious what this means for usage of 2002:6440::/26 address space. Things could get interested. This is briefly covered in section 5.2.6 of the RFC.

The dimensions of thumbnails are as pertinent as the file size itself. The clutter-free look is very attractive in a world where every other forum has animated gif avatars, large colored signatures and superfluous use of !!!!

It is akin to how people post to mailing lists with the entire thread quoted. It's just bad netiquette.

Which ISP & web host would turn on IPv6 support by default with that kind of end user delay?

RfC 3514. Why re-invent the wheel with new standards?

The IETF MMUSIC (Multiparty Multimedia Session Control) Working Group started working on Session Protocols in 1993.

Initial Internet drafts for a Session Invitation Protocol and a Simple Conference Invitation Protocol were prepared in 1996, and merged to a single first draft of SIP by December 1996 (slide 10), with further drafts (2-12) leading up to the publication of RFC 2543 in March of 1999 (slides 11-13, ibid.).

I don't see anything that says BT had a hand in anything to do with SIP up to 1996. More than half the patents BT claims (Exhibit C) were filed after RFC 2543 was published.

I hope this information is a useful starting point for some SIP vendor.

In contrast more than a decade ago I proposed a .here TLD (something like RFC1918 IPv4 addresses but for TLDs) to both the IETF: http://tools.ietf.org/html/draft-yeoh-tldhere-01 and the ICANN.

People back then said use .local or .localhost. But:
1) AFAIK these weren't even officially reserved either! .local was only reserved as of Feb 2013.
2) .local etc would be more for "machine usage" - existing stuff already use these things in certain ways (Apple's Bonjour). .local might be filled by with hostnames, whereas .here might be filled with more human oriented stuff (e.g. jukebox.here, airconditioner.here, whats.here, whos.here).

Neither the IETF nor ICANN showed much interest. But I believe ".here" has a better reason to exist than .amazon. Especially if wearable computers take off - it could make it easier to refer to stuff ".here" in your current location and "plane of existence" (e.g. SSID).

After seeing the direction ICANN was taking, I realized that they were more about progressing their bank accounts than the Internet.

http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03

Funny, i work for a government contractor and i had no idea what it means. Of course i'm just a programmer, people in other departments actually talk to the government agencies and deal with the bidding.

As a programmer, you should be familiar with Request For Comments (RFCs). It doesn't take a rocket scientist to replace the "C" with a "P" and do some logical thinking. Hell even a programmer could do it.... :-)

Every port being on a different segment is utterly unnecessary

Completely eliminating problems with MAC spoofing is worth something. It would mean even if a vendor by mistake assigned same MAC to two devices, you could plug them both into the same router, and it would just work.

and would introduce unneeded latency

My calculations says the opposite. But it is really a minor difference, because it is only for the initial neighbor discovery, there will be a difference. Once receiving MAC addresses are known, the actual payload traffic takes the exact same physical path, hence no change in latency. For the neighbor discovery it is more likely for each node having an entry for the router in cache already and the router having entries for the devices, than it is for the devices having entries for each other. So the probability that you need to wait for a neighbor discovery is smaller. Moreover the latency of that discovery will be smaller, as it will need to go over only a single Ethernet link, rather than the two links needed in case of doing it between two devices each connected to a switch.

break discoverability (broadcasts no longer work)

This is already being considered by the IETF.

waste huge numbers of IPs

Which is a problem only if you are doing this using public IPv4 addresses. But the networks we are talking about here aren't using public IPv4 addresses in the first place.

and all for no benefit.

Unless you want the introduced security it offers to your LAN. Some attacks works only within the same segment. Putting every port on a separate segment means you only need to protect the router against such attacks and not every single device.

As I said, you cal ALREADY turn on port-security with dynamically learned MAC addresses on a mid-range Cisco Switch, which immediately thwarts MAC spoofing / ARP poisoning.

Those are not the only sorts of attacks that you can perform within a segment. And learning MAC addresses doesn't make sure your devices will actually be able to communicate in case the vendor screwed up and manufactured two with identical MAC addresses. Putting each port on a separate segment would solve that problem.

Routers perform a vastly different job than switches, and do so orders of magnitude slower. switching is performed essentially "wire-speed", with fractions of a millisecond incurred by switching delay

With the proper chips, routing can be done at wire-speed as well. It is not even much more complicated to do so. Of course what I mentioned won't happen until the devices are being manufactured with chips capable of doing it.

you STILL would have to do filtering, just at layer 3 instead of layer 2.

• It is not something you absolutely have to do. IP is not that vulnerable to source address spoofing. Higher level protocols deals mostly fine with it.
• The MAC filtering you proposed wasn't validating the source IP anyway. Even if you don't spoof the source MAC address on a packet, you can still spoof the source IP address and send it through a switch.
• Filtering invalid source IPs would be easier in the setup I expect to see, because the router actually knows which source IPs are valid on which ports. In contrast the switch doesn't know which MACs are valid on which ports, and it doesn't even know what an IP address is.

It is still technically within the "switching" realm (as you are doing a lookup of physical port to IP address-- something that routers simply do not do)

Finding out which port a packet must leave on based on the destination IP address is the defining feature of a

_NO_. Under no circumstances use "mbox" for mail storage, or anything other than a temporary stage on the way to transferring it to something contemporary and uable such as Maildir. If you lose that one mbox file, by file system corruption or by fat finger accident or overflowing a partition or in tht eprocess of merging new email with it, you've lost _all_ your mail in that mbox.

Thus speaks ignorance. If you write corrupt data to a mbox file, nothing prior to the corruption is affected at all. Unlike most formats that don't store each mail in a separate file, you can also very easily run recovery against a mbox file. Heck, a one-liner perl script can retrieve anything from before and after a corruption.

And "overflowing a partition"? Um, run that by us again. If you mean disk full, that doesn't truly affect a format that's made for appending. You won't be able to append. Any other format you can come up with will have the same problem.

And for archival purposes, this also does not apply. You don't make changes to your archive. Period.
And you back it up. Period.
Which is a heck of a lot easier to do with mbox than most other formats.

But again, the main strength is that it is so simple, which means that pretty much every mail program out there will support it, one way or another.
Choosing a more modern format leaves you with fewer options, and less certainty that it will be supported in the future. 20 years down the road, mbox will still be supported. It has an RFC - http://tools.ietf.org/html/rfc4155

Can you say the same about ANY other format? Maildir doesn't work on systems that doesn't allow colon in file names, and hashes the filename based on the hostname which both isn't portable, and crashes badly for many implementations if you have a non-ascii hostname. Not to mention that the format has balkanized, to the point that it's no longer compatible betweeen implementations.

Again, for archival purposes, simplicity is the key.

A technical solution would require redefining the IP standard.

This is not something new. These attacks have been known for decades. The majority of existing protocols either are not subject to or have protections against this problem.

If you try and send SYN packets to start a TCP session using a spoofed source address the vast majority of currently deployed stacks will start requring cookies. If you are not able to receive the cookie your evil plot is foiled.

This problem really still only exists in a subset of clueless UDP protocols.

New UDP protocols such as DTLS have it right from day 1. Before TLS handshake starts and DTLS server allocates any state the client must echo back a stateless cookie provided by the server to guard against spoofing. This protects against resource exhaustion and amplification.

There are stateless cookies for other common UDP protocols subject to this problem including SIP and DNS. It requires no change to IP and only minor changes to most existing UDP based protocols.

For SNMP lock down community, use TCP/TLS or DTLS instead. You get better security and there is no more amplification insanity.

Either way you look at it a lot of work still needs to be done to solve the problem. Whether from the operator filtering end or the protocol end. They both suck and they both need to be fixed.

Yep. Had BCP38 (Best Current Practice No. 38) been in effect at those ISP's, this attack would not have occurred.

Unfortunately some ISPs are spammer-friendly. As long as the spammers pay them, BCP38 won't be implemented and the spammers can continue to send spoofed packets.
I wouldn't be surprised, if some of the spammers got their own AS-numbers and act as "ISPs".

Hopefully their upstream providers gets a clue.

For sake of argument assume you are able to snap your fingers and miraculously all open resolvers have been locked down. What has been accomplished?

Will anyone still be able to issue legitimate DNS queries using forged source address with impunity for which response is several times larger than request? YES.

Will DNSSEC with egregiously enormous amplification when configured entire as recommended simply go away? A man can dream. I doubt this will come to fruition.

The way I see it there are two solutions to this problem. BOTH need to be implemented.

1. Ingres filtering (AKA tools.ietf.org/html/bcp38) as TFA and many others here point out needs to be implemented with enough specificity to meaningfully raise the bar for successful source address spoofing.

2. All UDP protocols allowing amplification or resource exhaustion from spoofed source addresses need to be beaten with a clue stick for making the Internet worse than need be. There is NO EXCUSE.

It does not need to be perfect it only needs to not suck more than the underlying network.

We know how to do this. There are production protocols which get it right. The answer is stateless cookies. It might require an extra round trip once in a blue moon or a few extra CPU cycles to calculate HMACs... we can easily afford it.

In return we get UDP protocols at least as trustworthy as underlying transport. Protocols which can no longer be turned into weapons of mass deluge.

For DNS we have had reasonable solutions for years...yet we sit on our hands and nothing gets done...
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03

This can easily be phased in conjunction with DNS query rate limiting applicable for requests without cookies.

It seems to me all the money and political interest follow fools errands like DNSSEC which paradoxically makes the Internet we actually have right now less safe from denial of service.

The statement that implied DNS servers can implement this is bunk. However BCP38 is the fix. The attack would have been impossible without spoofed IP source addresses.

An application/reflection denial of service attack is actually possible with SNMP and several other protocols. Even if all of the DNS servers were closed this attack could happen.

Yep. Had BCP38 (Best Current Practice No. 38) been in effect at those ISP's, this attack would not have occurred.

It claims that the problem is DNS resolvers that don't authenticate the sender's IP address using BCP38. It is comparing chalk and cheese. Filtering out spoofed IP addresses is something that needs to happen at the edge of the network. It's not something that a single server on the network can do.

If you aren't browsing over a VPN with HTTPS / SSL and transmitting all your data encrypted by this point you ought to be.

Why? After all, if you have nothing to hide and you set your evil bit to zero, the DHS won't intercept your traffic.

I mean: nobody is so crazy to waste citizens' money on intercepting and storing everyone's communication, the investment and maintenance cost will be everly increasing.
And for what? After all it is only the traffic caused by hackers that would be interesting, not honest citizens' traffic. And the institutions/companies have already organized their own defense, as any good citizen does (e.g. installing locks and buying riffles); this along with paying their taxes (for supporting the infrastructure development and research and whatnot), behaving responsibly (e.g. avoiding the externalization of their cost of environment protection or defending their infrastructure), etc.

(grin)

RFC 6182 if anyone is interested.

I think RFC 6824, linked in the summary, is the more relevant RFC.

RFC 6182 if anyone is interested.

I think RFC 6824, linked in the summary, is the more relevant RFC.

The first part I read when I heard of this was the security concerns. While there's been a good attempt to address them I am not 100% sold. I guess the proof will be in the pudding as the old saying goes. Anytime you make a new protocol, especially one that is more complex, you run the risk of increased vulnerability.

RFC 6182 if anyone is interested.

The author makes no distinction between OAuth 1.0a and OAuth 2.0. One of the spec leads did rage quit, not because of how bad OAuth is in general but because of all the "enterprise" help in version 2.0. Saying there is no standard is also dumb, yes version 2.0 can suffer from incompatible implementations but version 1.0 is pretty straight forward, the standard is right here: http://tools.ietf.org/html/rfc5849. The suggestion that we should just stick to HTTP Basic Authentication over SSL/TLS shows that the author doesn't get OAuth. The whole point it that apps shouldn't have your passwords to do what you ask them. Passwords are insecure and we shouldn't be giving them to every single application that wants them no matter how useful the app. We need delegation and permission revoking.

Google.
IPoAC.

If I understood the article, the reported RC4 weakness is known since so long ago there is a RFC about it (rfc4345) that TLS implementation just ignores. SSH also uses RC4 in a non-vulnerable way, and that's why it's not broken, and it's perfectly possible to have a secure RC4 algorithm by simply discarding the first N bytes, where N>1000.

Isn't that somewhat close to ISO 8601? I generally find it good and sensihle, helps with sorting and reading.

However it is a bit short-termist. I prefer RFC2550 as a long-term solution

We have quite a lot of them, but we don't have many systems that are fully RFC2550 Compliant:
https://tools.ietf.org/html/rfc2550

So, if you just need to access by ssh for just some checks and so on, I think you can setup one of those free VPNs like proxpn.com If you would like to have direct connectivity (for example for bandwith reasons) I have another proposal: It's not so easy to set-up, but I think that the best solution is to use the ICE protocol (http://tools.ietf.org/html/rfc5245) for NAT traversal. It is used for establishing p2p connection on SIP for VoIP calls (also skype use it!), but actually you can use for anything else. It gives you a UDP tunnel between two peers and it works even if both the peers are behind NAT. The only case in which it does not work is when you can't use UDP or both peers are behind a symmetric-NAT (a kind of NAT used on some corporate networks). *Usually* ISP tries to follow some NAT requirements ( http://tools.ietf.org/html/rfc4787 ) so that this kind of NAT traversal techniques works.. Few weeks ago I've created a tool based on libpjproject for doing a tunnel using ICE: https://github.com/Otacon22/icetunnel the only thing is that you need some way for exchanging the SDP informations. For example you could: 1. connect both peers to a free VPN 2. Connect to the home peer on ssh over the VPN 3. Start my icetunnel tool on both peers, copy SDP data and paste to the other host 4. Open a VPN over the UDP tunnel created by ICE Sorry if the description is not so clear but I'm still developing it! P.s: also the new WebRTC uses ICE!

no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked

Its not a bug. While the Web Storage API Candidate Recommendation (related to, but not part, of, the HTML5 spec) both says that user agents should set a per-origin storage limit and should identify and prevent use of "origins of affiliated sites" to circumvent that limit, it doesn't specify either what constitutes an "affiliated site", and neither of those things that it says "should" be done are requirements of the specification. "Should" has a quite specific meaning in the specification (defined by reference in the spec to RFC2119), and its not the same as "must", instead:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, its both a recommendation rather than a requirement, and not specified clearly enough to be implemented. There are some cases where origins of the same second-level domain are meaningfully affiliated, and some times where they are not (for a clear case of the latter, consider subdomains of ".co.uk".) Its pretty clear that origins which differ only in protocol are almost always going to be affiliated by any reasonable definition (e.g., http://www.example.com/ and https://www.example.com/ which are different origins), but no automatic identification of origin affiliation by subdomain can be done simply without understanding of per-domain policies from the TLD down to the first level at which all subdomains are affiliated. (And this is a problem which will get worse with the planned explosion of TLDs.) W

Ooh, you left out avian carriers.

The fact that it's possible to build digital transmissions out of analog media is well understood. This is why I have a lot of copper wire in my house for that sole purpose. That doesn't make IP over CAT5 Ethernet a purely digital media though. People like to throw out "digital" as some sort of magic that gets bits from one place to another, but there are potentially lossy, analog encoding mechanisms involved in both transfer and storage all the time. Push deep enough and you'll start asking how bits in a computer are encoded into voltages; push a CPU hard enough and that layer can break down too. I was just pointing out where some of those edges at for the CD as a media.

There are very few avian carriers that can safely transport snakes. The only one I'm aware of is the sea eagle.

Packet loss from hungry eagles is unacceptable for long links. Screech owls perform notably better due to their symbiotic relationship with blind snakes, but the screech owl's low carrying capacity and nocturnal habit make them unsuitable for general purpose avian carriers, and severely restrict their application in general.

No, Internet is transmitted over avian carrier, see linked IETF RFC ( http://www.ietf.org/rfc/rfc1149.txt )

In other words there should be a "copyright" field in the metadata, so there is no doubt about it.

Ah .. so they finally want to implement the (almost) ten year old RFC 3514 IPv4 header!

A bad string isn't exceptional

Especially when the interpretation of that "bad string" is supposed to be CASE INSENSITIVE and the "exception" occurs because one character is upper case.

URI are defined here, and the part that deals with the "file:" or "http:" part (called the "scheme") says this:

3.1. Scheme ...

Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case- insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

Emphasis mine.

This is a case of a programmer implementing a feature defined in a standard and ignoring the standard when doing so. Not lazy, just ignorant and stupid. Just like the ignorant stupid programmers who write javascript email address verifiers that refuse to accept valid email addresses because they contain characters like '+'. Those programmers should be shot.

There's a RFC about one group's experience with using IPv6 and NAT64 exclusively (not dual stack): https://tools.ietf.org/html/rfc6586 It looks like the biggest stumbling blocks are chat clients and games. The result is not too surprising, because most P2P networking arrangements involve some kind of passing of IP addresses around, and it's doubtful that most programmers would have put in IPv6 support already.

Bruce, Microsoft contributed the SILK codec used in Skype to the Opus project and released any related patents royalty free. I would have a hard time trusting MS if they told me the sky was blue, but they basically made the low bitrate capability of Opus legally doable.

As for those who are posting their scepticism about the opus codec's quality, the IETF standardised Opus as RFC 6716 and is making it a mandatory to implement codec for WebRTC based on it's proven performance at every applicable bitrate.

For quality comparison info:
http://opus-codec.org/comparison/

RFC 6716:
http://tools.ietf.org/html/rfc6716

I should also mention there is a RFC that requires customer routers to support IPv6 firewalling and to have it enabled by default: http://tools.ietf.org/html/rfc6204

NAT has never ever had any packet inspection in it's specification.

The closest thing to a NAT specification is RFC 2663, an informational RFC that was published a good four years after NAT got deployed. It explicitly speaks about deep packet inspection:

One of the most popular internet applications "FTP" would not work with the definition of NAT as described. The following sub-section is devoted to describing how FTP is supported on NAT devices. FTP ALG is an integral part of most NAT implementations. Some vendors may choose to include additional ALGs to custom support other applications on the NAT device.

(ALG means "Application Layer Gateway".)

Carrier Grade NAT refers to an implementation of NAT444. What distinguishes this implementation is that the customer is given an IP address (or several) from within a private or shared range managed by the ISP, which is itself address-translated to a small pool of public addresses.

Hence, a customer's home network (IPv4) is translated to a provider's private network (IPv4) and again to the public Internet at large (on IPv4): NAT444.

Algorithmically it's the same network address translation you do at home, but if you were to stack two NAT-routers on top of each other to build a double-NAT at home you'd be a damn fool. When the provider does it, it gets a fancy name.

Of course, the **AAs love IPv6, since it gets rid of the "an IP address does not identify an individual" defense since an IPv6 can be traced to a specific PC, and it's possible to forensically analyze said PC to figure out which individuals are most likely to have done the crime. (Not so with NATv6 - because all traffic is routed through one IPv6 address).

Do people seriously still not know about privacy extensions?

Actually I've been waiting for such stuff since the 1990s before those books were written. There were wearable computers back then already. And even Apple came up with the Newton in 1998. In 2000 and 2001 I even tried to do a few things to shift the direction a bit to make things more open (allow for a more open ecosystem to build on) e.g. http://tools.ietf.org/html/draft-yeoh-tldhere-01
http://tech.slashdot.org/comments.pl?sid=8162&cid=716672
But I failed...

Sometimes progress seems so slow. Look at this stuff from 50 years ago: https://www.youtube.com/watch?v=mOZqRJzE8xg
(and also Douglas Engelbart's Mother of all Demos: http://sloan.stanford.edu/mousesite/1968Demo.html ).
We haven't really made that much progress in 50 years.

NASA has been doing reruns of 1960s stuff with new tech and trying to spin it as impressive. They haven't bothered trying to build a real space station where humans can actually live on rather than rot away on. New passenger jets are actually slower than those in the 1970s (but a lot more fuel efficient ;) ).

Ideas are easy. Implementation, getting mindshare and "buy-in" is the hard part. That's why patents are bad overall and slow down progress. You cannot build something decent using a typical vague and broad patent alone but you can stop someone trying to build something.

Progress in aerospace, computing, nuclear tech has been rather disappointing to me... There's been some progress in the medical tech front, so it's not all bad.

Progress in AI has been crap too, but I'm not keen on AI, prefer augmented humans (as mentioned already). We don't treat humans and other animals well, I don't see why we should create real AIs just to enslave and abuse, won't be good for us in many ways.

raw POSIX socket calls are horrendous from the perspective of the vast majority of application programmers

And yet, WebSockets exist.

I hadn't looked in depth at them before; the mix of HTTP, TCP and low-level bit-bashing is just... too depressing for Monday. I look forward to seeing someone implement websockets over BLOAT. After all, there's no problem that can't be fixed by another layer of abstraction!!!

Only because the protocol wasn't made backward compatible.

Your comment was in direct response to my observation *UNMODIFIED* IPv4 hosts cannot access the IPv6 network no matter how IPv6 was designed.

The reason for this as myself and others have pointed out is due to the simple truth larger address space can not map 1:1 to smaller space no matter how hard you try it is impossible.

The problem is not about IPv6's lack of backwards compatibility it is about IPv4s fixed address space. Increasing IPv4s address space has the same cost as IPv6 deployment.

One easy way to make IPv4 only nodes compatible with IPv6 applications would have been to preserve the old IPv4 prefixes.

Technology allowing an IPv6 only host to access IPv4 network by way of mapping an IPv6 /96 subnet to the IPv4 universe, using a NAT translator and altering DNS response to sell the effect are currently in production use. There is some breakage but it mostly works for web sites and basic access.

It does nothing to address the unmodified IPv4 only hosts dilemma. Allowing IPv6 to access IPv4 does not in any way enable the reverse to occur.

My tour thru those transition ideas which sounded good on the surface but don't actually work is pretty exhausted at this point.. Perhaps more importantly quite pointless at this stage to be reflecting on.

Well... there might still be one lingering possibility left ...perhaps we are all just complete idiots who don't know how to count... enjoy...

http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-05

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.

No, it isn't (if you do not agree, please feel free to tell me how it is). [...] It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space).

That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem.

Um... what? No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack", which means that we run IPv4 and IPv6 on the same network, at the same time. You won't "move" to IPv6. What you do instead is add IPv6 to the network, which gives you the benefits of IPv6. Then, at some later date, you might remove v4 from the network. Of course you can't remove v4 from the network now, because you'll lose access to Slashdot -- but that's not a reason to not add IPv6 to the network, it's just a reason to not remove IPv4 from it.

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.

No, it isn't (if you do not agree, please feel free to tell me how it is). [...] It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space).

That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem.

Um... what? No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack", which means that we run IPv4 and IPv6 on the same network, at the same time. You won't "move" to IPv6. What you do instead is add IPv6 to the network, which gives you the benefits of IPv6. Then, at some later date, you might remove v4 from the network. Of course you can't remove v4 from the network now, because you'll lose access to Slashdot -- but that's not a reason to not add IPv6 to the network, it's just a reason to not remove IPv4 from it.

Looks like it's not a formal standard. I found this mailing list post which links to this IETF draft text which mentions them on page 5.

Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6.

I suggest you have a look at the term "backward compatibility", and try to understand what I am talking about. Quote: "a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.".

Simply specifying a version number does NOT make a product backward compatible.

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs.

Exactly. Because there is no way you will update the entire Internet (or, on a smaller scale, all the components and legacy applications of an enterprise) all at once. And until you do, you will need your shiny new IPv6-enabled machine to access everything else.

The v6->v4 case is easy enough

No, it isn't (if you do not agree, please feel free to tell me how it is). And please remember that "I'll just put an IPv4 address on it" is not a solution - that will just make it an IPv4 machine as well. And then, why bother adding IPv6 to it??

It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space). Yes, there is more to it than that (you would need gateways capable of "translating" between that prefix and IPv4), but that is one idea.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem. It might even be an incentive for the host's owner to upgrade :) . But that case will only come into play many years later, when we actually have an IPv6-only internet.

Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6.

I suggest you have a look at the term "backward compatibility", and try to understand what I am talking about. Quote: "a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.".

Simply specifying a version number does NOT make a product backward compatible.

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs.

Exactly. Because there is no way you will update the entire Internet (or, on a smaller scale, all the components and legacy applications of an enterprise) all at once. And until you do, you will need your shiny new IPv6-enabled machine to access everything else.

The v6->v4 case is easy enough

No, it isn't (if you do not agree, please feel free to tell me how it is). And please remember that "I'll just put an IPv4 address on it" is not a solution - that will just make it an IPv4 machine as well. And then, why bother adding IPv6 to it??

It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space). Yes, there is more to it than that (you would need gateways capable of "translating" between that prefix and IPv4), but that is one idea.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem. It might even be an incentive for the host's owner to upgrade :) . But that case will only come into play many years later, when we actually have an IPv6-only internet.

X.509 doesn't have this capability. The certificate has exactly one issuer.

See http://tools.ietf.org/html/rfc5280#page-20