Serious question. Why is there not just some email header that contains your public key so that anyone who had gotten an email from you and has a supporting client can then send you an encrypted message? It so simple a solution that I assume I must be missing something obvious that prevents it from be a no brainer for key distribution.

You'd think they learned nothing from watching the backlash against Netflix. They appear to want to one-up Netflix by driving even more of their customers away than Netflix did with it's ill conceived changes. I doubt this even works out well for the cable guys. Only potential winners I see here are Netflix and pirates.

Well I'm not an ivory tower academic. I run a real network with 3 datacenters and ~5000 users. I have extensive experience with everything from NAT, MPLS VPNs, to high scale mcast routing and switching for market feeds and IPTV networks so I know there are VERY few good reasons to use NAT other than IP address depletion.

Only very good reason I can come up with off the top of my head is load balancing a server cluster to a VIP on an F5 or like device.

BTW - almost none of my comment had anything to do with NAT so thanx for missing the point.

I have to agree.

Considering ICMPv6 is used for such a wide array of things, RA, ND, etc, I am pretty surprised it did not include two things. First, advertisement of arbitrary data like DNS servers, NTP servers, etc. Second, the ability to sign a message so that only trusted RA advertisements would be accepted and the IPv4 equivalent of stealing the router's IP / ARP could not a happen. I suppose you can do something on a switch along the lines of DHCP snooping so only trusted ports can send RAs but that seems like a throwback to IPv4.

Right now NAT is such a huge barrier to end to end communications that other problems with TCP still get more ink. Once, if ever, we live in an IPv6 world the biggest problem with TCP, no multihoming, will get more ink.

If you want ubiquitous and seamless mobile connectivity you must go IPv6 and multihomed.

SCTP is multihomed by design. This absolutely essential for seamless mobile communications. You as a smartphone/mobile device could have something like 3 or more routable IPv6 addresses. Cellular, WiFi, and maybe some kind of MAN Fi or other in-between access tech.

Right now it's up to the higher layers to decide which connection to use. The addresses can change as you roam. Switching between connections breaks lots of stuff and any data multiplexing must be done at the application layer. It's a nightmare even without NAT!!

SCTP multihoming solves this and along with no-NAT IPv6 end to end addresses puts in place most of the foundation for truly constant mobile connectivity and better speed in some use cases via multiplexing to boot.

However, SCTP is still not all the way there in my option as it's congestion detection mechanism, packet drops, it still the same as TCP. The bittorrent uTP protocol's congestion avoidance mechanism is a much better way to go. Its use of one way delay as a proxy for detecting congestion is BRILLIANT!! Queueing on a network device will happen before drops so before you see drops you will see latency rise.

This combined with multihoming could deliver truly seamless mobile communications as you are connected via a number of possible channels. As you move around, something like SCTP can add and drop channels from the connection and one way delay will provide superior decision making ability for switching between channels in the connection. If delay starts to rise you can switch channels before a single congestion drop ever happens.

As a VoIP application I could open a socket where I tell the stack I just need X amount of throughput and no more but I want the lowest latency you can get me. The stack should take care of the rest. Or if doing a file transfer I could open a socket that says I don't care about latency, just get me the highest throughput you can and the stack would pick the right channel or multiplex across them so long as it did not adversely affect sockets that are using that same interface with a low latency socket flag.

It's a much harder job for the stack than what it has to do today but should not be put off on to the application layer as it is today else ubiquitous and seamless mobile connectivity will always be out of reach.

To sum up. Mutlihoming plus congestion avoidance based on one way delay equals the foundation for truly seamless mobile communications.

p.s. I know the submission period for questions is long past(must have not been reading slashdot that day) but I would love to have this comment submitted to Vint for consideration/critique.