×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Vint Cerf Answers Your Questions About IPv6 and More

timothy posted more than 2 years ago | from the tell-us-more-about-your-beard dept.

The Internet 150

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!!!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

150 comments

gay (-1)

Anonymous Coward | more than 2 years ago | (#37832228)

This shit is gay, yo. Frosty piss

ICANN (2)

rudy_wayne (414635) | more than 2 years ago | (#37832332)

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.

The Ethiopian Chicken (-1)

Anonymous Coward | more than 2 years ago | (#37832474)

What's the difference between dog shit and niggers? When dog shit gets old it turns White and quits stinking.
What's the difference between a jew and a pizza? A pizza doesn't scream in the oven.
What's the difference between a nigger and a snow tire? A snow tire doesn't sing when you put chains on it.
What would you call the Flintstones if they were black? Niggers.
Why don't sharks eat niggers? They think it's whale shit.
What do you call a nigger in a tree with a briefcase? Branch manager.
How come there aren't any Mexicans on Star Trek? They don't work in the future, either.
Why do niggers cry during sex? The Mace.
How do you stop a nigger from drowning? Take your foot off the back of his head.
How do you get a nigger out of a tree? Cut the rope.
What did the Alabama sherriff call the nigger who had been shot 15 times? Worst case of suicide he had ever seen.
What do you get when you cross a retard with a gang banger? Someone who spray paints on a chain link fence.
Why do niggers stink? So blind people can hate them too.
What do you get when you cross a nigger and a spic? Someone too lazy to steal.
Why don't niggers take aspirin? They refuse to pick the cotton out.
What do nigger kids get for Christmas? Your bike.
Why do spics drive low-riders? So they can cruise and pick lettuce at the same time.
What do you get when you cross a jew and a gypsy? A chain of empty retail stores.
Why don't nigger kids play in the sandbox? Cats keep covering them up.
What do you call an apartment full of niggers? A COON-dominium.
Why are there no nigger astronauts? Their lips explode at 50,000 feet.
How do you babysit a niglet? Wet his lips and stick him to the wall.
How do you get him down? Teach him to say "Motherfucker."
How else do you babysit a niglet? Put Velcro on the ceiling and tell him to jump.
How do you get him down? Invite the spics over, blindfold them and tell them it's a piñata party.
Why do jews have big noses? Air is free.
What is a nigger on a bike? Thief.
What's long and black and smells like shit?The welfare line.
What do you call 50 niggers at the bottom of the ocean? Good start.
What is the worst 3 years of a niggers life? First grade.
How was break dancing invented? Niggers trying to steal hubcaps from moving cars.
Why do niggers keep chickens in their back yards? To teach their kids how to walk.
How do you know Adam and Eve were not black? You ever try to take a rib from a nigger?
What is a nigger? Proof that skunks fuck monkeys.
What's the difference between a dead dog in the road and a dead nigger in the road? The dead dog has skid marks in front of it.
What did Abe Lincoln say after a 3 day drunk? "I set WHO free?"
Why are chimps always frowning? They know in a million years they are going to turn into niggers.
Why is interrogating a Mexican like a pool ball? The harder you hit it the more English you get.
How many jews can you fit in a VolksWagon? All of them if you put them in the ashtray.
A nigger and a spic jump off the Empire State Building, who hits the ground first? Who cares.
A nigger and a spic jump off the Empire State Building, who hits the ground first? The spic, because the nigger had to stop on the way down and spray paint "motherfucker" on the wall.
Why don't spics have barbeques? The beans keep falling through the grill.
You hear about the new car made in Israel? Not only can it stop on a dime, it will go back and pick it up.
What do you call an Ethiopian with a pickle on his head? A quarter-pounder.
How many Ethiopians can you fit in a phone booth? All of them.
How do you start a foot race in Ethiopia? Roll a doughnut down the street.
How many niggers does it take to pave a driveway? One if you spread him real thin.

How do you blindfold a chink? Dental floss.

How do chinks name their kids? They throw silverware down the stairs.

What's the difference between a nigger and a bag of shit? The bag.

What's the most confusing day in Harlem? Father's Day.

When does a Black man turn into a nigger? As soon as he leaves the room.

What do you call a nigger with a Harvard education? Nigger.

What do you call a nigger in a courtroom in a 3 piece suit? The defendant.

There is a nigger and a spic in a car, who's driving? The cop.

Why is Stevie Wonder always smiling? He doesn't know he's black.

How long does it take a nigger bitch to take a shit? 9 months.

Why don't nigger women wear panties to picnics? To keep the flies off the chicken.

Why does Alabama have niggers and California have earthquakes? California got first pick.

Why do Mexican cars have those little steering wheels? So they can drive handcuffed.

Why are niggers like sperm? Only one in a million actually work.

What do you call Mike Tyson with no arms? Niger nigger nigger.

How do you fit 100 Cubans in a shoe box? Tell them its a raft.

Why do police dogs lick their ass? To get the taste of nigger out of their mouth.

What can a pizza do that a nigger can't? Feed a family of four.

Why did the nigger carry a piece of shit in his wallet? I.D.

What is red green yellow orange purple and pink? A nigger dressed for church.

Why do niggers have flat noses? That's where god put his feet when he was pulling off their tails.

Did you hear that the KKK bought the movie rights to Roots? They're going to play it backwards so it has a happy ending.

What is the difference between a white owl and a black owl? A white owl goes, "Who, who," a black owl goes, "Who dat? Who dat?"

Did you hear about the new Black Barbie? It comes with 12 kids, AIDS and a welfare check.

What is black, white, and rolls off the end of the pier? A nigger and a seagull fighting over a chicken wing.

What do you get when you cross a nigger with a gorilla? A dumb gorilla.

What is the difference between Batman and a black man? Batman can go out at night without Robin.

Did you hear about the new Chap Stick for niggers? It comes in a spray can.

What's the difference between niggers and pit-bulls? It's still legal to own a pit-bull.

What do you say to a black man in uniform? "I'll have a Big Mac with cheese and a coke."

Why do niggers walk the way they do? Because they spent the first nine months of their lives dodging a coat hanger.

What happened when the Ethiopian fell in the crocodile pit? He ate six crocs before they could pull him out.

Why do niggers call white people "honkies"? That's the last sound they hear before the white people run them over.

How do you stop a nigger from going out? Pour more gas on him.

Did you hear about the nigger with insomnia? He kept waking up twice a week.

What do you do if you run over a nigger? Reverse.

Why do decent white folks shop at nigger yard sales? To get all their stuff back.

Who were the three most famous women in black history? Aunt Jemima, Diana Ross, and Mother Fucker!

Hear about the new bumper sticker that says "Run, Jesse, Run"? You put it on the front of your car.

What do Stevie Wonder and Ray Charles have in common? They're both niggers. How come Stevie Wonder & Ray Charles can't read? They're both niggers.

Why do niggers wear wide-brimmed hats? So pigeons can't shit on their lips.

Why did so many nigger soldiers get killed in Vietnam? Every time someone yelled "Get down!" the niggers would jump up and start dancing.

What do you get when you cross a nigger with a Vietnamese? Nothing. There are some things even a Vietnamese won't do.

What's black and tan and looks good on a nigger? A Doberman Pinscher.

What's the fastest animal in the world? The Ethiopian chicken.

IPv4 (1)

Anonymous Coward | more than 2 years ago | (#37832350)

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 (1)

Anonymous Coward | more than 2 years ago | (#37832576)

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 (1)

unixisc (2429386) | more than 2 years ago | (#37837486)

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.

Easy squash... (1)

Gription (1006467) | more than 2 years ago | (#37838498)

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

Router price/performance and mgmt apps (1)

billstewart (78916) | more than 2 years ago | (#37840312)

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

Hardware accelaration for IPv6 (0)

Anonymous Coward | more than 2 years ago | (#37841070)

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

What? (2)

OverlordQ (264228) | more than 2 years ago | (#37832404)

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

Re:What? (1)

Desler (1608317) | more than 2 years ago | (#37832450)

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? (1)

vlm (69642) | more than 2 years ago | (#37833144)

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? (1)

unixisc (2429386) | more than 2 years ago | (#37838116)

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? (0)

Anonymous Coward | more than 2 years ago | (#37832472)

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? (0)

Anonymous Coward | more than 2 years ago | (#37836544)

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? (5, Interesting)

Arlet (29997) | more than 2 years ago | (#37832600)

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

Re:What? (0)

Anonymous Coward | more than 2 years ago | (#37834278)

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

Re:What? (1)

MaerD (954222) | more than 2 years ago | (#37837352)

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

Re:What? (1)

jgrahn (181062) | more than 2 years ago | (#37837710)

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

IPv6 "hard". NAT "easy" (5, Interesting)

tlhIngan (30335) | more than 2 years ago | (#37832468)

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" (3, Insightful)

Bookwyrm (3535) | more than 2 years ago | (#37832558)

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" (5, Informative)

csnydermvpsoft (596111) | more than 2 years ago | (#37832794)

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 [wikipedia.org]. 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" (1)

Pentium100 (1240090) | more than 2 years ago | (#37834462)

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" (3, Informative)

CAPSLOCK2000 (27149) | more than 2 years ago | (#37832878)

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" (0)

Anonymous Coward | more than 2 years ago | (#37832922)

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" (1)

Pentium100 (1240090) | more than 2 years ago | (#37834540)

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 (0)

Anonymous Coward | more than 2 years ago | (#37838358)

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.

Re:IPv6 "hard". NAT "easy" (5, Informative)

vlm (69642) | more than 2 years ago | (#37832942)

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" (1)

Pentium100 (1240090) | more than 2 years ago | (#37834418)

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" (1)

Jonner (189691) | more than 2 years ago | (#37834816)

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" (1)

unixisc (2429386) | more than 2 years ago | (#37841136)

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" (3, Insightful)

Jonner (189691) | more than 2 years ago | (#37834936)

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" (2)

Bengie (1121981) | more than 2 years ago | (#37837288)

"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" (1)

unixisc (2429386) | more than 2 years ago | (#37838746)

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 first 2 bytes were country ID, followed by 2 bytes for ISP (does any country have more than 65536 ISPs?), followed by organization, where one can allow any ISP up to 4 billion customers. That eats up the top 8 bytes. The next 4 bytes could have been the subnet ID, and would have allowed nested subnets, which would allow anything from 1 to 8 layers of nesting. The final 4 billion addresses is something each owner could have gotten, and configured his DHCP6 to assign as deemed fit. (One thing - if one wants to use autoconfiguration, do it in a way that does not give away your MAC address. Otherwise, don't use it!)

Re:IPv6 "hard". NAT "easy" (0)

Anonymous Coward | more than 2 years ago | (#37838780)

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.

A few privacy concerns (0)

Anonymous Coward | more than 2 years ago | (#37832552)

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

Re:A few privacy concerns (1)

Millennium (2451) | more than 2 years ago | (#37832912)

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 (1)

antientropic (447787) | more than 2 years ago | (#37840648)

It's not "lazy developers", it's right there in the IPv6 standard [ietf.org]. 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 [ietf.org].

Re:A few privacy concerns (4, Insightful)

JSBiff (87824) | more than 2 years ago | (#37833170)

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 (0)

Anonymous Coward | more than 2 years ago | (#37833382)

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.

The MAC address tracking problem (1)

billstewart (78916) | more than 2 years ago | (#37840506)

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.

Why using the MAC address was so cool! (2)

billstewart (78916) | more than 2 years ago | (#37840444)

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

Biggest TCP/IP mistake (0)

phantomfive (622387) | more than 2 years ago | (#37832574)

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 (2)

Arlet (29997) | more than 2 years ago | (#37832666)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37832812)

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 (2)

Arlet (29997) | more than 2 years ago | (#37832898)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37833228)

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 (1)

Arlet (29997) | more than 2 years ago | (#37833334)

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 (1)

Sir Homer (549339) | more than 2 years ago | (#37833458)

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 (1)

Arlet (29997) | more than 2 years ago | (#37833946)

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

Simplicity and Obviousness take a lot of work (1)

billstewart (78916) | more than 2 years ago | (#37840572)

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 [wikipedia.org] 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.)

Re:Biggest TCP/IP mistake (2)

Sir Homer (549339) | more than 2 years ago | (#37833212)

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 [ncsu.edu]

Re:Biggest TCP/IP mistake (1)

phantomfive (622387) | more than 2 years ago | (#37840364)

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 (1)

Jonner (189691) | more than 2 years ago | (#37835096)

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 (1)

petermgreen (876956) | more than 2 years ago | (#37838398)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37840324)

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.

so use UDP (1)

Chirs (87576) | more than 2 years ago | (#37833064)

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 (3, Insightful)

vlm (69642) | more than 2 years ago | (#37833114)

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 (1)

Jonner (189691) | more than 2 years ago | (#37835200)

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 (0)

Anonymous Coward | more than 2 years ago | (#37839464)

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

Re:so use UDP (1)

phantomfive (622387) | more than 2 years ago | (#37833166)

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

vlm (69642) | more than 2 years ago | (#37833066)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37833206)

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 (1)

Arlet (29997) | more than 2 years ago | (#37833260)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37840396)

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 (2)

Sir Homer (549339) | more than 2 years ago | (#37833592)

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 (2)

fa2k (881632) | more than 2 years ago | (#37833934)

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 [wikipedia.org]! 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 (0)

Anonymous Coward | more than 2 years ago | (#37833190)

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 (0)

Anonymous Coward | more than 2 years ago | (#37833404)

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 (1)

Jonner (189691) | more than 2 years ago | (#37835000)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37840340)

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 (1)

jgrahn (181062) | more than 2 years ago | (#37837850)

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 (1)

phantomfive (622387) | more than 2 years ago | (#37840238)

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.

Vendor support for home routers (1)

Anonymous Coward | more than 2 years ago | (#37832582)

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 (2)

Daniel_Staal (609844) | more than 2 years ago | (#37832832)

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 (1)

gurubert (39045) | more than 2 years ago | (#37837496)

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

sootman (158191) | more than 2 years ago | (#37832608)

> 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 (2)

phantomfive (622387) | more than 2 years ago | (#37832720)

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 (1)

BeforeCoffee (519489) | more than 2 years ago | (#37834234)

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

LOL usage approved by Vint Cerf (1)

TheLink (130905) | more than 2 years ago | (#37832904)

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 (1)

Greyfox (87712) | more than 2 years ago | (#37833148)

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 (1)

TheLink (130905) | more than 2 years ago | (#37833408)

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 (0)

Anonymous Coward | more than 2 years ago | (#37834026)

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

Re:LOL usage approved by Vint Cerf (1)

Greyfox (87712) | more than 2 years ago | (#37839758)

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 (1)

Greyfox (87712) | more than 2 years ago | (#37834076)

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 (1)

Coren22 (1625475) | more than 2 years ago | (#37836046)

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 [wikipedia.org]

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 (1)

TheLink (130905) | more than 2 years ago | (#37837418)

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/ [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 (0)

Anonymous Coward | more than 2 years ago | (#37833694)

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.

IP addresses in URLs (1)

Onymous Coward (97719) | more than 2 years ago | (#37839168)

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 (1)

Greyfox (87712) | more than 2 years ago | (#37839706)

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!

Colons (0)

Anonymous Coward | more than 2 years ago | (#37832966)

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 [ietf.org], postfix config [postfix.org], shorewall (now - initially they picked something else) [shorewall.net], 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).

Problem with .here (2)

vlm (69642) | more than 2 years ago | (#37833250)

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 (1)

srg33 (1095679) | more than 2 years ago | (#37834294)

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 (0)

Anonymous Coward | more than 2 years ago | (#37834332)

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

ISPs and IPv6 (0)

Anonymous Coward | more than 2 years ago | (#37834416)

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.

IPv6 Autoconf & DHCPv6 (1)

gurubert (39045) | more than 2 years ago | (#37837454)

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 (1)

vividvew (2493670) | more than 2 years ago | (#37839998)

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.

IPv6 HW forwarding (0)

Anonymous Coward | more than 2 years ago | (#37839120)

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.

IPv6 + mobile devices (1)

vividvew (2493670) | more than 2 years ago | (#37839856)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...