Slashdot Mirror
Vint Cerf Answers Your Questions About IPv6 and More
Last week, you asked questions of "father of the Internet" Vint Cerf; read on below for Cerf's thoughts on the present and future of IPv6, standards and nomenclature, the origin of his beard, and more. Thanks, Vint!
What can we do to get ISPs to switch on IPv6?
by jandrese
One of the biggest hurdles to IPv6 adoption today is that the average home user simply cannot get an IPv6 address from their ISP. Tunnels are hacker toys, and completely impractical/impossible for people who are using their ISP's "home router". What do you think we can do to convince ISPs to start rolling out IPv6 [i]before[/i] there is a crisis? Everybody agrees that the transition will go smoother if we take it slow and easy, but nobody is willing to make the first step, and IPv4 addresses aren't still being inexorably depleted the world over.
VC: I have been asking myself (and others) this question for some years now! When you try to explain that they can't really expand the Internet effectively relying solely on cascading NAT boxes they kind of glaze over. Sadly, now that we really are in the IPv4 end-game, there is not much choice but to deploy NATs to try to make dual-stack work as a transition plan. If ISPs had started implementing IPv6 5 years ago we would not have this problem. I think only pressure from consumers, businesses and governments to demand IPv6 implementation will help. Even then, I can imagine the bean counters insisting that there be incremental revenue for implementing IPv6 despite the simple fact that the only serious path to supporting smart devices (including smart grid, mobiles with IP addresses, etc) is through implementation of IPv6. We are also going to have to find some incentives for users to upgrade their home routers to handle both IPv4 and IPv6. Maybe a trade-in policy???
IPV6, and a related question
by gr8_phk
With IPv6 we could all have fixed IP addresses (or blocks of them) at home. Is this likely to happen? What do you see as the pros and cons from the ISP point of view for doing this? I think the reasons I want it are the reasons they don't, but I'd like to know how someone with your perspective sees it.
VC: We could actually have a fairly large group of IPv6 addresses at each termination point. An advantage is that one could then run servers but some ISPs might find that problematic because of the potential uplink traffic. I ended up paying for "business" class service to assure fixed IP addresses for that reason. I did not have servers of video or imagery in mind, but, rather, controllers and sensors (and ability to print remotely, for instance).
Hardware accelerated IPv6
by vlm
Hardware accelerated ipv4 routing/switching was out there, I dunno, at least a decade ago, or more. Your expectations on the rollout of hardware accelerated ipv6 switching?
VC: It probably won't happen until there is clear evidence of an IPv6 tipping point. Of course, it makes every bit of good sense and the IPv6 format is better geared to hardware assist than IPv4.
Why the colon in IPv6?
by jandrese
The biggest thing I hate about IPv6 is that the standard format uses colon as the digit separator. On most keyboards, that is a fairly awkward character to type, especially in rapid fire between groups of hex digits. Also, it causes problems for the many many programs that specify ports after IP addresses with a colon (like URIs!). IPv4's use of the period instead is much nicer. If you didn't want to reuse the period (so programs can distinguish between the two types of addresses more easily), why not use dash instead? It's just as visually appealing and doesn't require you to hit shift to type it. It would have saved a whole lot of ugly brackets around IP addresses.
Any aesthetic qualities of the colon are lost when you have to do this:
http:/// [http] [1005:3321:5a52:4fca::1]:8080/
instead of: http://1005-3321-5a52-4fca--1:8080/ [1005-3321-5a52-4fca--1]
And that second example was noticeably quicker for me to type.
Edit: And of course because this is Slashdot it made a huge mess of the first URL and forced me to mess it up slightly to be readable!
VC: The colon was needed to allow for compressed display of IPv6 addresses and to avoid confusion with a dotted representation of IPv4. It was apparently the only character thought to be unencumbered for this purpose at the time. Other slashdot readers may have additional comments on this.
Hindsight is 20/20
by eldavojohn
If there was one thing you could go back and change about TCP/IP -- something that is far too entrenched to change now -- what would it be?
VC: Well, I wish I had realized we'd need more than 32 bits of address space! At the time, I thought this was still an experiment and that, if successful, we would develop a production version. I guess IPv6 is the production version! I would also have included a lot of strong authentication mechanisms but at the time we were standardizing TCP/IP (version 4), there was no practical public key crypto capability ready in hand.
.here TLD?
by TheLink
Do you think there should be a .here TLD, reserved officially for local use in an analogous way to the way that the RFC1918 IP addresses are reserved officially for private use?
Currently many are coming up with their own ad hoc TLDs for local use. In my opinion this is suboptimal. Having a standard official TLD would allow more interesting things to "organically grow" on it.
(See also: http://tools.ietf.org/html/draft-yeoh-tldhere-01)
VC: Hard to say, honestly. I am not sure just what ".here" might actually mean unless intended to be self-referential (in other words, the server is the same as the referring party - kind of like 127.0.0.1? In that case, it need only be a reserved term rather than something you register in.
Ooh! Settle An Argument For Me!
by Greyfox
Though my deep and thoughtful meditation on IP addressing, I have realized that an IP address is simply a number. We canonically break it up into 4 smaller numbers that are presumably easier to remember. However if you stack all the bits of those smaller numbers together, you get a bigger number, and that number is actually the address. Moreover, every C standard library that I have ever tried is able to resolve this bigger number to the correct address. If I ping a 10 digit number in that address range, the C standard library will figure it out. It is my position that this is a feature and not a bug.
It seems that the OS X Firefox Guys don't agree with me. Admittedly they do have an RFC on the subject, but their browser breaks a known behavior that every other TCP/IP client program on the planet exhibits, including other operating system versions of Firefox!
Would you kindly bludgeon one of us into submission? I don't really care which side of the argument you come down on, but one of us has to be able to say "Because Vint Cerf said so!"
Oh, and while I've got you, I'm sick of writing stateless http applications. May I have your permission to go back to writing plain old socket servers on other ports, providing data based on whatever query format I feel like implementing? It kind of looks like REST, I suppose, except that I don't have to load 14 layers of frameworks to get to that point.
VC: LOL! actually, most of us assumed that any way to generate the 32 number should be acceptable since the connection process doesn't actually use the text representation of the IP address. I think any value in the range 0 to 2^32-1 should be acceptable as an IP reference. As to stateless operation, I know what you mean; you have to get used to figuring out how to stash intermediate state (cookies usually)...
SMTP, DNS, U.S. Customs
by molo
It seems that it is getting more and more difficult to successfully run your own SMTP server. See, for example, this post responding to the idea that a user was going to move off gmail to their own server. Are there any prospects for meaningful SMTP reform that would lower the barrier to entry for legitimate emailers?
DNS has been often criticized as a centralized single point of failure / censorship. Have you been following the development of namecoin and P2P DNS? Are these systems viable in your estimation? How would you improve them or encourage their adoption?
The U.S. Customs department recently created headlines in seizing domains. These seizures appear to be extra-legal (not founded in law), but ICANN has gone along with them. Are those fair statements? Should ICANN's trustworthiness be suspect as a result of this process?
VC: On SMTP, the problem is spam. If SMTP relays could be authenticated in some way, perhaps running your own would work better. As of now, it is a problem to validate relays and most ISPs don't allow it. Maybe we will make some progress in this when we can strongly authenticate/validate end points in the network better. Regarding alternatives to DNS, it would be interesting to find alternatives to DNS that might be less prone to the business models that produce domaining, for example, but I have not yet seen evidence that such an outcome is likely to gain traction. I am not sure that ICANN has any ability to resist effectively the so-called seizures of domain names by the DHS/ICE. I am disturbed by the argument that this is comparable to FBI "seizures" of contraband for many reasons but I think the ability to resist this would rest on a successful court challenge to the practice, not to an ICANN policy.
Smart Grid
by kiwimate
You're currently on the Governing Board of the NIST Smart Grid Interoperability Panel. What is the state of standards development, and how big an impact does it have to move national infrastructure communications into the public IP arena so far as our ability to strengthen and expand our infrastructure? Conversely, how big are the threats in this new world?
VC: The process is moving along reasonably well although adoption of the standards that are emerging in the US will depend on endorsement by FERC and NERC. I think the standards can be very beneficial to the creation of interoperable energy management systems, edge devices, and device controllers. I am pleased that IPv6 forms a major basis for edge communication but concerned that the domestic ISPs, with some notable exceptions, have been slow to roll out support for IPv6. I imagine that an IPv6-equipped mobile could easily become a remote controller for a wide range of IPv6-labelled devices.
What would you like to see developed next?
by techmuse
I'm curious what technologies you would like to see developed next, or what you think would be most important to develop next. In other words, what do you think researchers should work on now that would be most significant? (Oh, and thank you for changing my life!)
V: My major wish right now, apart from ISP implementation of IPv6, DNSSEC and more end/end crypto and strong, 2-factor authentication, is the implementation of true broadcast IP. Satellites raining IP(v6) packets to Earth in range of millions of receivers could make widespread digital distribution of information far more efficient.
Interplanetary Internet
by immakiku TCP/IP started as a military project but has been adapted for all the Internet applications we see today. What sort of applications do you foresee/imagine for the Interplanetary Internet, aside from the stated purpose of coordinating NASA devices?
VC: The primary terrestrial applications are military tactical communications and enhanced mobile communications. I see a role for these delay and disruption tolerant protocols in public safety networking as well. All devices in the system could also serve as relays to allow for the dynamic creation of Mobile Ad hoc Networks, making more resilient emergency services communications and any number of popular user apps on mobiles.
The IP of TCP/IP
BY WHOM
The head of UN's WIPO believes that the Internet (and obviously the stack on which it runs) should have been patented. How do you believe it would have evolved, would TCP/IP be protected by patents?
VC: This is really pretty silly. Bob Kahn and I consciously did NOT patent or control distribution of the design and protocol specifications for TCP/IP for the simple reason that we wanted no intellectual property barriers to the adoption of TCP/IP as an international standard. I see absolutely no utility in the proposition to patent TCP/IP. It would have given a reason for SNA, DECNET and other proprietary protocols to persist since their inventors/purveyors could have argued that licensing TCP/IP (had it been patented) would be of no interest to them - indeed, its use opened up interoperability among many brands of computers (and networks) leading to more competition.
Has the Internet become too centralized?
by slashsloth
That is to say, do you think that too much power & control now lies in the hands of the Internet Service Providers, thereby making it, at least in terms of control if not routing, too centralized & too easily manipulated by the powerful few. I guess this question stems from a viewpoint that it should be somehow democratic & free (as in free speech). Also do you share my pedantic belief that the public Internet should be spelt with a capital 'I'?
VC: As to the latter, yes, I strongly believe that the capital was intended to refer to the public Internet (I have written on this in the past). We accepted the notion that "internet" could use the protocols but be private and disconnected from the public Internet but that "Internet" referred to the latter. Some people disagree but I still believe it to be a useful distinction. As to centralization, it is possible that the lack of competition among Internet access providers is a bad outcome. I have always been a proponent of intra-modal competition through open access to underlying transport networks but not everyone agrees with me.
How can we bring trust back to the internet?
by Madman
One of the secrets of the internet's massive success is the lack of controls over it; if there had been strict security and processes in place it would likely not have come about. One of the downsides is that all our security measures are tacked-on, there is no built-in security to the protocols used on the internet and as a result security is a massive problem. How do we go from the wild west to having at least a reasonable level of trusted computing?
VC: Better and stronger authentication would help. 2-factor "passwords" and registration of devices. We may also need to adopt international norms for acceptable usage of the net with some kind of enforceable rules with reciprocity. Until we have some collective and cross-border ability to bring miscreants to justice, we will continue to see relatively unconstrained behaviors including harmful ones.
No more "peace and love" in software designs
by BeforeCoffee
I take it that the "route around failures" and other original design features of TCP/IP and the Internet as a whole relied upon trusting others always having good intentions and cooperating. Those designs were necessary at the time and the reason the internet exists today.
Nowadays distrust, firewalls, and coding defensively is the norm (or it should be). In that light, the internet's design seems creaky and vulnerable.
Do you have any thoughts or feelings on how software has changed and seemingly become so treacherous since you first designed TCP/IP? Would you advocate a ground-up redesign of internet transports and protocols starting with TCP/IP?
VC: I have always been a fan of trying clean-sheet designs. Sometimes you discover retrofits that don't require a re-design. In other cases (such as delay and disruption tolerance) you need serious re-implementation of new designs. It is clear that authentication, various forms of cryptographic protections and the like are needed at several layers in the architecture. Deploying something wholly new is hard, though.
Future of the Internet
by H0bb3z
Do you feel the security concerns over collected information will trump the leveraging of information in future Internet technologies? Will there be a separate "opt-in" or "opt-out" web to cater to each preference?
Context: There have been many controversies recently regarding the collection of data and the privacy of individual information. As we move forward, I've heard a mixed set of messages regarding the direction we should expect to see.
Consumerism is indeed driving innovation and everything is going mobile these days (there's an app for that I think). One example I heard recently of the benefit of the convergence of information and mobility: a consumer can point their mobile phone at a shelf of groceries, get an active "overlay" of information regarding the products and determine which best suits the customer needs. On the flip side, sensors that track customer behavior are installed at the grocery shelf and based on detected behavior (like stopping for a moment to reminisce about Coco-Puffs even though you know they are bad for you) initiates a coupon for whatever the vendor may feel would provide enough motivation to purchase their product -- in the example a $1 off coupon to the mobile phone of a shopper.
Will this become reality in the future?
I think there are benefits to be had, but also am fiercely protective of my personal information and preferences.
VC: At least in America, we have tended to readily give up privacy in exchange for convenience. Credit card information bases being a good example of that. If one can divorce identity from behavior patterns, it might be acceptable to many to benefit from system reactions to our choices and behavior if these are not correlated with identity.
Postel and Crocker
by vlm
So you went to high school with Postel and Crocker, according to Wikipedia; did you guys hang out all along or meet up decades later?
V: Crocker and I have been best friends since about 1959. Jon was in a later class and we didn't know him until we all reconvened at UCLA in the late 1960s.
A Simple Pogonological Question
by eldavojohn
What level of success does TCP/IP owe to your glorious beard?
VC: LOL!! not much! I just got tired of nicks and cuts from shaving my whole face and went with the beard!! I did shave it off once, but quickly re-grew it after being painfully reminded why I had grown it in the first place!!!
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!!!
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.
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.
The colon is hard to type? It's two pinkies
Your hair look like poop, Bob! - Wanker.
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.
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.
> 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'. :-)
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
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.
"First they came for the slanderers and i said nothing."
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.
"First they came for the slanderers and i said nothing."
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.
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.
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.
or SCTP, or TIPC, or RDS. There are lots of message-based protocols out there. Why use TCP if you don't want streams?
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
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.
"First they came for the slanderers and i said nothing."
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
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.
"First they came for the slanderers and i said nothing."
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
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 ?
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.
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.
No need to do it in TCP when you have IPsec! Unless of course you want per-process authentication instead of per-host authentication -- then you could use TLS. I think you are suggesting a built-in version of TLS anyway, The key management would be a pain if we didn't go with the same error-prone trusted CA model. Windows actually does something interesting here with the "homegroup" system: they use IPSec and IPv6 transparently to get secure LAN communication.
The core of TCP, as its original RFC 793, is quite straightforward. The many later additions have made it more complicated, though.
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.
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.
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.
"Is it friday yet?"
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 ...
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
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
"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?
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:
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
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.
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.
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.
"First they came for the slanderers and i said nothing."
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...)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
"First they came for the slanderers and i said nothing."
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.
"First they came for the slanderers and i said nothing."
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.
"First they came for the slanderers and i said nothing."
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.
"First they came for the slanderers and i said nothing."
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.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yes, it's simple and obvious, and it took years of experimentation to get the simple and obvious parts to work well. The early Internet had congestion collapse problems that TCP needed to be retuned for, and figuring out how to get slow machines to send data fast (Van Jacobson's work) took a while, and Jim Getty's Bufferbloat work says we're not done yet.
Bram Cohen put a huge amount of incremental experimentation and testing into making Bittorrent work as well - things that are simple and obvious when you've got a dozen machines sharing files don't always scale up to a thousand machines sharing them, and things that work with a thousand machines don't always work with a million. And if you think that the Internet is mostly doing short transactions, you need to remember that at least as of a few years ago, Bittorrent was burning about a third of the bits on the internet, though Youtube/Hulu/etc. have probably displaced some of that with other big streaming data. (So yes, most of the transactions on the net are probably very short, but most of the bits aren't.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It's not "lazy developers", it's right there in the IPv6 standard. It's pretty much the standard way of forming IPv6 interface identifiers (basically, the lower 64 bits of most IPv6 addresses). Generating interface identifiers randomly to protect privacy is a later invention.
That's b'cos in the IPv4 header, bits 96-127 is the source IP address, and bits 128-159 is the destination IP address. The moment you start adding octets i.e. bits to the address, you are changing the lengths (and thereby offsets) of both the source and destination addresses, and as a result, every router in the world, and all networking equipment that uses IPv4 would have to be updated. Same level of effort as w/ IPv6. Given this recognition when they undoubtedly first confronted this problem, the IETF decided that since they'd be going through so much effort anyway, they decided to use the opportunity to throw in all improvements to IP that could be done, but not in IPv4.
Expanding the IPv6 address to 128 bits, and strictly defining the lengths of each field, has done enough to future-proof this protocol and probably ensuring that an IPv7 will unlikely ever be needed. 128 bits allows for a hierarchical routing scheme that was not possible under IPv4. Also, improved support for multicast and anycast, and elimination of broadcast has done wonders.
It's not exactly security secret information, the only time where it might be useful to know it is when you're on a LAN and if you are then you can get it from ARP anyhow. If someone has it they can probably guess what model your machine is or maybe your wifi chipset if you're on that. That information might be useful for an attack, but usually only within a LAN context where as I said before they'd have it anyway.
But you raise a good point giving away your permanent address to everyone you connect outbound? Well you don't have to, on modern ipv6 stacks you get a EUI-64 address as your permanent address, and along with it a random dynamic address assigned as your temporary. Windows 7 and Mac OS X do this already, RFC 3041 described here. If you want anyone to be able to connect to you permanently only then do you give them your permanent address (back to my mac, VNC connections, etc). But for all outbound connections you always use your temporary.
Later or not, it still resolves the issue of having to use EUI-64 in the address. I like random identifiers, but would those random identifiers be static or dynamic, and would they be stateless or stateful? I think a modification to EUI-64, which would mask random bits in the address for all nodes on a particular subnet would solve the issue of uniqueness (since most networks won't need anywhere even close to 64 bits for each of their nodes to be uniquely id'ed) as well as create enough possible choices that any malware has to pick from in determining the exact MAC address that the intrusion would be detected by whatever security the network has. Eg if 24 bits in EUI-64 were masked, that would create 16,777,216 different possible MAC addresses that would need to be examined to determine a match. If that's not good enough, increase the number of bits that need to be masked.
I thought that Hurricane Electric already does that, and Comcast too has plans to go to dual-stack-lite i.e. have an IPv6 only network, and for IPv4 customers, have LS-NAT, where each private IPv4 address is mapped on to an IPv6 address and that mapping resides on their routers. But I'm glad that your ISP has such plans. It would be good if all ISPs went the IPv6 only route, and supported IPv4 through dual-stack lite or tunneling.
But UDP is really good for Teredo, which enables a IPv6 packet to get encapsulated in an IPv4 UDP datagram and get forwarded by the NAT to the ultimate destination address w/o IPSEC getting mangled. As a result, a host implementing Teredo can gain IPv6 connectivity with no cooperation from the local network environment.
Yeap. UDP sucks unless you can accept dropped packets, out of order messages, and don't care about flow control. If you're ok with all of those, then it's fine. But that situation is rare.
"First they came for the slanderers and i said nothing."
For the most part, the first 64bits is for routing and the last 64bits is for identifying the local machine. This allows breaking up the work on a 64bit machine quite nicely.
While processing "messages" is easier than a stream for any case where the message is small, what about a message that is larger than a packet? Suddenly you need a layer on top of IP again. So now you have message on message instead of stream on message.
In order to process message on top of message, you have to treat it as a stream. So instead of stream on top of message, you have message on top of stream on top of message.
Now if you wanted to have implement a stream interface, you will have stream on top of message on top of stream on top of message.
It's just easier to have stream on top of message and let the programmer decide who to process the data.
"I have to implement a scheme for setting up message sizes."
ROFL
Lets give a scenario where you want to send message like you're talking about. Say you send 1400 byte messages.
1) You send 1400 bytes
2) OS packages it up into a single packet and sends it out.
3) OS gets ICMP about fragmentation
4) OS splits up original message into two packets
5) Receiver gets two packets
Now, should your app see one message or two messages?.. I'm leaning towards 1. What does this mean? It means at the very basic network stack level, it will have to treat TCP/IP as a stream because it never knows how large the messages will be from packet to packet.
If you want to have a "message" based TCP, then implement your own libraries, but at the OS/Network level, packets are processed as a stream because you NEVER know how much data you will get from packet to packet.
From my perspective, most everything I do now days is working with streams. Treating TCP as messages would be more complicated for me than just doing everything as a stream. Almost any time I've moving data around, it's as a stream. The default of TCP as a stream just makes it really easy to plug into.
TCP is just a super-set of UDP. I don't see the problem. Implement your own protocol on top of UDP.
If TCP was message based, how would you handle messages that are larger or smaller than a packet's payload capacity? A smaller packet will have wasted space, so you're better of including "part" of the next packet. If it's a larger packet, you'll have to fragment the message across more than one packet.
Suddenly we're right back to not working with messages, but partial messages. Guess what's a great way to read partial messages?... STREAMS!
I would love to see programmers abuse a "message" based TCP protocol. I'm going to send this file across as a "message"... Yay, buffer an entire 10TB file into a message... How I love streams.
This is pretty dumb. I can think of three ways to resolve this 'problem' in about 30 seconds. Whereas you apparently can't think of any. Therefore, you are pretty dumb.
"First they came for the slanderers and i said nothing."