4 ms·

Thomas always says this whenever IPv6 comes up. He wants some sort of "overlay" network. He's ambiguous on what this would look like, why it would be better tha

Thomas always says this whenever IPv6 comes up. He wants some sort of "overlay" network. He's ambiguous on what this would look like, why it would be better than IPv6, and why IPv4 will suffice as its underlying protocol. My conclusion is that his application-level networking experience has fooled him into thinking he knows more than he does about actual network architecture, management, and performance issues. Or maybe he doesn't realize the issues even exist.

JoachimSchipper 13y ago
Um, you're aware that he wrote http://insecure.org/stf/secnet_ids/secnet_ids.html http://insecure.org/stf/secnet_ids/secnet_ids.html, worked for a networking (security) company (Arbor) for years, etc.? He may be wrong, and he may think that he knows more than he actually does, but he does know a thing or two. ;-) Regarding overlay networks: note that HTTP, WebSocket, Skype, BitTorrent and such are already looking quite a bit like an overlay network, and that increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. I'm not sure I particularly like this vision of the future, and I agree that the performance will be worse, but it's far from insane. (As to performance, note how everything is routed over HTTP these days, despite it being rather inefficient for lots of use cases.)
- nknighthb 13y ago
  Forgive me, as I don't have time at the moment to review the paper in detail, but none of what I see skimming through it really contradicts what I already believed. Knowing how the protocols work is not the same thing as knowing how to architect and manage large networks. The "overlay" networks you speak of are already hamstrung by the shrinking ability to directly address endpoints on the Internet. IPv4's fundamental flaws when applied to billions of nodes cannot be papered over forever.
  - wglb 13y ago
    I don't have time at the moment to review the paper in detail, But you have time to make multiple complaints about tptacek not knowing what he is talking about? May I suggest you withdraw from this line of argument?
    - nknighthb 13y ago
      > May I suggest you withdraw from this line of argument? May I suggest that you look at the paper in question and realize it is one that requires careful and uninterrupted attention for an extended period of time to properly understand? May I also suggest that you not make assumptions as to what another person is or is not doing, and how it may interfere with their ability to do some things but not others? Or would you rather just be a judgmental, holier-than-thou asshole?
      - tptacek 13y ago
        As a reminder, this is what you said upthread: My conclusion is that his application-level networking experience has fooled him into thinking he knows more than he does about actual network architecture, management, and performance issues. Or maybe he doesn't realize the issues even exist. My conclusion is that you made that comment having absolutely no idea what my experience was, and then decided to get pissy when the facts didn't line up with your bet. I've made the same dumb bet on HN a bunch of times. "This is just some Ruby dork who knows fuck all about", I don't know, "tax law". It never works out for me, either. The thread is now full of technical commentary about the point I made. Lots of smart people disagree with me; no surprise! You've contributed none of that commentary. Maybe now's a good time to start? You seem to feel passionately about the issue.
        nknighthb 13y ago
        > you made that comment having absolutely no idea what my experience was I made the comment based on the fact that the only thing you ever talk about actually doing is security-related. On everything else, you just pontificate context-free. You implied earlier I should have looked at your "public linkedin profile". You should know that, for me, your profile contains nothing but your current and past employers, and your university. Nothing about what you did there. What was I supposed to conclude from that? I've spent most of my career working for companies that do video-related work, but if you ask me a question about MPEG transport streams, I'll refer you to the guy who, y'know, actually deals with MPEG. At this point I am pissy, yes, but that's not because I was wrong, it's because of the asshole who decided he knows better what my personal time commitments are than I do. > The thread is now full of technical commentary about the point I made. No, it isn't. The thread is full of cursory rejections of your equally cursory commentary. There is absolutely nothing interesting about any of it, because it's all surface bullshit that everybody already knows. There are no details. There's nothing concrete. There's nothing new. Boring, hand-wavy crap. Propose something concrete, something that actually addresses the obvious criticisms you already know are going to be leveled, and I might get interested. Right now, all I'm interested in is ignoring HN for a while.
- ginko 13y ago
  >increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. which is a bad thing.
  - tptacek 13y ago
    It's a bad thing now, because the only way to get assured direct connectivity to the "Internet" is via IPv4 connectivity. It would be less of a bad thing if IPv4 connectivity (specifically: what ASN was advertising the IPv4 prefixes your traffic was associated with when it traversed, say, Telecom Malaysia) wasn't the sine qua non of global connectivity, in the same sense that nobody cares what IP address you use when you connect to IRC.
    - ay 13y ago
      You can connect to IRC because the IRC server is not behind a NAT. Try to run an IRC server on your host which runs behind the consumer NAT which runs behind the CGN. Yes, if the gear supports it, you can use uPNP for the first, and PCP for the second, to open up a port. Unless someone is using it already. Then you need to choose another port. Which you need to communicate to the other clients behind the NATs around the world. Fine, we'll just update the DNS server with an SRV record. You probably will always have a spare public IPv4 address to map the ports 53 to something on the inside network, so this might work. Until your CGN does not have enough IPv4 addresses/ports to permanently allocate one to you. Oh, by the way this is a great way to introduce a "premium" tier service with a public IP address - if you really want to run a server then you can buy an address. So doing the PBX-style circuit switching with NATs is not really in the economic interest of the ISPs. (Not saying that they need to do all the accounting/logging). If the app is awesome enough that the users will pay extra to get the public address - great. That will help to further exhaust the IPv4 addresses and drive the prices up. Rinse, repeat. I am of course exaggerating. But this presentation from NANOG may be a less biased view (though Lee's employer does deploy IPv6, so you can argue it is biased): http://www.nanog.org/sites/default/files/wed.general.howard.gametheory.17.pdf http://www.nanog.org/sites/default/files/wed.general.howard.... Full disclosure: I am into this IPv6 thing. Before that, I spent ~10 years of my life at a random 5-letter vendor to find the bugs in the code and misconfigurations causing outages in people's NATs. It's refreshing to be able to use access-lists again. (the latter statement is only partially correct, but this is a topic for another rant, IPv6 has tons of its warts as well :-)
tptacek 13y ago
Well, let's see. I ran all of technical operations for Chicago's most popular indie ISP, up through the point where we were default-free BGP4 peered, in the era where every customer connection every day was an OSPF recalculation. Then I took a job that required me to write the clientside for every protocol exposed on a "modern network" circa 1996, including FTP, TFTP, NFS, SunRPC, DNS (for which I had to write 3 different recursors and an authority server to do serverside-serverside testing), RIP(!), and lord knows what else. Our product was a network security scanner, before there was Nessus, that worked by actually testing for bugs instead of doing banner grabs. I moved to a research role in that job and built a testsuite for network intrusion detection systems based on a line-by-line audit the 4.4BSD IP stack, then used it to reverse engineer the behaviors of the Windows NT and Solaris (then closed-source) IP stacks, and used that to discover (with my then-partner Tim Newsham) 3 new classes of attacks/bugs on network observation tools. Incidentally: I did that research because I have an ethical problem with unchecked network surveillance. Half this site seems to think I'm a secret government agent. Then I started, with two friends, a chat company that pivoted into multicast content delivery. My role on the dev team was the routing system, which implemented a multicast link-state routing protocol and a multicast service model comparable to PIM; I was also the project manager for our global traffic management system, which took full BGP4 feeds from the networks of friends of mine that ran backbones, and used them to compute anycast DNS results. When that company failed because our VCs and the CEO they installed decided we should go head to head with Akamai and invest all our money in global colocation fees, I thought long and hard about where to go next and decided I didn't yet know enough about networking. So I took at a job as the team lead for Arbor Networks Peakflow DOS, an anti-DOS product now deployed on the backbones of to a first approximation all the Internets. Peakflow worked by consuming NetFlow records from the backbone Cats and GSRs of companies like AT&T; ie, it binned and computed stats for a large percentage of all the packets traversing the--- what would you call it? Yeah, the Internet. Your call whether my career experience as a network designer, a network operator, a provider of network management and performance monitoring tools, and a kernel network software developer is germane to the discussion. Have we dispensed with the part of this thread where we wonder whether I have any business having ideas about how the Internet might work, and move on to the part where you actually try to shoot down those ideas? The former conversation is irritating, because I'm re-explaining things you could have found out simply by reading my public LinkedIn profile. But I would love to be proven wrong on my ideas; that would involve me actually learning something. I think you now owe me your best shot at taking down the actual notion of a next-gen Internet built as an application-layer overlay.

JoachimSchipper 13y ago

Um, you're aware that he wrote http://insecure.org/stf/secnet_ids/secnet_ids.html http://insecure.org/stf/secnet_ids/secnet_ids.html, worked for a networking (security) company (Arbor) for years, etc.? He may be wrong, and he may think that he knows more than he actually does, but he does know a thing or two. ;-) Regarding overlay networks: note that HTTP, WebSocket, Skype, BitTorrent and such are already looking quite a bit like an overlay network, and that increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. I'm not sure I particularly like this vision of the future, and I agree that the performance will be worse, but it's far from insane. (As to performance, note how everything is routed over HTTP these days, despite it being rather inefficient for lots of use cases.)

nknighthb 13y ago
Forgive me, as I don't have time at the moment to review the paper in detail, but none of what I see skimming through it really contradicts what I already believed. Knowing how the protocols work is not the same thing as knowing how to architect and manage large networks. The "overlay" networks you speak of are already hamstrung by the shrinking ability to directly address endpoints on the Internet. IPv4's fundamental flaws when applied to billions of nodes cannot be papered over forever.
- wglb 13y ago
  I don't have time at the moment to review the paper in detail, But you have time to make multiple complaints about tptacek not knowing what he is talking about? May I suggest you withdraw from this line of argument?
  - nknighthb 13y ago
    > May I suggest you withdraw from this line of argument? May I suggest that you look at the paper in question and realize it is one that requires careful and uninterrupted attention for an extended period of time to properly understand? May I also suggest that you not make assumptions as to what another person is or is not doing, and how it may interfere with their ability to do some things but not others? Or would you rather just be a judgmental, holier-than-thou asshole?
    - tptacek 13y ago
      As a reminder, this is what you said upthread: My conclusion is that his application-level networking experience has fooled him into thinking he knows more than he does about actual network architecture, management, and performance issues. Or maybe he doesn't realize the issues even exist. My conclusion is that you made that comment having absolutely no idea what my experience was, and then decided to get pissy when the facts didn't line up with your bet. I've made the same dumb bet on HN a bunch of times. "This is just some Ruby dork who knows fuck all about", I don't know, "tax law". It never works out for me, either. The thread is now full of technical commentary about the point I made. Lots of smart people disagree with me; no surprise! You've contributed none of that commentary. Maybe now's a good time to start? You seem to feel passionately about the issue.
      - nknighthb 13y ago
        > you made that comment having absolutely no idea what my experience was I made the comment based on the fact that the only thing you ever talk about actually doing is security-related. On everything else, you just pontificate context-free. You implied earlier I should have looked at your "public linkedin profile". You should know that, for me, your profile contains nothing but your current and past employers, and your university. Nothing about what you did there. What was I supposed to conclude from that? I've spent most of my career working for companies that do video-related work, but if you ask me a question about MPEG transport streams, I'll refer you to the guy who, y'know, actually deals with MPEG. At this point I am pissy, yes, but that's not because I was wrong, it's because of the asshole who decided he knows better what my personal time commitments are than I do. > The thread is now full of technical commentary about the point I made. No, it isn't. The thread is full of cursory rejections of your equally cursory commentary. There is absolutely nothing interesting about any of it, because it's all surface bullshit that everybody already knows. There are no details. There's nothing concrete. There's nothing new. Boring, hand-wavy crap. Propose something concrete, something that actually addresses the obvious criticisms you already know are going to be leveled, and I might get interested. Right now, all I'm interested in is ignoring HN for a while.
ginko 13y ago
>increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. which is a bad thing.
- tptacek 13y ago
  It's a bad thing now, because the only way to get assured direct connectivity to the "Internet" is via IPv4 connectivity. It would be less of a bad thing if IPv4 connectivity (specifically: what ASN was advertising the IPv4 prefixes your traffic was associated with when it traversed, say, Telecom Malaysia) wasn't the sine qua non of global connectivity, in the same sense that nobody cares what IP address you use when you connect to IRC.
  - ay 13y ago
    You can connect to IRC because the IRC server is not behind a NAT. Try to run an IRC server on your host which runs behind the consumer NAT which runs behind the CGN. Yes, if the gear supports it, you can use uPNP for the first, and PCP for the second, to open up a port. Unless someone is using it already. Then you need to choose another port. Which you need to communicate to the other clients behind the NATs around the world. Fine, we'll just update the DNS server with an SRV record. You probably will always have a spare public IPv4 address to map the ports 53 to something on the inside network, so this might work. Until your CGN does not have enough IPv4 addresses/ports to permanently allocate one to you. Oh, by the way this is a great way to introduce a "premium" tier service with a public IP address - if you really want to run a server then you can buy an address. So doing the PBX-style circuit switching with NATs is not really in the economic interest of the ISPs. (Not saying that they need to do all the accounting/logging). If the app is awesome enough that the users will pay extra to get the public address - great. That will help to further exhaust the IPv4 addresses and drive the prices up. Rinse, repeat. I am of course exaggerating. But this presentation from NANOG may be a less biased view (though Lee's employer does deploy IPv6, so you can argue it is biased): http://www.nanog.org/sites/default/files/wed.general.howard.gametheory.17.pdf http://www.nanog.org/sites/default/files/wed.general.howard.... Full disclosure: I am into this IPv6 thing. Before that, I spent ~10 years of my life at a random 5-letter vendor to find the bugs in the code and misconfigurations causing outages in people's NATs. It's refreshing to be able to use access-lists again. (the latter statement is only partially correct, but this is a topic for another rant, IPv6 has tons of its warts as well :-)

tptacek 13y ago

Well, let's see. I ran all of technical operations for Chicago's most popular indie ISP, up through the point where we were default-free BGP4 peered, in the era where every customer connection every day was an OSPF recalculation. Then I took a job that required me to write the clientside for every protocol exposed on a "modern network" circa 1996, including FTP, TFTP, NFS, SunRPC, DNS (for which I had to write 3 different recursors and an authority server to do serverside-serverside testing), RIP(!), and lord knows what else. Our product was a network security scanner, before there was Nessus, that worked by actually testing for bugs instead of doing banner grabs. I moved to a research role in that job and built a testsuite for network intrusion detection systems based on a line-by-line audit the 4.4BSD IP stack, then used it to reverse engineer the behaviors of the Windows NT and Solaris (then closed-source) IP stacks, and used that to discover (with my then-partner Tim Newsham) 3 new classes of attacks/bugs on network observation tools. Incidentally: I did that research because I have an ethical problem with unchecked network surveillance. Half this site seems to think I'm a secret government agent. Then I started, with two friends, a chat company that pivoted into multicast content delivery. My role on the dev team was the routing system, which implemented a multicast link-state routing protocol and a multicast service model comparable to PIM; I was also the project manager for our global traffic management system, which took full BGP4 feeds from the networks of friends of mine that ran backbones, and used them to compute anycast DNS results. When that company failed because our VCs and the CEO they installed decided we should go head to head with Akamai and invest all our money in global colocation fees, I thought long and hard about where to go next and decided I didn't yet know enough about networking. So I took at a job as the team lead for Arbor Networks Peakflow DOS, an anti-DOS product now deployed on the backbones of to a first approximation all the Internets. Peakflow worked by consuming NetFlow records from the backbone Cats and GSRs of companies like AT&T; ie, it binned and computed stats for a large percentage of all the packets traversing the--- what would you call it? Yeah, the Internet. Your call whether my career experience as a network designer, a network operator, a provider of network management and performance monitoring tools, and a kernel network software developer is germane to the discussion. Have we dispensed with the part of this thread where we wonder whether I have any business having ideas about how the Internet might work, and move on to the part where you actually try to shoot down those ideas? The former conversation is irritating, because I'm re-explaining things you could have found out simply by reading my public LinkedIn profile. But I would love to be proven wrong on my ideas; that would involve me actually learning something. I think you now owe me your best shot at taking down the actual notion of a next-gen Internet built as an application-layer overlay.