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.

IPv4

[Anonymous Coward]

I think the problem is legacy machines. Not the unwillingness to upgrade, but the shear expense. And I don't mean the expense of new hardward. One issue is legacy software, a subset of what I mean by legacy machines. And software isn't so nice to replace, no matter how you spin it.

I hope IPv4 and IPv6 can live side by side for as long as necessary.

Re:IPv4

[Anonymous Coward]

As someone who's been running native IPv6 for the past year and a half, I have never come across software that had any serious problems with IPv6. Any operating system and any piece of software built within the past 15 years is, in my experience, fine. Every now and then you find a corner case of a tool not parsing the colons properly, but you can work around that by using the host's name instead of its address.

Maybe there are old legacy business systems, those that run banks or something, that have problems with IPv6, but those would be relegated to specific industries and are the exception more than the rule.

The problem, as I see it, is not the end systems; it's the routers. I'll guess conservatively that 99.9% of the machines, be they servers or desktops or phones or what, attached to the Internet have no problems with IPv6. The problem is not the machines or the software, but the routers. It's changing slowly, but up until a year or two ago it was extremely uncommon to come across a router that did IPv6 out of the box.

Re:IPv4

[unixisc]

What % of boxes are legacy machines, legacy as in there-is-a-snowball's-chance-in-hell-that-it'll-ever-support-IPv6? I'd suspect that it's really low, and for such things, exceptions can be made, and they can be allowed to remain IPv4. But if a situation was created whereby anything that can upgrade must upgrade, this problem wouldn't be banging on our door today.

Re:IPv4

[Anonymous Coward]

All it takes is one piece of software that can't use IPv6 to be a problem. That software may be discontinued or continued.

If it happens to be discontinued, it may be that there is no suitable software to replace it, or at least not with the look and feel of the software some person or group has been accustomed to.

If it happens to be continued, there could be a multitude of reasons why some person or some group refuses to upgrade. It could be the expense, the look and feel not being the same, or perhaps it would take hundreds of hours to redo a bunch of other things intrinsically tied to the software.

Some would say if it isn't broke, don't fix it. I don't feel IPv4 to be necessarily broke. I feel it can survive along with IPv6 for as long as necessary.

Re:IPv4

[Anonymous Coward]

Of course you don't feel that it's broken, you have an IP address. If you no longer have access to a public IP address without paying extra, though, you might start having second thoughts about IPv4.

What?

[OverlordQ]

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

Re:What?

[Desler]

They were probably meaning that in light if the fact that ipv4 addresses are easily typed with only one hand on the numpad whereas ipv6 requires using shift and hitting colon.

Re:What?

[Anonymous Coward]

But it requires a chording input (Shift + other key) as opposed to a single keypress. That by definition is harder than a period or as Cerf suggests, a dash.

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?

[vlm]

They were probably meaning that in light if the fact that ipv4 addresses are easily typed with only one hand on the numpad whereas ipv6 requires using shift and hitting colon.

And the letters a thru f, most of the time.

I suppose a standard for ipv6 addresses using octal digits and dash - as spacer could work, but it'll be hard to share with the 16 bit boundaries of "standard hex". I'm thinking the only way to make those people happy, is a standard like this:

http colon slash slash 11111110110101001010101 ... 128 bits of binary ... 101010101000111/index.htm (gotta be a .htm extension for these types)

Re:What?

[notmyusualnickname]

*snerk*

Re:What?

[Anonymous Coward]

if you have to input IPv6 addresses at all (outside some very exceptional circumstances), you're doing it wrong

Re:What?

[Anonymous Coward]

Using the hyphen in place of the colon in URLs would still require the brackets or some other markup, because "fe80-123--1" could either be interpreted as an IPv6 address or as the domain name "fe80-123--1.whatever-my-domain-suffix-is.com"

Re:What?

[MaerD]

Because updating DNS zone files is a "exceptional circumstance" for an admin?

Re:What?

[jgrahn]

Because updating DNS zone files is a "exceptional circumstance" for an admin?

It seems to me that admins are in the tiny minority who can say s/\./:/g ...

Re:What?

[unixisc]

If somebody simply types in the address, without the colons, why not just have the software either insert them, or recognize them as such? Conversions of such texts are pretty trivial. Or in configuration files, when one is typing in IPv6 addresses, just allow one the option to type things like 200104580ace00530000000000000045? If one wants to eliminate those zero blocks, then make one type 2001:458:ace:53::45. That then simplifies the typing part somewhat w'o making programming, or the conversion of the above hex number to an IPv6 address a nightmare.

Re:What?

[unixisc]

If text files, like /etc/hosts is being updated, it's one thing. But if one is updating an IP in say Windows 7, having 4 fields in which to fill in the hex numbers solves the problem of the colons - one can just tab or shift-tab b/w fields Same for GUI apps that involve entering IPv6 addresses

Re:What?

[Anonymous Coward]

It is not that ':' is hard to type, it is that ':' is already used for a different purpose. And LOTS of software depends on this.

PORT=`echo $SOCKET|cut -d ":' -f 2"`

no longer works.

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.

Re:What?

[Anonymous Coward]

I am my OWN router, you insensitive clod!

Re:What?

[Bengie]

" especially when you're working on small disconnected networks with intermittent connectivity and doing lots of peer to peer traffic with embedded devices."

That's what static private IPs are for or just static public IPs for that matter.

fd::1 for one machine, fd::2 for another.. really, these address aren't that hard to remember or type.

Re:What?

[Anonymous Coward]

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

Which makes it one of the most difficult characters of all to type on a QWERTY keyboard. Why couldn't they just go with a semicolon? Or apostrophe? Basically any character that does not require the user to hold down Shift while typing.

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"

[Anonymous Coward]

Give this man a cigar. I've been saying this same thing for years... Eventually, IPv6 will happen on the public internet, but I cannot see a single, solitary advantage to a network administrator transitioning his internal network to IPv6. What do I get in exchange for weeks, months, or years of work, besides the eternal admiration of the IPv6 crowd? Because that doesn't really justify spending the cash-mountain.

NATv6 to v4 seems like an obvious, relatively simple to implement solution that allows us all to continue on as we have for the past twenty years without having to fork-lift upgrade/reconfigure the entire universe. Can you imagine the nightmare?

"Yes Grandma, but this one does IPv6!"

Give me a break. Whoever conceived IPv6 as an end-to-end solution was smoking crack. "End-to-end" connectivity isn't necessarily desirable to any but the most unsophisticated users, because everybody else has a network admin/engineer or consultant telling them how suicidally stupid such "end-to-end" openness would really be.

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"

[Pentium100]

Yea, I once used NAT to load balance between two connections (DSL and (legit) Wi-Fi) so that I could upload/download torrents faster. The router, when it detected a new outgoing connection just routed it to one of the connections and it worked. I could use uTorrents and achieved almost the sum of the speeds of both connections.

With IPv6 and no NAT, that would not have been possible, unless the ISP would agree to load balance it (and give the same IPs on both connections) and that is less likely than a hard drive with the contents of the torrent suddenly materializing on my table every time I download the .torrent file.

Re:IPv6 "hard". NAT "easy"

[Pentium100]

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.

Or if you have two connections (from the same or different ISPs) and try to load balance them or even just use one when the other one fails. And changing the IPs (well, at least on IPv4) breaks all established connections, local or not.

Re:IPv6 "hard". NAT "easy"

[Pentium100]

NATv6 to v4 seems like an obvious, relatively simple to implement solution

But how do you do it? there are more IPs in v6, so how do you map them to v4?

Re:IPv6 "hard". NAT "easy"

[Jonner]

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).

Why should it be necessary to ever change statically-allocated network addresses? The only reason that's necessary for IPv4 is that the addresses are scarce.

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.

As you say, the problem is the lack of a working DNS setup. Few people should ever have to be aware of IP addresses, including your parents. Multicast DNS already works great today with IPv4 and IPv6.

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.

The simplicity you want is already provided by the end-to-end model of IP (both versions) and broken by NAT. The only reason we must use NAT for IPv4 is the scarcity of addresses.

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.

You're proposing something fundamentally different from IP. What would it look like and what rationale do you have that it would be better?

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:IPv6 "hard". NAT "easy"

[unixisc]

I think the part that confuses here is that in IPv4, private addresses play two roles. One is local addresses within a LAN. The other is extensions, if you will, to routable addresses to ensure that it gets to the end point. The latter is like dialing a phone number and then dialing someone's extension, instead of a direct line. Re-numbering addresses, which is avoided by the admin since only local addresses are assigned in case the computers are behind a NAT, is something that's achieved using the first role. The second role - of having to re-number addresses is something that is inevitable if the organization changes networks (e.g. ISPs)

In IPv6, nodes are supposed to be capable of having multiple IPv6 addresses. Therefore, one can assign both routable and private addresses to them. Now, in IPv6, unlike in IPv4, there are different types of private addresses. The one that automatically gets installed when IPv6 support is added is link-local addresses - 0xfe80::/10, where an admin can do exactly what he does under IPv4. Only that in IPv4, one has to worry about whether to have a class A, or class B or class C private address, whereas in IPv6, he has the entire 2*118 addresses - I'm not in a mood to calculate that right now, but one gets the magnitude.

For the public addresses, the global prefix is all that is assigned by the ISP, which is the first 3 blocks (a /48). The subnet area belongs to the network (some ISPs may choose to give more than 48 to the global prefix, but the spec doesn't allow for more than 64.) The network admin gets to define the subnet address, and then the interface ID, which is the lower 64 bits. These are the global unicast addresses.

In both the above cases - link-local addresses as well as the routable addresses, a DHCP6 configuration can define/assign how addresses are to be distributed within a network. For the LAN part, it's easy - if one has, say 34 computers in the network, simply define their private addresses as fe80::1 to fe80::34. Or do something more elaborate, if one pleases. For the routable part, depending on what sort of addressing scheme one desires, do something similar, but have maybe a system whereby nodes that need static addresses get them, and the others get dynamic addresses within a certain range. So if a network has an address 2001:449:3fad as the global prefix, the admin could set DHCP6 up to have, say 6 networks, and map each network subnet to say, a department number. Let's say you have networks 1-6, for department numbers 7492, 4892, 4728, 3249, 2394 and 2349, it can be set up so that the addresses will be 2001:449:3fad:1:7492::y, 2001:449:3fad:2:4892::z and so on. That makes it more difficult for external IP scanning malware to track than if it were simply Network address::1,2,3... Bottom line - this assignment of IP addresses has to be done only once, whether it's in IPv4 or IPv6, and in the event that it needs to be changed often, it can easily be done on DHCP6. This attains end to end connectivity.

That then brings up the question of NAT. NAT6 does not exist - everywhere that NAT exists, it's solely for the sake of managing communications w/ IPv4 nodes, since the latter is what has a shortage. When there wasn't a shortage of IPv4 addresses, NAT was not used - not for security, nor anything else. Each node has to be protected, not only from external threats, but also potential malware being spread through the LAN - something that a NAT can never protect against.

I do agree w/ one thing, though - 8 bytes for a network size is overkill, and even for things like autoconfiguration, it's assinine to use schemes like EUI-64, which just export one's MAC address out of the network. If one thinks through this logically, using only 32 bits, instead of 64, as the interface ID would have been fine - even the largest subnets in the world ain't gonna have anything even close to 4 billion users. I think that instead, having a hierarchical structure, where the

Re:IPv6 "hard". NAT "easy"

[Anonymous Coward]

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).

Firewalls also decouple the network (i.e. NAT not required). As you mention below, they could natIPv6 to IPv6 and solve this problem ike they do now. Or better yet they can use IPv6 autoconfig, change the routers and dns (e.g. perl -p -i -e 's/oldprefix/newprefix/g zonefile) and be done with the local machines. Easier than changing IPv4 frankly.

They see the ISP giving them a prefix and changing that prefix willy-nilly causing lots of fun for everyone inside.

If the ISP changes prefixes will-nilly, they are doing it wrong. If the ISP changes how it routes addresses willy-nilly to a network's IPv4 addresses, that networked would be just as hosed (maybe even slightly more than with IPv6 prefix changes)

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.

Which as you mentioned earlier, they could do.

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.

Odd, most even relatively old printers should broadcast on the local network. That is, your parents sans-dns open a dialog and click on Epson-model# and they are done. Don't see why this would be any different under IPv6.

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.

I'd agree that hardware support is one of the bigger issues. Although backbone and ISP are probably the biggest issue. Frankly with autoconfig, it's not much different from NAT-DHCP boxes now for the home/small business user anyway. It will be a matter of plugging in the new box. If ISPs supported it, they could switch now. I'd also add that there is a transition and it's name is dual stack. I won't argue that the dual stack transition has been well planned (or maybe even 'planned' at all), but I do believe that is where we are going.

Re:IPv6 "hard". NAT "easy"

[unixisc]

Why should it be necessary to ever change statically-allocated network addresses? The only reason that's necessary for IPv4 is that the addresses are scarce.

No, the other reason for dynamic addresses is security - if your addresses change every time you log on, and you're not hosting a web server or anything like it, there's no reason to have a static address. In IPv6, one can have a dynamic address, again provided by DHCP6, just like DHCP4 does it for IPv4. If the ISP gives a new global prefix, they can simply substitute that for their existing global prefix, keeping everything else unchanged. I believe that's a part of what csnydermvpsoft noted above - except that everything gets automatically reconfigured.

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.

The simplicity you want is already provided by the end-to-end model of IP (both versions) and broken by NAT. The only reason we must use NAT for IPv4 is the scarcity of addresses.

I forgot to mention something while responding to GP - that end to end connectivity is not broken. End to end connectivity doesn't mean that there shouldn't be a firewall. End to end connectivity implies that the destination address of the packets that are sent should be that of the ultimate recipient. Under NAT, it's not. Imagine sending a letter to somebody, but in the address of the letter, instead of the destination being that person, it's some intermediate post-office who has the responsibility of looking up the recipients name, inserting his address and then taking it to him. That would be the physical equivalent of NAT. A firewall here would be something that sorts out for you your real mail from your junk mail.

Re:IPv6 "hard". NAT "easy"

[Anonymous Coward]

Well, your home router should be able to advertise a new route around the failing ISP without changing IP addresses.

Should be able.

That's one of the fundamental assumptions of the Internet, isn't it?

Re:IPv6 "hard". NAT "easy"

[Eunuchswear]

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.

Unfortunately many ISPs see this as a feature rather than a bug.

Re:IPv6 "hard". NAT "easy"

[Pentium100]

Well, except that the new ISP will not route the packets that have IP from the failed ISP to me. NAT router can just change the source IP of the packets, decoupling the internal IP from the external ones. The ISP will most likely not even send out the packets with the wrong (not their) source IP.

Re:IPv6 "hard". NAT "easy"

[jandrese]

Multicast was a requirement in v4 as well, and you see how far that got. The advantage of v6 is that it supports anycast, which is like multicast, except that it stops when it reaches the first recipient instead of getting delivered to every one.

Re:IPv6 "hard". NAT "easy"

[CAPSLOCK2000]

I think you have things reversed. Anycast works just fine with ipv4. On the other hand, IPv6 breaks if you disable multicast.

Re:IPv6 "hard". NAT "easy"

[Anonymous Coward]

not a bigger address space, for goodness' sake, but *better*

Why wouldn't a bigger address space be better? Set the size to 2048-4096 bits, and then simply issue everyone their own corresponding 2048-4096 bit certificate.

Re:IPv6 "hard". NAT "easy"

[jandrese]

Only router discovery, which is optional (you can manually configure your address and the next hop router if you like). IPv6 has the same problems with multicast that IPv4 does, namely that routing it is a big mess and nobody wants to do it unless they have to, especially on the internet. So it's fine for local discovery type applications (most routing protocols use multicast for this reason), but nobody wants to think about sending it past the first hop unless they really have to.

Re:IPv6 "hard". NAT "easy"

[unixisc]

Multicast in IPv4 is 224.x.x.x to 239.x.x.x i.e. 251,658,240 multicast addresses in all!!! How many multicast DNS servers would be there worldwide? In IPv6, all multicast addresses are ff00::/8, with the flag & scope following the ff, and then followed by the 112-bit multicast address. That would be around 5.1922968585348276285304963292201e+33 multicast addresses. That should be enough to tell one that just b'cos multicast didn't take off on IPv4 doesn't imply that it won't take off on IPv6.

Re:IPv6 "hard". NAT "easy"

[unixisc]

Actually, it's IPv6 that introduces Anycast, and drops Broadcasts.

A few privacy concerns

[Anonymous Coward]

why include the mac address? and why not have it more like IPv4 ie hexadecimal vs decimal for example

Re:A few privacy concerns

[Millennium]

Strictly speaking, IPv6 addresses don't include MAC addresses. Some developers tie it in because it's an easy easy way to get a unique host address, but it's not actually a requirement. Developers who do this should indeed be taken to task for a lazy solution that compromises user privacy, but the problem isn't inherent in the protocol.

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:A few privacy concerns

[Anonymous Coward]

Pluse you can usually change your MAC address anyway. It's actually part of some protocols like DECnet that different classes of hosts on the local area network are configured with MACs of particular forms. MAC addresses are not unique IDs, they're quite short and they're supposed to be user-configurable (user as in network admin) to allow you to pick what MAC addresses feature on your network without any conflicts. Oh, for some devices it may not be obvious how to configure them, but almost all devices ultimately support changing them somehow or they're unfit for purpose.

Re:A few privacy concerns

[antientropic]

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

Re:A few privacy concerns

[unixisc]

Later or not, it still resolves the issue of having to use EUI-64 in the address. I like random identifiers, but would those random identifiers be static or dynamic, and would they be stateless or stateful? I think a modification to EUI-64, which would mask random bits in the address for all nodes on a particular subnet would solve the issue of uniqueness (since most networks won't need anywhere even close to 64 bits for each of their nodes to be uniquely id'ed) as well as create enough possible choices that any malware has to pick from in determining the exact MAC address that the intrusion would be detected by whatever security the network has. Eg if 24 bits in EUI-64 were masked, that would create 16,777,216 different possible MAC addresses that would need to be examined to determine a match. If that's not good enough, increase the number of bits that need to be masked.

Biggest TCP/IP mistake

[phantomfive]

In my opinion the biggest problem with TCP/IP is that TCP is a stream protocol. Everyone who uses it immediately creates some sort of scheme to divide the stream into messages. Making it a stream protocol is logically equivalent to making it a messaging protocol with messages of size 1 byte. Maybe someone somewhere uses it as a pure byte stream, but it's not very common (and can be easily simulated over a message-based protocol).

Not that I blame Vint Cerf for that.....he created it, he didn't decide which parts would become popular.

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.

Re:Biggest TCP/IP mistake

[phantomfive]

Streams are just as trivial to implement on top of messages as the other way around. In fact, that's exactly what TCP is. But it is slightly painful to implement either one on top of the other, and since 99% of the time people want messages, logically that should have been the default.

Also, I seriously doubt (I'm giving you credit as a network programmer here) that you would have implementing one type of messages on top of another type of messages, since network programmers do it all the time. As questionable as such designs may be, they now have to implement one message type on top of another message type on top of a stream, whereas they could have just implemented one message type on top of another message type.

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:Biggest TCP/IP mistake

[Anonymous Coward]

So, how do I send a 20MB message without using a stream protocol? You do realize that UDP is a lossy protocol?

UDP is well suited for real-time data and real-time streams, where loss of a few packets does not affect the application. Think games, streaming audio/video, sensor data, multicast, etc. TCP is more suited for applications requiring guaranteed delivery. Furthermore, UDP should not be used for bulk data transfers. Congestion control is built into TCP, but it is not part of UDP. It would have to be built into the applications.

Honestly, your comment is not well thought out. You might as well call file systems a failure because people store files, like XML, as a stream of bytes while each part of the XML is separate part of a message. Why not store XML as a file hierarchy instead with each node's text() and attributes being stored in appropriate files?

Re:Biggest TCP/IP mistake

[phantomfive]

UDP is even worse as a message passing system, because it isn't reliable. If you don't mind that, it's great, though. The stream problem is the one that causes me the most pain in my life.

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

Re:Biggest TCP/IP mistake

[phantomfive]

Even though the essence of the protocol is simple, many implementers would still get it wrong.

No. Getting reliable, inorder message transfer is difficult. Implementing a stream on top of reliable inorder messages is simple as pie.

Re:Biggest TCP/IP mistake

[Arlet]

Why would the stream problem cause problems ? It's not that hard to transport messages over a stream. A trivial solution would be to the send the message length, followed by the message.

Re:Biggest TCP/IP mistake

[Arlet]

Getting reliable, inorder message transfer is difficult

That's probably why it wasn't done. The beauty of TCP/IP is it's simplicity, and that's probably also why it was so successful. For most applications, the stream model works fine, so why would it be better to implement a more complex message transfer protocol instead ?

Re:Biggest TCP/IP mistake

[Anonymous Coward]

Datagram based protocols, by nature, have size limits. If you want to send something of an undefined size, a stream is the way to go. In the datagram model, you can break it up into chunks, but then your essentially implementing a stream.

Re:Biggest TCP/IP mistake

[Sir Homer]

TCP is simple to use (from the view of someone doing network programming), but under the scenes it is crazy complicated to implement properly.
 
  Fortunately you really only need someone to implement a TCP stack once (in open source) and it can be reused in a multitude of operating systems. BSD pretty much set the standard for a TCP/IP stack (TCP Reno) and everyone went from there.

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.

Re:Biggest TCP/IP mistake

[Arlet]

The core of TCP, as its original RFC 793, is quite straightforward. The many later additions have made it more complicated, though.

Re:Biggest TCP/IP mistake

[Jonner]

In my opinion the biggest problem with TCP/IP is that TCP is a stream protocol. Everyone who uses it immediately creates some sort of scheme to divide the stream into messages. Making it a stream protocol is logically equivalent to making it a messaging protocol with messages of size 1 byte. Maybe someone somewhere uses it as a pure byte stream, but it's not very common (and can be easily simulated over a message-based protocol).

Not that I blame Vint Cerf for that.....he created it, he didn't decide which parts would become popular.

Yeah, the most commonly used Internet application protocols aren't stream protocols. That is, unless you count HTTP and SMTP. You also might want to study up on this new-fangled thing called UDP.

Re:Biggest TCP/IP mistake

[Jonner]

Streams are just as trivial to implement on top of messages as the other way around. In fact, that's exactly what TCP is. But it is slightly painful to implement either one on top of the other, and since 99% of the time people want messages, logically that should have been the default.

How can you say that messages aren't the default orientation, since IP is a message-based protocol? For implementing applications, TCP and UDP have equal footing. The fact that TCP is far more used implies that your 99% figure was pulled out of your ass.

Re:Biggest TCP/IP mistake

[jgrahn]

In my opinion the biggest problem with TCP/IP is that TCP is a stream protocol. Everyone who uses it immediately creates some sort of scheme to divide the stream into messages.

Yeah -- but dividing it in a way which suits the problem they want to solve. I'm not at all convinced that it's feasible to design a simple and safe "one size fits all" reliable datagram protocol.

And I'm very unimpressed by the UDP-based protocols I've seen: slow, fragile, constant problems with a fast sender overloading a slow receiver, inefficient stack--application interfaces ...

Re:Biggest TCP/IP mistake

[petermgreen]

Traditionally a "TCP/IP stack" gave two main options for applications.

* an "unreliable", non congesion-controlled and non-connection based message based protocol with limited message sizes and no message aggregation (UDP)
* a "reliable" congestion controlled, connection orientated stream based protocol (TCP) .

So the path of least resistance for most applications was to turn their messages into a stream so they could transmit arbitary sized messages and take advantage of the "reliable", connection orientated nature of TCP. This works tolerably but it less than ideal, for example if a packet is lost then it delays messages in subsequent packets as the processing to turn packets back into a stream must happen in-order.

SCTP provides a richer interface that avoids this deficiency. Sadly it came along too late to have much impact. Apps that couldn't tolerate TCP had already built custom soloutions on top of UDP

Re:Biggest TCP/IP mistake

[phantomfive]

And I'm very unimpressed by the UDP-based protocols I've seen: slow, fragile, constant problems with a fast sender overloading a slow receiver, inefficient stack--application interfaces ...

UDP WOULD be a great message based protocol, if they had implemented ordered reception, resending, flow control, etc. These are reasons to use TCP over UDP, and they are good reasons. But if UDP had them, it would be used much more often than TCP.

Re:Biggest TCP/IP mistake

[phantomfive]

Your comment makes me wonder if you've ever written a network program. You do realize that if you call read() on a TCP socket, you are only guaranteed to get one byte, right (assuming no errors, etc)? It's called a stream based protocol for a reason, because it simulates a byte stream on top of the ip packets.

Re:Biggest TCP/IP mistake

[phantomfive]

HTTP and SMTP are message protocols built on top of TCP. That means you have to go to the extra effort to divide the TCP stream into packets. Which was exactly my point.

UDP sucks unless you can accept dropped packets, out of order messages, and don't care about flow control. If you're ok with all of those, then it's fine. But that situation is rare.

Re:Biggest TCP/IP mistake

[phantomfive]

I didn't say that TCP is trivial. I said that message based protocols are better than stream based. This is independent of whether said protocol has error correction, flow control, and guaranteed order. Please work on your reading comprehension.

Re:Biggest TCP/IP mistake

[phantomfive]

It causes problems because every time I ever want to do network programming, I have to implement a scheme for setting up message sizes. It's more than just setting the message length followed by the message because then you have to set up a read loop to make sure you got the entire message.

Of course there could be worse things, but it is the problem with TCP that causes me the most problems.

Re:Biggest TCP/IP mistake

[unixisc]

But UDP is really good for Teredo, which enables a IPv6 packet to get encapsulated in an IPv4 UDP datagram and get forwarded by the NAT to the ultimate destination address w/o IPSEC getting mangled. As a result, a host implementing Teredo can gain IPv6 connectivity with no cooperation from the local network environment.

Re:Biggest TCP/IP mistake

[phantomfive]

Yeap. UDP sucks unless you can accept dropped packets, out of order messages, and don't care about flow control. If you're ok with all of those, then it's fine. But that situation is rare.

Re:Biggest TCP/IP mistake

[Bengie]

While processing "messages" is easier than a stream for any case where the message is small, what about a message that is larger than a packet? Suddenly you need a layer on top of IP again. So now you have message on message instead of stream on message.

In order to process message on top of message, you have to treat it as a stream. So instead of stream on top of message, you have message on top of stream on top of message.

Now if you wanted to have implement a stream interface, you will have stream on top of message on top of stream on top of message.

It's just easier to have stream on top of message and let the programmer decide who to process the data.

Re:Biggest TCP/IP mistake

[Bengie]

"I have to implement a scheme for setting up message sizes."

ROFL

Lets give a scenario where you want to send message like you're talking about. Say you send 1400 byte messages.

1) You send 1400 bytes
2) OS packages it up into a single packet and sends it out.
3) OS gets ICMP about fragmentation
4) OS splits up original message into two packets
5) Receiver gets two packets

Now, should your app see one message or two messages?.. I'm leaning towards 1. What does this mean? It means at the very basic network stack level, it will have to treat TCP/IP as a stream because it never knows how large the messages will be from packet to packet.

If you want to have a "message" based TCP, then implement your own libraries, but at the OS/Network level, packets are processed as a stream because you NEVER know how much data you will get from packet to packet.

From my perspective, most everything I do now days is working with streams. Treating TCP as messages would be more complicated for me than just doing everything as a stream. Almost any time I've moving data around, it's as a stream. The default of TCP as a stream just makes it really easy to plug into.

Re:Biggest TCP/IP mistake

[Bengie]

TCP is just a super-set of UDP. I don't see the problem. Implement your own protocol on top of UDP.

If TCP was message based, how would you handle messages that are larger or smaller than a packet's payload capacity? A smaller packet will have wasted space, so you're better of including "part" of the next packet. If it's a larger packet, you'll have to fragment the message across more than one packet.

Suddenly we're right back to not working with messages, but partial messages. Guess what's a great way to read partial messages?... STREAMS!

I would love to see programmers abuse a "message" based TCP protocol. I'm going to send this file across as a "message"... Yay, buffer an entire 10TB file into a message... How I love streams.

Re:Biggest TCP/IP mistake

[phantomfive]

This is pretty dumb. I can think of three ways to resolve this 'problem' in about 30 seconds. Whereas you apparently can't think of any. Therefore, you are pretty dumb.

Vendor support for home routers

[Anonymous Coward]

I work at a relatively large ISP in south Europe, and i can tell you that we are fully ready for IPv6 except for one thing: home gateway IPv6 support. Our vendors (three of them, all well known companies) simply do not have the firmwares that support IPv6 for broadband modems yet. Sad, but true.

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:Vendor support for home routers

[gurubert]

I am using a standard AVM Fritz!Box that includes IPv6 firmware with tunneling support: http://avm.de/en/Produkte/FRITZBox/FRITZ_Box_Fon_WLAN_7270/index.php

Nice.

[sootman]

> What do you think we can do to
> convince ISPs to start rolling out
> IPv6 [i]before[/i] there is a crisis?

Slashdot editors: they put the 'k' in 'quality'. :-)

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:IPv6

[BeforeCoffee]

Aren't there gobs of address blocks reserved for ISP's to talk to one another? Perhaps ISP's could lead the way by converting their back-channel host addresses over to IPv6 and then release those blocks for public site use? Are there really 2 or 3 billion IPv4 internet addresses serving public clients?

Perhaps IPv4 running out of available addresses is the necessity that will push the experts, at least, to convert over to IPv6...

Re:IPv6

[Bengie]

You should've asked him what he would've done once he ran out of IPs. It'll cost more to do ISP level NAT than upgrading to IPv6.

Either way he's going to have to pay money, but the "proper way" (IPv6) will be cheaper in both the short and long run.

Re:IPv6

[phantomfive]

His plan was to start rolling out IPv6. His ISP is unusual in that it doesn't NAT at all, he gives all his customers static IPs. I think most ISPs are planning on doing IPv6 after they run out, though. It really does make more sense economically, as you mentioned.

Re:IPv6

[unixisc]

Why? What's the point of keeping them, since there is an annual subscription associated w/ these addresses. His ISP could either return them to ARIN (I'm assuming that's the RIR in question here), or, if they want more money for it, do what Nortel did w/ MS and sell them. ARIN is quite interested in getting back as many IPv4 addresses that it can to have it available for people who can't move to IPv6 and need to have IPv4 addresses. So if they are capable of migrating sooner, why wait?

The only rational reason I see is that the ISPs may not be willing to spend the money now, which begs the question - do they plan to go out of business when they run out? B'cos it'll sure be more expensive then, when everything is important and urgent, instead of just important. Otherwise, since they know that they're going to, in the end, transition to IPv6, it'll be immaterial whether they spend the money on the transition now or later. In fact, chances are likely that they'll be guzzling money later when there are critical shortages of IP addresses. Otherwise, buy whatever equipment is needed now, and come up with either dual stack or dual stack lite solutions. In fact, this solution would be even cheaper than IPv4, since he'd be getting much larger IPv6 blocks than IPv4, and would therefore have a lot more of them.

Re:IPv6

[phantomfive]

Maybe, but I'm pretty sure he's thought of all that. Apparently the cost of holding onto IPv4 addresses is worth the ability to have them 1.5 years from now. It's not like you can get more if you need them.

LOL usage approved by Vint Cerf

[TheLink]

So now we can use LOL and say "hey Vint Cerf uses it in public correspondence too!". :).

p.s. Too bad he didn't seem to understand my question. Oh well.

Re:LOL usage approved by Vint Cerf

[Greyfox]

No, he did understand the question. "Any way to generate a 32 bit number... because the text address isn't used during the connection process," could not be clearer. Indeed, the text address is not even a necessary part of the internet. It's a convenient directory service that is widely used by clients, but it is in no way essential to the functioning of the network itself. That's always what bothered me about that bug. They're essentially replacing the numeric-format addressing with a text mode one that the protocol doesn't even use. And they had to have gone out of their way to have their address parser intercept addresses in that format, because if you pass a string with a number in it to gethostbyname, it'll damn well return an address.

He was a little less explicit about giving me permission to go write non-http applications but I'm going to take "I know what you mean" as such, so I'm off to write a program to deliver satellite orbits to any application that can open and write to a network socket! Sure that'd be great as a REST service, but I don't feel like installing Apache just to deliver a number!

Re:LOL usage approved by Vint Cerf

[TheLink]

Yes he did understand your question. But that was not _my_ question which was a the ".here TLD?" one.

Anyway, your reply and his just shows that what I write is hard for people to understand. Dunno why.

Regarding your question, I wonder how should "numeric only" IPs work if a browser supports both IPv4 and IPv6? The two address ranges would overlap. So would numeric-only IPs mean IPv4 only?

BTW: on some OSes you can ping 4.8. Which isn't a numeric only IP address, so it's even messier than that ;).

Re:LOL usage approved by Vint Cerf

[Anonymous Coward]

Should be able to enter it as "ten dot one ninety two dot thiry dot fifty five" as well. Kind of like putting a date in PHP. As long as it can be parsed as a date it's valid. As long as it can be parsed to produce 32 bits, it's valid.

Re:LOL usage approved by Vint Cerf

[Anonymous Coward]

I LOL'd when I saw Bruce Ide's recent update to the OSX Firefox bug tracker.

Re:LOL usage approved by Vint Cerf

[Greyfox]

Oohh sorry didn't see the the second LOL down there toward the bottom. It seems the father of the internet is a cheerful sort of guy. Kind of like Father Christmas. You don't suppose they're the same guy? They both deliver stuff very quickly world-wide...

Re:LOL usage approved by Vint Cerf

[Coren22]

The .here TLD you are talking about didn't make much sense to me either, but I think what you are looking for is .local which is what I was taught to use in MCSE classes.

http://en.wikipedia.org/wiki/Top-level_domain#Pseudo-domains

The top-level pseudo domain local is required by the Zeroconf protocol. It is also used by many organizations internally, which may become a problem for those users as Zeroconf becomes more popular. Both site and internal have been suggested for private usage, but no consensus has emerged[citation needed].

So apparently it isn't a standard, and can break zeroconf.

Re:LOL usage approved by Vint Cerf

[TheLink]

So apparently it isn't a standard, and can break zeroconf

That's why I said: "a .here TLD, reserved officially for local use" and "analogous way to the way that the RFC1918 IP addresses are reserved officially for private use".

If RFC1918 IP addresses didn't exist people could have used arbitrary IP ranges they hope won't conflict. The same reason why RFC1918 is a better idea than that, is the same reason why there should be a .here or similar TLD.

Once you have a standard, others can build upon it. For example: many areas might allow you to visit http://here/ so that you can get a list of publicly advertised stuff/people that you can interact with.

This sort of thing can make it easier for you to do virtual telekinesis in different areas, and not just in places you are "accustomed" to (home, office).

I have proposed this type of TLD to the ICANN (back when Vint Cerf and Esther Dyson were there) and also the IETF. But the ICANN prefers to keep inflicting "Yet Another dotCom TLD money grab" on us.

Re:LOL usage approved by Vint Cerf

[Greyfox]

Yep, that's me! I thought about saying "He's the father of the Internet, you know? What are YOU the father of?" But I thought that might come off as snarky. I haven't updated my user page in a while since I'm currently living in an internet ghetto without a static IP. Having to manage my own mail server was a huge pain in the ass. Can't say I miss it.

Feel free to explore my github page, or my Star Trek fanfic about a homoerotic encounter between Picard and Q, which I wrote back in the 90's. Please don't sue me, Paramount!

Re:LOL usage approved by Vint Cerf

[swillden]

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

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

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

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

Re:LOL usage approved by Vint Cerf

[Anonymous Coward]

Yes he did understand your question. But that was not _my_ question which was a the ".here TLD?" one.

Anyway, your reply and his just shows that what I write is hard for people to understand. Dunno why.

Regarding your question, I wonder how should "numeric only" IPs work if a browser supports both IPv4 and IPv6? The two address ranges would overlap. So would numeric-only IPs mean IPv4 only?

BTW: on some OSes you can ping 4.8. Which isn't a numeric only IP address, so it's even messier than that ;).

I see other people already addressed your .here TLD.

Numeric only addressing in any resolver should not be a problem. If the value is 128 bits long, it is an IPv6 address, if it is 32 bits it is IPv4. I guess intermediate values should probably be ignored. You mention the address spaces overlap. This is only in the case where all the upper bits of an IPv6 address are zero.

The whole ::/8 range is reserved so that is not a huge issue in general. However things like loopback (::1) should probably be handled as special cases. Additionally there is a range ::IPv4/96 (where IPv4 is an IPv4 address, 32 bits long) which is reserved specifically to allow carrying an IPv4 address in an IPv6 address data type: http://tools.ietf.org/html/rfc4291#section-2.5.5

I hope that answers your concerns about address space overlap, or at least gives you a place to start.

Finally, great stuff on the 'ping 4.2' "feature" I had not noticed that before :D

Re:LOL usage approved by Vint Cerf

[TheLink]

For identifying nearby hosts with names, the .local TLD already exists.

Which Internet standards document or similar says that .local is a TLD reserved for such use? As far as I know .local is not reserved after so many years.

And because of all the messiness, it's probably best to reserve .local for "local legacy" use (mDNS etc), and start over with .here OR some other tld for a proper "reserved for official local use" TLD, which could resolve to standard local use IPv6 and IPv4 addresses as you suggest.

Re:LOL usage approved by Vint Cerf

[TheLink]

BTW:
1) I don't see where I made a comparison to E911.
2) much of your talk about IPv6 is not really relevant to domain names and TLDs.

Hardly any user in the world is going to type IPv6 addresses.They're going to type domain names. So if they want to figure out what is available in a particular room/hall/building, what is the way for them to do so without forced HTTP/DNS packet redirection and other hack jobs?

Colons

[Anonymous Coward]

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

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

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

so use UDP

[Chirs]

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

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:so use UDP

[phantomfive]

I've used SCTP before. It's a fine protocol, but implementations are buggy, and as vlm said, there are problems with proxies, firewalls, etc.

Re:so use UDP

[Jonner]

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.

Let me get this straight. You're trying to blame poor service from "scummy" ISPs on the easiest to use Internet protocol built on IP? You need to revisit your history if you think that it has been industry standard to run everything over TCP port 80. Last time I checked, TCP port 80 is used for exactly HTTP. There are certainly plenty of bad ideas out there, but TCP wasn't one of them.

Re:so use UDP

[Anonymous Coward]

Umm - 20 years ago was 1991. In 1991, HTTP did not exist, and the US Internet backbone was not yet privatized and publically available.

So - how then has this been feasable, let alone standard for the 'last 20 years?' ?

clearly, you do not know much about what you are talking about

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:Problem with .here

[srg33]

Admittedly ".test" is not pretty, but it is already a Reserved Top Level DNS Name per RFC 2606.
I also read Yeoh's draft. It really has no restrictions and as such the idea of bookmarking a name that has no guarantee of working anywhere else is self-defeating. For example, "https://airconditioner.here/settemp?celsius=25" is probably not very useful in a large room with multiple A/C units. Should that local DNS have every alias/synonym for airconditioner? His idea of "all.here" etc. giving "a list of registered devices" has some merit. But, how about "all.test" or "devices.test" or even "nodes.test"?

Re:Problem with .here

[Anonymous Coward]

my /etc/hosts has localhost.localdomain never heard of localnet.

Re:Problem with .here

[Anonymous Coward]

I read the question differently. Not a private tld, but a localized one. So that if you are physically in Chicago and go to movies.here, you would get a different site that when you did the same thing in Toronto.

ISPs and IPv6

[Anonymous Coward]

I work for an ISP that will roll out an IPv6 only network mid-next year. Each customer will have a /64 for their house to use as they please.

Re:ISPs and IPv6

[unixisc]

I thought that Hurricane Electric already does that, and Comcast too has plans to go to dual-stack-lite i.e. have an IPv6 only network, and for IPv4 customers, have LS-NAT, where each private IPv4 address is mapped on to an IPv6 address and that mapping resides on their routers. But I'm glad that your ISP has such plans. It would be good if all ISPs went the IPv6 only route, and supported IPv4 through dual-stack lite or tunneling.

IPv6 Autoconf & DHCPv6

[gurubert]

I am missing a question and an answer: Why is IPv6 autoconf missing such basic features as providing information about DNS servers?
Or the other way round: why did nobody think about central management stuff that DHCPv4 provides in corporate networks? DHCPv6 is nowhere even barely usable.

Re:IPv6 Autoconf & DHCPv6

[vividvew]

I am missing a question and an answer: Why is IPv6 autoconf missing such basic features as providing information about DNS servers? Or the other way round: why did nobody think about central management stuff that DHCPv4 provides in corporate networks? DHCPv6 is nowhere even barely usable.

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.

Re:IPv6 Autoconf & DHCPv6

[bbn]

You need to understand the coupling between "autoconf" also called SLAAC (stateless address autoconfiguration) and DHCPv6. SLAAC is used when the network has active routers with a RA daemon but no DHCPv6 server. The RA daemon is nothing but a router announcing its presence and the subnet it will route. Any extra information is retrieved from a possibly stateless and possibly non-local DHCPv6 server by multicast.

The idea is that RA gives you enough information to communicate with the DHCPv6 server. It is not intended to be a replacement for DHCPv6. In fact it is a required part of DHCPv6.

Someone figured that it would be possible to do entirely without DHCPv6 so they allocated one bit in the RA response for that case. Of course that is not so useful if you need information such as DNS.

Later DNS information was added to the RA response. Not all clients supports this however, so it is still recommended to run a (stateless) DHCPv6 server to provide that information.

It should be trivial to implement a stateless DHCPv6 server along your RA daemon so I am not sure why everyone makes this a problem.

Re:IPv6 Autoconf & DHCPv6

[bbn]

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

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

Re:IPv6 "hard". NAT "easy

[Anonymous Coward]

Give this man a cigar. I've been saying this same thing for years... Eventually, IPv6 will happen on the public internet, but I cannot see a single, solitary advantage to a network administrator transitioning his internal network to IPv6.

Well I'll go for a couple obvious ones
- You can't get any IPv4 addresses. (NAT to IPv4 locally when your communicating IPv6 globally is somewhat pointless)
- You want to directly communicate to someone with IPv6 addresses

What do I get in exchange for weeks, months, or years of work, besides the eternal admiration of the IPv6 crowd?

Your both doing it wrong and for the wrong reasons.

NATv6 to v4 seems like an obvious, relatively simple to implement solution that allows us all to continue on as we have for the past twenty years...

Yes, try to talk to one of those IPv6 addresses from your IPv4-only box.

Give me a break. Whoever conceived IPv6 as an end-to-end solution was smoking crack. "End-to-end" connectivity isn't necessarily desirable to any but the most unsophisticated users, because everybody else has a network admin/engineer or consultant telling them how suicidally stupid such "end-to-end" openness would really be.

It is perhaps suicidally stupid if you run Windows or if you don't have one of these hi-tech-cutting-edge-technology-that-only-the-elite-have-heard-of called... firewalls.

Having to hide behind your multiple NAT boxes, curled up under your desk with your Window-x box clutched tightly in your hands while mumbling something about "strangers bad" doesn't sound very sophisticated to me.

Easy squash...

[Gription]

"Let's blame legacy machines" is an incredibly silly idea and it is so easy to prove how dumb it is.

Legacy Systems = "Old stuff"...
Now tell me how fast is the quantity of "Old stuff" increasing? Who is making the new "Old stuff"? (gaaak!)
(Where can I find the next generation of really old stuff? ...)

IPv6 HW forwarding

[Anonymous Coward]

Switch and router FW ASICs already do IPv6. There are gaps in feature support for IPv6 in the ASICs but that's b/c no one cares very much yet but the basic HW forwarding for IPv6 has been there and supported for years.

IP addresses in URLs

[Onymous Coward]

At first I thought you were right, but I wanted to confirm it so I dug into the issue further.

RFC 2396, regarding URIs, states that URI authority hosts look like so:

host = hostname | IPv4address
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit

It exactly specifies the manner of IPv4 address representation, constraining it from the wide world of possible ways to format a 32 bit number. Whether represented as

• 3626153261 (decimal)
• 033010532455 (octal)
• 0xd8.0x22.0xb5.0x2d (hex dotted quad)
• or even 0330.34.0xb52d (mixed dotted triad) (this and the dyad are interesting cases)

the point is not about equivalency. And the point isn't about the underlying libraries and whether they can recognize this variety of representations.

The point that really needs addressing is "Which representations work best for URIs?"

Whether the RFC authors (including Berners-Lee, if celebrity makes authority) intentionally constrained host IPv4 addresses from the range of possibilities or whether it didn't occur to them to allow the range of library-supported values is hard to say. I'm guessing the former. But anyway it's moot, and, again, we should be addressing the appropriateness for the protocols at hand, HTTP etc., not IP and general reckoning of addresses.

The Firefox guys seem to be getting it right. They're keeping an eye on the RFC, they're looking at the benefits and penalties, and they're coming down on the side of the simple, common convention. Limiting URI host addresses to decimal dotted quads is not "a fundamental misunderstanding of what an IP address is". It's a(n HTTP) protocol interface/usability decision.

I'm genuinely sorry about the loss of the ability to specify IPs in their myriad ways in Firefox (and other browser) URLs. I myself rather enjoyed showing people how this worked. You have my sympathy for the loss of the clever teaching tool. I can only suggest you use ping for your demonstrations.

Re:IP addresses in URLs

[Greyfox]

Yes yes yes, they have an RFC. And I have the father of the internet saying "Text addresses are not used during the connection process"! They're not part of the protocol. Elevating an answer from a directory service to protocol level is not the direction we should be going in!

I do, however, have a workaround, and that's to register the numeric address as a ".com". 1137387091.com! And then I thought, why not register a different address than what that would point you to? Then all other client programs would go to a different address than OSX firefox, which would append a dot-com to the end! I think that's an excellent idea!

Re:IP addresses in URLs

[Onymous Coward]

I acknowledge that you are being funny.

I worry, however, that you will still retain an element of seriousness when you, in the future, summarize this matter the way that you are currently.

Text addresses are used in URLs. That's part of the HTTP protocol. The father of the web said we should use decimal dotted quads, so your browser does not take all representations of addresses for URLs. Rest assured that when your browser gets around to making its connections it's not using a text address. But when we speak HTTP, including in the browser address bar, we say a.b.c.d.

Cerf's 'LOL' was epic, I have to say. Even if he didn't understand the issue. Please don't bother the browser developers further.

Re:IP addresses in URLs

[swillden]

There are important security reasons for not allowing too many representations for a host address, and there really aren't any compelling motivations for allowing it. The FF guys are right, and Vint didn't really contradict them; he just said that in the low-level protocols it's a pure number. That has nothing to do with the UI considerations that drive having a single, consistent representation.

IPv6 + mobile devices

[vividvew]

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.

Re:IPv6 + mobile devices

[TheLink]

Right now NAT is such a huge barrier to end to end communications that other problems with TCP still get more ink.

Where you see a barrier, others see a layer of abstraction.

no-NAT IPv6 end to end addresses puts in place most of the foundation for truly constant mobile connectivity

What if you want to move a friend's device from using his internet connection (out of credits) to using your mobile phone's internet connection?

Do you:
a) Go without NAT and wait for all the required routers in the world to figure out where your friend's device now is, so that they can still send packets to its IPv6 address but now located in a different ISP's network? Good luck with that.
b) Get your friend to sign up for all the ISPs to get all the necessary multiple IPv6 addresses for multi-homing?
c) Use NAT and share the connection? Yes this can break your friends connections, But he can actually make new ones (whereas with a) and b) he might not be able to). Another thing, if your friend uses a VPN service through your NAT, your friend can keep his endpoint IP addresses and not break connections, despite hopping from different NAT connections or nonNAT connections. With this the ISPs and their devices don't have to be informed of any configuration or routing changes.

Despite what all the "ivory tower academics" think
there are many reasons to use NAT in the real messy world out there.

Re:IPv6 + mobile devices

[unixisc]

In IPv6, the friend's device would do a neighbor discovery, and get a global prefix automatically. All routers in the world wont figure out the friend's device, only that particular router. That's b'cos in IPv6, a device is allowed to have multiple IPv6 addresses (unlike w/ IPv4), so the friend's device will use the address that's within the network whose signals it's getting @ any point in time.

Re:IPv6 + mobile devices

[TheLink]

1) You're mistaken. In IPv4 a device can have multiple IP addresses, in fact most IPv4 devices have multiple IP addresses. The issue is ISPs usually charge you more for public IPv4 addresses if you want more. So how many real world ISP would allow users to use multiple IPv6 addresses without charging extra?
2) using the new IP address will cause non-SCTP connections to break. That does not necessarily happen for the "c) via VPN" scenario.

And I'm not too sure about the security of SCTP connections. Since you can use a different IP address to resume your connection, if there are security bugs or weaknesses, someone else might be able to "resume" your connection ;).

Re:IPv6 + mobile devices

[vividvew]

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.

Re:IPv6 + mobile devices

[unixisc]

1. In IPv4, ISPs would charge you more for routable IP addresses b'cos they assign only a /32 to you. But in IPv6, an ISP is supposed to assign a /64 to users, not a /128. But that's not so much the point here, since we are talking about mobile carriers, who are going to assign /128 to all devices in any subnet. What happens here is that a customer will get a publicly routable end-to-end link while switching b/w networks, no matter whose IPv6 network they are on - there will never be a shortage of such addresses, so the carrier will happily provide an IP for each subnet that one happens to be in. But in IPv4, carriers just don't have such routable addresses to loan out for their entire subscriber base. That's one of the main reasons that IPv6 is more promising for Mobile IP than IPv4 - if a mobile network were to offer you something like 10.1.2.3 behind NAT while you were driving, how does your phone know that since you are in 123.45.67.89, your address should be 10.1.2.3, and when you go to 98.76.54.32, it needs to change to 172.20.9.8? With IPv6, it'll at least recognize common prefixes, and can work from there. Are you going to have NAT mappings on the phone as well, in addition to on the router? :-)
2. Why would non-SCTP connections break? As for the security, in this case, autoconfiguration is used, so the router knows something unique about the phone, maybe its IMEI#, so unless a phone was stolen, it's not necessary that someone else will be able to 'resume' the connection.

Re:IPv6 + mobile devices

[TheLink]

Why would non-SCTP connections break?

Because TCP and UDP connections are: IP address+Port to/from IP Address+Port.

So if you change the IP address, you have to make new connections. You cannot continue using the old connections.

Router price/performance and mgmt apps

[billstewart]

A big problem for years was the price/performance of routers that were big enough to run large businesses or medium-large ISPs - they'd use hardware acceleration for IPv4, but didn't have anywhere near as good performance for IPv6, even if they had hardware support and weren't doing it all in software. And there was a big chicken-vs-egg problem of getting ISPs to spend more for fast IPv6 hardware when there wasn't enough IPv6 demand, while customers weren't pushing to go to IPv6 because few ISPs supported it (and content providers didn't feel the need to move when consumer ISPs weren't serving them eyeballs over IPv6, and consumer ISPs didn't move to IPv6 when there wasn't enough content.)

These days the big hardware has largely caught up - but consumer hardware for the home hasn't. That DSL router or cable modem runs on firmware, not remotely upgradeable hardware, and your $29 WiFi router doesn't know from IPv6, much less dual-stack, and your ISP doesn't want to deal with the customer support issues it'll take to get all their customers to upgrade. You'd think that at least all the 802.11n wireless gear would have done IPv6, so upgrading from g to n would also fix the problem, but nope - my Cisco Linksys stuff didn't, and I don't know if Netgear or DLink have caught up yet, much less random cheaper brands.

The other big problem is all of the management applications that it takes to run an ISP, web hosting service, or large business. There may not be quite as many 32-bit IP address fields stuck in random databases or printf statements as there were 2-digit dates before Y2K, but there are a lot. I work on managed network security services, and we need to deal with every router, firewall, IDS, and switch that we support to make sure that all of our databases and support systems and that perl script you wrote 5 years ago to automate monitoring the status of some widget all can work over IPv6. Vendor support is getting better, but I'm still running into products where you can connect to the management port over IPv6 if you need to, but the web GUI page where you put in the addresses of the trusted vs. untrusted sides only knows IPv4, or where some application lets you filter on arbitrary IPv4, ICMP, TCP, and UDP values (but not only doesn't do IPv6, but also forgot that ARP isn't IP either...)

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.)

The MAC address tracking problem

[billstewart]

There are two problems with using MAC addresses in IPv6 addresses making it easy to track - tracking you when you're in one place, and tracking you when you move around.

Tracking you in one place - in a typical IPv4 environment, there's a firewall that hides inside addresses behind NAT, so there's no obvious correlation between a public IP address and the actual machine behind it. Somebody may know that a connection came from a specific company or a specific Starbucks, but that doesn't identify the user, unless the firewall is managed by somebody who tracks that kind of thing. Of course, that's partly because NAT is breaking the end-to-end principle of the Internet in fundamentally evil ways, but it turns out that being evil wasn't all bad. And Microsoft and others have adopted IPv6 privacy mode, which lets your machine use different IPv6 addresses for every connection, which is kind of nice.

Tracking you in multiple locations - Computers aren't just for desktops any more - laptops etc. are portable. In a DHCP world, even if everybody used registered addresses instead of NAT, you can take a machine from home to work to Starbucks to a friend's house, and it'll get a different IP address at each location, with no correlations to show that you were at all those places, because the IPv4 address block belongs to the wired connection. With IPv6, each of those locations would have a different 64 network bits, but the 64 host bits are always your laptop's EUI-64 address, so somebody can track that it's you at all those place. On the other hand, IPv6 privacy mode helps that, and all of those cookies and flash-cookies and ever-cookies and browsers advertising your whole font collection mean that it was going to be pretty easy to track you anyway.

Re:The MAC address tracking problem

[unixisc]

I think that this is something that could be re-engineered so that autoconf wouldn't simply be taking the MAC address and inserting 0xfffe in between, but rather takes the MAC address, masks random bits of the address, and then uses it. Such an approach would be a lot tougher to breach, but would provide all the benefits of autoconfiguration. Also, since no network has anything even close to 2^64 addresses, masking i.e. losing certain number of bits from the string while assigning the address is unlikely to cause any IP conflicts, and in any case, DAD (duplicate address detection) would prevent it from taking it anyway. In the case of when someone is in one place, usually stateful addresses are used w/ DHCP6. But in case of things like Mobile IP, which is what you alluded to, this would come into play, and it would have been good had some of the bits been masked. Incidentally, the 4G standard dictates that IPv6 is the default IP for networks, not IPv4, so that's a good thing.

Simplicity and Obviousness take a lot of work

[billstewart]

Yes, it's simple and obvious, and it took years of experimentation to get the simple and obvious parts to work well. The early Internet had congestion collapse problems that TCP needed to be retuned for, and figuring out how to get slow machines to send data fast (Van Jacobson's work) took a while, and Jim Getty's Bufferbloat work says we're not done yet.

Bram Cohen put a huge amount of incremental experimentation and testing into making Bittorrent work as well - things that are simple and obvious when you've got a dozen machines sharing files don't always scale up to a thousand machines sharing them, and things that work with a thousand machines don't always work with a million. And if you think that the Internet is mostly doing short transactions, you need to remember that at least as of a few years ago, Bittorrent was burning about a third of the bits on the internet, though Youtube/Hulu/etc. have probably displaced some of that with other big streaming data. (So yes, most of the transactions on the net are probably very short, but most of the bits aren't.)

Hardware accelaration for IPv6

[Anonymous Coward]

One thing I was wondering in this context of hardware accelaration - one reason I believe it's so easy w/ IPv4 is that 32-bit is commonplace w/ CPUs, which need the hardware accelaration, and even 64 bit is common. But now that we are dealing w/ 128 bit numbers, wouldn't that require 128-bit CPU/ASICs? I'm not talking about any addressing capabilities here - I'm talking about the simple ability to do logical (and maybe arithmetic) operations on 128-bit numbers. Since there are no 128-bit CPUs out there (not counting GPUs) since there apparently ain't a need, why not take one of those open soft CPUs (like OpenRISC), make a 128-bit version of it - even if initially just in FPGAs - and then use it as the basis on which to make an IPv6 router? Make it such that it can deal w/ any group of bytes in the entire data string at a time. Such a CPU, seems to me, would be pretty handy for routing. If volumes pick up for their use in routers, they can then be spun into ASICs

I don't doubt that 64-bit CPUs, such as the MIPS III or IV can be used as well. Just that it would presumably take separate cycles to process the network ID, and then the interface ID

Re:Hardware accelaration for IPv6

[Bengie]

For the most part, the first 64bits is for routing and the last 64bits is for identifying the local machine. This allows breaking up the work on a 64bit machine quite nicely.

IPv6 is a camel

[Anonymous Coward]

Why was IPv6 not just implemented as a superset of IPv4? Existing IPv4 addresses would become IPv6 addresses by prefixing them with the requisite number of octets containing zero. This would have just required a patch to the major operating systems and a firmware upgrade to networking equipment.

Why a completely new address space and all this new functionality when all most people cared about was the depletion of the existing address space? The maxim that a camel is a horse designed by a committee seems appropriate to IPv6.

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.

EUI-64 giving away your MAC isn't a problem

[realxmp]

It's not exactly security secret information, the only time where it might be useful to know it is when you're on a LAN and if you are then you can get it from ARP anyhow. If someone has it they can probably guess what model your machine is or maybe your wifi chipset if you're on that. That information might be useful for an attack, but usually only within a LAN context where as I said before they'd have it anyway.

But you raise a good point giving away your permanent address to everyone you connect outbound? Well you don't have to, on modern ipv6 stacks you get a EUI-64 address as your permanent address, and along with it a random dynamic address assigned as your temporary. Windows 7 and Mac OS X do this already, RFC 3041 described here. If you want anyone to be able to connect to you permanently only then do you give them your permanent address (back to my mac, VNC connections, etc). But for all outbound connections you always use your temporary.

Re:EUI-64 giving away your MAC isn't a problem

[unixisc]

But even if one wants to enable his computer - say his web server - to be connected to from outside the network, why use EUI-64 for that? What interest does the visitor have in knowing his model or his chipset, and why make it easier for a cracker? Instead, using DHCP6, assign a static address to that machine for any inbound connections, and pool a bunch of addresses to by dynamically assigned to all boxes on the network. That way, he uses his static web address. Also, if I'm not mistaken, he can even use different static IPs for virtual hosts, so that host1.example.com can be on 2001:420:4ed::10, host2.example.com can be on 2001:420:4ed::20, and so on. Or different IPs for different protocols e.g. one for an httpd server, another for an ftp server, another for an smtp server and so on, w/o necessarily involving port numbers. Added advantage of that - if ever there is a problem w/ a break-in or something, a new IP address can be assigned, w/o an EUI-64 address being contaminated.