Vint Cerf Answers Your Questions About IPv6 and More

Last week, you asked questions of "father of the Internet" Vint Cerf; read on below for Cerf's thoughts on the present and future of IPv6, standards and nomenclature, the origin of his beard, and more. Thanks, Vint! What can we do to get ISPs to switch on IPv6?
by jandrese

One of the biggest hurdles to IPv6 adoption today is that the average home user simply cannot get an IPv6 address from their ISP. Tunnels are hacker toys, and completely impractical/impossible for people who are using their ISP's "home router". What do you think we can do to convince ISPs to start rolling out IPv6 [i]before[/i] there is a crisis? Everybody agrees that the transition will go smoother if we take it slow and easy, but nobody is willing to make the first step, and IPv4 addresses aren't still being inexorably depleted the world over.

VC: I have been asking myself (and others) this question for some years now! When you try to explain that they can't really expand the Internet effectively relying solely on cascading NAT boxes they kind of glaze over. Sadly, now that we really are in the IPv4 end-game, there is not much choice but to deploy NATs to try to make dual-stack work as a transition plan. If ISPs had started implementing IPv6 5 years ago we would not have this problem. I think only pressure from consumers, businesses and governments to demand IPv6 implementation will help. Even then, I can imagine the bean counters insisting that there be incremental revenue for implementing IPv6 despite the simple fact that the only serious path to supporting smart devices (including smart grid, mobiles with IP addresses, etc) is through implementation of IPv6. We are also going to have to find some incentives for users to upgrade their home routers to handle both IPv4 and IPv6. Maybe a trade-in policy???

IPV6, and a related question
by gr8_phk

With IPv6 we could all have fixed IP addresses (or blocks of them) at home. Is this likely to happen? What do you see as the pros and cons from the ISP point of view for doing this? I think the reasons I want it are the reasons they don't, but I'd like to know how someone with your perspective sees it.

VC: We could actually have a fairly large group of IPv6 addresses at each termination point. An advantage is that one could then run servers but some ISPs might find that problematic because of the potential uplink traffic. I ended up paying for "business" class service to assure fixed IP addresses for that reason. I did not have servers of video or imagery in mind, but, rather, controllers and sensors (and ability to print remotely, for instance).

Hardware accelerated IPv6
by vlm

Hardware accelerated ipv4 routing/switching was out there, I dunno, at least a decade ago, or more. Your expectations on the rollout of hardware accelerated ipv6 switching?

VC: It probably won't happen until there is clear evidence of an IPv6 tipping point. Of course, it makes every bit of good sense and the IPv6 format is better geared to hardware assist than IPv4.

Why the colon in IPv6?
by jandrese

The biggest thing I hate about IPv6 is that the standard format uses colon as the digit separator. On most keyboards, that is a fairly awkward character to type, especially in rapid fire between groups of hex digits. Also, it causes problems for the many many programs that specify ports after IP addresses with a colon (like URIs!). IPv4's use of the period instead is much nicer. If you didn't want to reuse the period (so programs can distinguish between the two types of addresses more easily), why not use dash instead? It's just as visually appealing and doesn't require you to hit shift to type it. It would have saved a whole lot of ugly brackets around IP addresses.

Any aesthetic qualities of the colon are lost when you have to do this:
http:/// [http] [1005:3321:5a52:4fca::1]:8080/
instead of: http://1005-3321-5a52-4fca--1:8080/ [1005-3321-5a52-4fca--1]

And that second example was noticeably quicker for me to type.

Edit: And of course because this is Slashdot it made a huge mess of the first URL and forced me to mess it up slightly to be readable!

VC: The colon was needed to allow for compressed display of IPv6 addresses and to avoid confusion with a dotted representation of IPv4. It was apparently the only character thought to be unencumbered for this purpose at the time. Other slashdot readers may have additional comments on this.

Hindsight is 20/20
by eldavojohn

If there was one thing you could go back and change about TCP/IP -- something that is far too entrenched to change now -- what would it be?

VC: Well, I wish I had realized we'd need more than 32 bits of address space! At the time, I thought this was still an experiment and that, if successful, we would develop a production version. I guess IPv6 is the production version! I would also have included a lot of strong authentication mechanisms but at the time we were standardizing TCP/IP (version 4), there was no practical public key crypto capability ready in hand.

.here TLD?
by TheLink

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 ad hoc 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)

VC: Hard to say, honestly. I am not sure just what ".here" might actually mean unless intended to be self-referential (in other words, the server is the same as the referring party - kind of like 127.0.0.1? In that case, it need only be a reserved term rather than something you register in.

Ooh! Settle An Argument For Me!
by Greyfox

Though my deep and thoughtful meditation on IP addressing, I have realized that an IP address is simply a number. We canonically break it up into 4 smaller numbers that are presumably easier to remember. However if you stack all the bits of those smaller numbers together, you get a bigger number, and that number is actually the address. Moreover, every C standard library that I have ever tried is able to resolve this bigger number to the correct address. If I ping a 10 digit number in that address range, the C standard library will figure it out. It is my position that this is a feature and not a bug.

It seems that the OS X Firefox Guys don't agree with me. Admittedly they do have an RFC on the subject, but their browser breaks a known behavior that every other TCP/IP client program on the planet exhibits, including other operating system versions of Firefox!

Would you kindly bludgeon one of us into submission? I don't really care which side of the argument you come down on, but one of us has to be able to say "Because Vint Cerf said so!"

Oh, and while I've got you, I'm sick of writing stateless http applications. May I have your permission to go back to writing plain old socket servers on other ports, providing data based on whatever query format I feel like implementing? It kind of looks like REST, I suppose, except that I don't have to load 14 layers of frameworks to get to that point.

VC: LOL! actually, most of us assumed that any way to generate the 32 number should be acceptable since the connection process doesn't actually use the text representation of the IP address. I think any value in the range 0 to 2^32-1 should be acceptable as an IP reference. As to stateless operation, I know what you mean; you have to get used to figuring out how to stash intermediate state (cookies usually)...

SMTP, DNS, U.S. Customs
by molo

It seems that it is getting more and more difficult to successfully run your own SMTP server. See, for example, this post responding to the idea that a user was going to move off gmail to their own server. Are there any prospects for meaningful SMTP reform that would lower the barrier to entry for legitimate emailers?

DNS has been often criticized as a centralized single point of failure / censorship. Have you been following the development of namecoin and P2P DNS? Are these systems viable in your estimation? How would you improve them or encourage their adoption?

The U.S. Customs department recently created headlines in seizing domains. These seizures appear to be extra-legal (not founded in law), but ICANN has gone along with them. Are those fair statements? Should ICANN's trustworthiness be suspect as a result of this process?

VC: On SMTP, the problem is spam. If SMTP relays could be authenticated in some way, perhaps running your own would work better. As of now, it is a problem to validate relays and most ISPs don't allow it. Maybe we will make some progress in this when we can strongly authenticate/validate end points in the network better. Regarding alternatives to DNS, it would be interesting to find alternatives to DNS that might be less prone to the business models that produce domaining, for example, but I have not yet seen evidence that such an outcome is likely to gain traction. I am not sure that ICANN has any ability to resist effectively the so-called seizures of domain names by the DHS/ICE. I am disturbed by the argument that this is comparable to FBI "seizures" of contraband for many reasons but I think the ability to resist this would rest on a successful court challenge to the practice, not to an ICANN policy.

Smart Grid
by kiwimate

You're currently on the Governing Board of the NIST Smart Grid Interoperability Panel. What is the state of standards development, and how big an impact does it have to move national infrastructure communications into the public IP arena so far as our ability to strengthen and expand our infrastructure? Conversely, how big are the threats in this new world?

VC: The process is moving along reasonably well although adoption of the standards that are emerging in the US will depend on endorsement by FERC and NERC. I think the standards can be very beneficial to the creation of interoperable energy management systems, edge devices, and device controllers. I am pleased that IPv6 forms a major basis for edge communication but concerned that the domestic ISPs, with some notable exceptions, have been slow to roll out support for IPv6. I imagine that an IPv6-equipped mobile could easily become a remote controller for a wide range of IPv6-labelled devices.

What would you like to see developed next?
by techmuse

I'm curious what technologies you would like to see developed next, or what you think would be most important to develop next. In other words, what do you think researchers should work on now that would be most significant? (Oh, and thank you for changing my life!)

V: My major wish right now, apart from ISP implementation of IPv6, DNSSEC and more end/end crypto and strong, 2-factor authentication, is the implementation of true broadcast IP. Satellites raining IP(v6) packets to Earth in range of millions of receivers could make widespread digital distribution of information far more efficient.

Interplanetary Internet
by immakiku TCP/IP started as a military project but has been adapted for all the Internet applications we see today. What sort of applications do you foresee/imagine for the Interplanetary Internet, aside from the stated purpose of coordinating NASA devices?

VC: The primary terrestrial applications are military tactical communications and enhanced mobile communications. I see a role for these delay and disruption tolerant protocols in public safety networking as well. All devices in the system could also serve as relays to allow for the dynamic creation of Mobile Ad hoc Networks, making more resilient emergency services communications and any number of popular user apps on mobiles.
The IP of TCP/IP
BY WHOM

The head of UN's WIPO believes that the Internet (and obviously the stack on which it runs) should have been patented. How do you believe it would have evolved, would TCP/IP be protected by patents?

VC: This is really pretty silly. Bob Kahn and I consciously did NOT patent or control distribution of the design and protocol specifications for TCP/IP for the simple reason that we wanted no intellectual property barriers to the adoption of TCP/IP as an international standard. I see absolutely no utility in the proposition to patent TCP/IP. It would have given a reason for SNA, DECNET and other proprietary protocols to persist since their inventors/purveyors could have argued that licensing TCP/IP (had it been patented) would be of no interest to them - indeed, its use opened up interoperability among many brands of computers (and networks) leading to more competition.

Has the Internet become too centralized?
by slashsloth

That is to say, do you think that too much power & control now lies in the hands of the Internet Service Providers, thereby making it, at least in terms of control if not routing, too centralized & too easily manipulated by the powerful few. I guess this question stems from a viewpoint that it should be somehow democratic & free (as in free speech). Also do you share my pedantic belief that the public Internet should be spelt with a capital 'I'?

VC: As to the latter, yes, I strongly believe that the capital was intended to refer to the public Internet (I have written on this in the past). We accepted the notion that "internet" could use the protocols but be private and disconnected from the public Internet but that "Internet" referred to the latter. Some people disagree but I still believe it to be a useful distinction. As to centralization, it is possible that the lack of competition among Internet access providers is a bad outcome. I have always been a proponent of intra-modal competition through open access to underlying transport networks but not everyone agrees with me.

How can we bring trust back to the internet?
by Madman

One of the secrets of the internet's massive success is the lack of controls over it; if there had been strict security and processes in place it would likely not have come about. One of the downsides is that all our security measures are tacked-on, there is no built-in security to the protocols used on the internet and as a result security is a massive problem. How do we go from the wild west to having at least a reasonable level of trusted computing?

VC: Better and stronger authentication would help. 2-factor "passwords" and registration of devices. We may also need to adopt international norms for acceptable usage of the net with some kind of enforceable rules with reciprocity. Until we have some collective and cross-border ability to bring miscreants to justice, we will continue to see relatively unconstrained behaviors including harmful ones.

No more "peace and love" in software designs
by BeforeCoffee

I take it that the "route around failures" and other original design features of TCP/IP and the Internet as a whole relied upon trusting others always having good intentions and cooperating. Those designs were necessary at the time and the reason the internet exists today.

Nowadays distrust, firewalls, and coding defensively is the norm (or it should be). In that light, the internet's design seems creaky and vulnerable.

Do you have any thoughts or feelings on how software has changed and seemingly become so treacherous since you first designed TCP/IP? Would you advocate a ground-up redesign of internet transports and protocols starting with TCP/IP?

VC: I have always been a fan of trying clean-sheet designs. Sometimes you discover retrofits that don't require a re-design. In other cases (such as delay and disruption tolerance) you need serious re-implementation of new designs. It is clear that authentication, various forms of cryptographic protections and the like are needed at several layers in the architecture. Deploying something wholly new is hard, though.

Future of the Internet
by H0bb3z

Do you feel the security concerns over collected information will trump the leveraging of information in future Internet technologies? Will there be a separate "opt-in" or "opt-out" web to cater to each preference?

Context: There have been many controversies recently regarding the collection of data and the privacy of individual information. As we move forward, I've heard a mixed set of messages regarding the direction we should expect to see.

Consumerism is indeed driving innovation and everything is going mobile these days (there's an app for that I think). One example I heard recently of the benefit of the convergence of information and mobility: a consumer can point their mobile phone at a shelf of groceries, get an active "overlay" of information regarding the products and determine which best suits the customer needs. On the flip side, sensors that track customer behavior are installed at the grocery shelf and based on detected behavior (like stopping for a moment to reminisce about Coco-Puffs even though you know they are bad for you) initiates a coupon for whatever the vendor may feel would provide enough motivation to purchase their product -- in the example a $1 off coupon to the mobile phone of a shopper.

Will this become reality in the future?

I think there are benefits to be had, but also am fiercely protective of my personal information and preferences.

VC: At least in America, we have tended to readily give up privacy in exchange for convenience. Credit card information bases being a good example of that. If one can divorce identity from behavior patterns, it might be acceptable to many to benefit from system reactions to our choices and behavior if these are not correlated with identity.

Postel and Crocker
by vlm

So you went to high school with Postel and Crocker, according to Wikipedia; did you guys hang out all along or meet up decades later?

V: Crocker and I have been best friends since about 1959. Jon was in a later class and we didn't know him until we all reconvened at UCLA in the late 1960s.

A Simple Pogonological Question
by eldavojohn

What level of success does TCP/IP owe to your glorious beard?

VC: LOL!! not much! I just got tired of nicks and cuts from shaving my whole face and went with the beard!! I did shave it off once, but quickly re-grew it after being painfully reminded why I had grown it in the first place!!!

Comments

ICANN

[rudy_wayne]

I find it odd that nobody ever mentions that during his tenure as head of ICANN they were one of the biggest scumbag organizations of the internet.

What?

[OverlordQ]

The colon is hard to type? It's two pinkies

Re:What?

[Arlet]

Besides, if you have to enter so many numeric IPv6 addresses that the colon is bothering you, you're doing it wrong.

Re:What?

[jandrese]

You might think that, but in practice you end up typing the addresses a lot more than you would think, especially when you're working on small disconnected networks with intermittent connectivity and doing lots of peer to peer traffic with embedded devices. When something autoconfigures an address, that address needs to be added to DNS somehow, and that's often a fairly difficult step, if you even have DNS.

The colon requires you to keep smacking the shift key, which is awkward becuase your left hand is typing numbers and letters at the same time--try it yourself, type out: a84f:9b3a:0221::1 vs. a no-shift solution like a84f-9b3a-0221--1 and see which one takes longer. I suspect the real answer is that - is a valid name is a domain, so it's possible there was a conflict with an actual domain. While that's theoretically true, in practice I doubt it would have been an issue. Registrars could simply say: you can't register anything that would parse as a valid IPv6 address and that would be the end of it, very few (if any) domains would be in the IPv6 address format already. It's not like you didn't have to modify every gethostbyname() to support v6 anyway, so adding the check wouldn't have made much difference.

IPv6 "hard". NAT "easy"

[tlhIngan]

That's the big problem.

NAT decouples the internal private network from the external network - and I'm sure any IT admin who has had to renumber their internal network would agree it's a huge PITA on IPv4. Luckily though they don't have to do it when their ISP gives them a new range of IPv4 addresses except for the few machines that are using them (DNS servers mostly - other servers can often hide behind NAT).

They see the IPv6 transition as hard because no one makes NATv6 boxes (though it does exist, and heck, NAT-PT makes it possible to isolate the internal network's protocol from the external network - start IPv4, NAT-PT translates to IPv6 for the internet, etc.). They see the ISP giving them a prefix and changing that prefix willy-nilly causing lots of fun for everyone inside. They'd rather do it the IPv4 way - give everyone a private IPv6 address (FC00::/64) and worry on the few border routers and such.

Even worse - home users, who most likely do NOT have a working DNS setup and have to type the damn things in. And just when my parents have gotten used to typing the long string of nonsense garbage to hit the printer, the ISP changes their prefix and they have to learn a new set of IPs.

If we break the concept of true-end-to-end connectivity (already broken thanks to firewalls), the IPv6 transition could've been done years ago - everyone replaces their Linksys or Cisco router and go on their way, while the router does NATv6/NATv4/NAT-PT as appropriate. It just works, my parents don't have to learn anything new (and I don't have to fiddle with their machines and everything), etc. etc.

IPv6 is sorely needed, yes. But the assumptions made 20 years ago when it was designed just aren't true today and no one wants to play network admin for their entire extended family and neighbourhood. And enterprise is slow because they're worried about end-to-end connectivity for security reasons. NAT breaks that, so it's a nice secondary layer beyond the firewall at ensure they don't accidentally leave their customer database exposed (it might be protected on IPv4, but exposed on IPv6).

We can probably switch a good chunk of the Internet to IPv6 by haivng a transition plan of home users replacing their routers with ones that do NATv6/NATv4/NAT-PT - they're used to stuff like that and it makes life easy. Ditto enterprise customers - most businesses will probably just switch if they only have to replace one box and not have to learn the ins and outs of IPv6 and getting every PC to have a routable address it doesn't need.

Re:IPv6 "hard". NAT "easy"

[Bookwyrm]

I wish I had mod points at the moment to moderate you up, because not many get the problem.

It gets even worse if you imagine that, some day, someone comes up with a protocol that's better than IPv6 (not a bigger address space, for goodness' sake, but *better*). If people compulsively cling to the dead-end-to-dead-end connectivity model with IPv6, trying to migrate that network to the next generation of technologies that come after when every lightbulb has its own IPv6 address will bring network innovation to a stand-still.

Unfortunately, NAP-PT and related do not always work because there is not a clean separation in many applications between network-layer stuff and application-layer stuff. The applications/network services APIs have to be cleaned up first.

Re:IPv6 "hard". NAT "easy"

[csnydermvpsoft]

NAT decouples the internal private network from the external network - and I'm sure any IT admin who has had to renumber their internal network would agree it's a huge PITA on IPv4. They see the ISP giving them a prefix and changing that prefix willy-nilly causing lots of fun for everyone inside.

IPv6 provides an excellent way to address this: prefix delegation. Your router gets a prefix assignment automatically from your ISP and advertises it to clients. If the ISP renumbers, everything is automatically reconfigured when the ISP's announcement changes. The only issue is DNS, and there are mechanisms to ease that as well (though some manual intervention is required with current tooling).

More importantly, prefixes won't need to change very often. The only times I've ever had to renumber were when I was either changing ISPs or when I wanted a different size IP block. The former case still exists (though the mechanisms I mentioned above help with that transition), but the latter case should be virtually nonexistent, as everyone will be assigned a block of subnets large enough to service them for the foreseeable future, no matter how big they get.

Even worse - home users, who most likely do NOT have a working DNS setup and have to type the damn things in.

Thankfully, there are solutions for this problem as well - and they're already widespread. Look for technologies such as zeroconf to become even more common going forward (all of the printers I've purchased in the past few years - including a large corporate laser [Ricoh] and two smaller multifunctions [Brother] - include and enable it by default).

Re:IPv6 "hard". NAT "easy"

[CAPSLOCK2000]

Even worse - home users, who most likely do NOT have a working DNS setup and have to type the damn things in. And just when my parents have gotten used to typing the long string of nonsense garbage to hit the printer, the ISP changes their prefix and they have to learn a new set of IPs.

Multicast DNS is gaining traction. Multicast is a requirement for IPv6 anyway so it has a reasonable chance of working.
In my experience most parent-class-beings are unable to deal with raw IPv4 either.

Re:IPv6 "hard". NAT "easy"

[vlm]

If you don't want global addrs, don't use them. Use link local addrs inside and have everyone talk thru a proxy. Its Just Not A Big Deal.

If you don't want world wide access to your local printer, put it on a vlan thats not running radvd handing out global addrs...

Basically your "private" web browsing clients will get inet access via "squid" instead of "iptables nat". The industry has been moving toward "everything over port 80" anyway for a decade or two now.

Static DNS is dead/dying/soon no longer usable. Will that be a change? Yeah. So start changing now, so you're not trying to do dyndns and ipv6 at the same time. Dynamic for global and simple multicast DNS for internal. Yes multicast DNS is an unholy pain between VLANs, but it can be (carefully) done.

We "need" a way to actively repeatedly quickly renumber DNS because our ISP "needs" to shuffle their precious resource of tiny little /20's around to different POPs because there is an intense shortage of ipv4 space. So we can't roll out ipv6 until it supports the intense address churn required by ipv4. Err, wait a second, we don't need that administrative load of address renumbering with ipv6, thats kinda the whole point. Standard /. car analogy is we can't roll out automobiles because we are having a production problem at the horse harness factory and the customers have always needed horse harnesses with our coaches so lets not roll out "the car" until we have a guaranteed scalable horse harness factory, otherwise what would our customers use to harness their new cars?

At some point, randomly renumbering people in ipv6 is going to be considered red in the face screaming into the phone "contract breaking time" not just business as usual another day at the office ho hum. Maybe you should expect a faxed/emailed maint notification for ipv6 renumbering?

Re:IPv6 "hard". NAT "easy"

[Jonner]

And enterprise is slow because they're worried about end-to-end connectivity for security reasons. NAT breaks that, so it's a nice secondary layer beyond the firewall at ensure they don't accidentally leave their customer database exposed (it might be protected on IPv4, but exposed on IPv6).

Relying on NAT rather than a stateful firewall for security is a rookie mistake. NAT provides absolutely no security benefits beyond a properly configured stateful firewall. If you don't want to allow any incoming connections, configure that on the firewall and NAT is irrelevant. OTOH, many of the increasingly common peer to peer protocols, such as those used for VoIP are made less reliable and harder to diagnose by NAT.

Re:IPv6 "hard". NAT "easy"

[Bengie]

"NAT decouples the internal private network from the external network - and I'm sure any IT admin who has had to renumber their internal network would agree it's a huge PITA on IPv4."

IPv6 makes it even easier. Also, Ever have to renumber your network because you merged with another corp? NATs won't help you there. IPv6 helps this also by having HUGE address spaces. Chance of a collision is crazy small.

"Even worse - home users, who most likely do NOT have a working DNS setup and have to type the damn things in. And just when my parents have gotten used to typing the long string of nonsense garbage to hit the printer, the ISP changes their prefix and they have to learn a new set of IPs."

I don't have DNS setup and I can ping my printer by name. There's like 3-4 protocols for resolving by name without DNS. I have some cheap $70 HP printer, Wireless N and I can configure the name w/o DNS. In other words, what you say is a problem, isn't. Your parents have old/cheap hardware. Even my DD-WRT box can pick-up the name of the printer w/o DNS.

"If we break the concept of true-end-to-end connectivity (already broken thanks to firewalls)"

ehhh? At least with Firewalls it's "optional" to block incoming SYN packets, while NAT kind of forces it, which makes it a PITA for configuring game port forwarding.

"NAT breaks that, so it's a nice secondary layer beyond the firewall at ensure they don't accidentally leave their customer database exposed"

There are so many ways around NATs, it's not even funny. Anyone who who thinks NATs add to security, usually don't know how to properly setup a firewall.

If you want your internal network secure, use a combination of VLANs and authenticated connections along with proper firewalls. Adding a NAT to a properly locked down network is like painting a tank and thinking the paint helps protect you. Technically it does, but probably not as much as you think.

A few of my best friends are admins in datacenters. They've been running IPv6 for a while because it is just so much easier than IPv4. When I asked them what they thought about IPv6, they unanimously said any network admin worth their salt will love IPv6(except the transition, which kind of sucks). Once you're switched over, it's easy mode for a lot of things that use to waste your time. Other than the minor learning curve and transitional work, it's one of the best things to happen to networking.

Re:Biggest TCP/IP mistake

[Arlet]

That's not a problem, but a feature. It's trivial to make a message protocol on top of a stream, and the stream protocol is easy to implement.

Streams on top of messages, or one type of messages on top of other type of message protocol is trickier.

IPv6

[phantomfive]

I talked to the owner of a mid-sized ISP about IPv6. He said they had enough IP addresses assigned to them to last for another year and a half. I asked him what his plan was for migrating to IPv6. He glared at me slightly, and said, "pay lots of money for hardware."

Also, a lot of mobile carriers are starting to use IPv6. Try running netstat on an Android phone and you might see some IPv6 activity there.

Re:Vendor support for home routers

[Daniel_Staal]

Tell your three vendors that the first one of them who gets working IPv6 support will get all your business for two years, minimum. They'll have the firmware by the end of the year. (And it'll help all of us.)

Re:Biggest TCP/IP mistake

[Arlet]

Yes, TCP implements streams on top of messages, but I wouldn't call it trivial. Even though the essence of the protocol is simple, many implementers would still get it wrong.

Also, the IP message is limited in size, so if you want to implement larger messages, you'd have to split them up into smaller ones. Or, alternatively, it you want to exchange very short messages, performance will suffer. At least TCP protects you from that with the Nagle algorithm.

But, hey, if you don't like the stream protocol, you can always use UDP.

Re:Biggest TCP/IP mistake

[vlm]

Everyone who uses it immediately creates some sort of scheme to divide the stream into messages.

If its small, stick it in a single UDP packet instead of TCP, if its just one message if you can standardize on one message per TCP session its easy, so if its big and multiple messages in a stream isn't that still just one line of perl? I know its more work with every other language, but...

You can find much worse problems with TCP/IP if you want.

The biggest problem with TCP was having to implement big windows on top of it a decade or two ago to handle long latency high bandwidth links. TCPv6 or whatever should be cleanly designed from the start with big, heck, giant, window pointers. So you can send email to Mars using off the shelf devices...

Also the socket space is an awkward middle ground with some complaining its way too small and some complaining its way too large. I suppose safest to go large... 32 bit socket space would be nice.

A designed-in-at-the-start standard header compression system would be nice.

As would an embedded public key crypto infrastructure inside the TCP system supporting multiple protocols. And multiple selection of hash checking protocols. Lets make setting a md5 hash at the BGP level obsolete?

Being a stream is pretty small potatoes as far as problems go.

Re:so use UDP

[vlm]

or SCTP, or TIPC, or RDS. There are lots of message-based protocols out there. Why use TCP if you don't want streams?

Industry standard for the past 20 years has been to try and run every freaking thing over TCP port 80, often thru a proxy and a NAT. Some scummy companies try to claim something that limited actually is "internet access". And everyone is loudly trying to bend over backwards to reimplement that in ipv6. Sometimes a bad idea just needs to get chopped but no one wants to admit it.

Re:A few privacy concerns

[JSBiff]

You don't have to use the MAC address if you don't want. You can setup a DHCP server to assign addresses randomly if you really want to. However, I think the reason auto-config uses it by default is that:

A) It's already guaranteed to be unique (unless you've changed it), without having to resort to any additional logic to check for conflicts on the network.

B) For network administration, it's often nice to know which machine traffic is coming from (although, of course, for the local network admin there's other ways to track this which don't involve exposing the MAC address to the rest of the world).

One thing I don't really understand is why people get so hung up on the MAC address being embedded in the IP address. You can already be tracked by IP address, and with IPv6, even if you don't use MAC addresses, that can likely still be resolved to a specific computer.

But, as I said before, and others have said a thousand times before on other IPv6 threads - you don't *have* to use the MAC address, so please quit whining.

Re:Biggest TCP/IP mistake

[Sir Homer]

Stream protocols that offer error, flow and congestion control over heterogeneous datagram networks are NOT trivial.

TCP is not trivial at all. In fact & efficient algorithms to implement features of TCP is still an area of active research. IETF RFCs in various stages of standardization related to TCP probably amount to thousands of pages at this point, and it's still growing. Linux recently got a new algorithm for congestion control for instance: http://www4.ncsu.edu/~rhee/export/bitcp/cubic-paper.pdf

Problem with .here

[vlm]

The problem with .here is there are so many "rfc1918 like dns names".

Off the top of my head some standard ones are ".localnet" (as in localhost.localnet) and .local as in mdns/bonjour

I don't think creating another tld is going to solve the problem of why people would not / will not use the previous "local" tlds.

Re:Biggest TCP/IP mistake

[Sir Homer]

You can implement reliable transmission over UDP. And you have more options as well: you can do it with error correction algorithms for latency intorelent applications, something TCP can't provide with it's ARQ design.

Re:Biggest TCP/IP mistake

[fa2k]

As would an embedded public key crypto infrastructure inside the TCP system supporting multiple protocols. And multiple selection of hash checking protocols. Lets make setting a md5 hash at the BGP level obsolete?

No need to do it in TCP when you have IPsec! Unless of course you want per-process authentication instead of per-host authentication -- then you could use TLS. I think you are suggesting a built-in version of TLS anyway, The key management would be a pain if we didn't go with the same error-prone trusted CA model. Windows actually does something interesting here with the "homegroup" system: they use IPSec and IPv6 transparently to get secure LAN communication.

Why using the MAC address was so cool!

[billstewart]

Maybe you don't remember the days before DHCP, back when you had to put IP addresses into equipment by hand, and TCP/IP hadn't entirely taken over the world. There were a couple of alternative protocols, such as Netware IPX and Banyan VINES and Appletalk, which let you plug equipment together and it would just work, because it would figure out what network-layer address to use based on the hardware address, and you didn't have to worry about whether two people had numbered their equipment 192.9.200.1 because they'd literally typed in the address in the manual, and if you wanted to renumber your network, you just renumbered a small number of boxes and everything else quickly figured out its new addresses by talking to the server/router/whatever. (There was also NetBEUI, if you were a Microsoft user, that had the property that you could plug it in and it wouldn't just work, because it was from Microsoft, but they weren't the only purveyor of bad proprietary networking software out there either.)

Of course, DHCP has given us that for 15 years or so, so it doesn't matter as much. And Microsoft's TCP/IP support gradually got good enough that most people stopped buying Netware, and it's probably been a decade since I've had to tell anybody to stop using IPX, Netware's had TCP/IP since 1995, and even Apple Localtalk was pretty much gone by the late 90s.

But it's still somewhat nice to be able to look at an IPv6 address and say "Oh, that MAC address belongs to a Cisco/Dell/Macintosh/etc., that's probably where the problem is.", the way you could with Netware. And it's too bad that the switchover from MAC to EUI-64 meant that any subnetting happens in the first 64 bits, not the second, so ISPs have to care about whether their customers are doing subnetting and how many bits they need for it, as opposed to the early-90s view where the ISP got 64 bits and the customer got 64 bits (which left 16 for subnet and 48 for MAC.)

Re:IPv6 is a camel

[unixisc]

That's b'cos in the IPv4 header, bits 96-127 is the source IP address, and bits 128-159 is the destination IP address. The moment you start adding octets i.e. bits to the address, you are changing the lengths (and thereby offsets) of both the source and destination addresses, and as a result, every router in the world, and all networking equipment that uses IPv4 would have to be updated. Same level of effort as w/ IPv6. Given this recognition when they undoubtedly first confronted this problem, the IETF decided that since they'd be going through so much effort anyway, they decided to use the opportunity to throw in all improvements to IP that could be done, but not in IPv4.

Expanding the IPv6 address to 128 bits, and strictly defining the lengths of each field, has done enough to future-proof this protocol and probably ensuring that an IPv7 will unlikely ever be needed. 128 bits allows for a hierarchical routing scheme that was not possible under IPv4. Also, improved support for multicast and anycast, and elimination of broadcast has done wonders.