4 ms·

If I could waive a magic wand I'd rework TCP/IP as follows: - reduce routing table sizes by using explicit AS routing - have src and dst AS numbers in I

If I could waive a magic wand I'd rework TCP/IP as follows: - reduce routing table sizes by using explicit AS routing - have src and dst AS numbers in IP packet headers and route based on explicit AS numbers - that would require a decent network prefix to AS number lookup service - maybe reduce IPv6 address sizes to 64 bits - complete deployment of rpsec - make TCP a bit more dynamic (e.g., change window scaling after handshake) - fix IPsec -- specifically get RFC5660 implemented everywhere, add channel binding support

gruez 6y ago
>reduce routing table sizes by using explicit AS routing >that would require a decent network prefix to AS number lookup service I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection. > - maybe reduce IPv6 address sizes to 64 bits why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.
- xxpor 6y ago
  >why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways. It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns. BTW, if we're going to radically reimagine the internet, we should really push for a 9000+ MTU.
  - mytailorisrich 6y ago
    I think the point of 128 bit addresses in IPv6 is that it is effectively unlimited and thus won't cause problems and can make address allocation simpler. It's a bit like the maxima in ZFS. Current technology allows to pick maxima so large that we can just forget about them, so why not do it?
    - xxpor 6y ago
      Oh I'm not advocating for it, I'm just saying that'd be the argument. I think avoiding a new L3 transition ever again is well worth the tradeoff.
  - gruez 6y ago
    >It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns. So in cases where we're packet limited and not bandwidth limited we'd get a 1.1% throughput boost (1460 IP payload vs 1476). Seems like a fair tradeoff for never having to worry about NAT or address exhaustion ever again.
  - betaby 6y ago
    1. All Tier1 ISP have mtu of at least 4470 since forever. 2. Most Tier1 ISP have 9000 ip mtu for a long time.
    - xxpor 6y ago
      Eyeball networks don't though. In fact, a decent number (at least in the US) still run PPPoE, shaving off even more.
      - betaby 6y ago
        Consumer networks lags badly, indeed. And inventing random new protocols won't fix limitations of MTU.
    - gruez 6y ago
      How does that work with connections (eg. consumer ISPs) that use <= 1500 MTU? If there's even one router in your path that doesn't accept high MTUs, any benefits will evaporate. So basically high MTUs are only really useful for datacenter <-> datacenter connections, where you can reliably get high MTUs throughout the entire path.
      - pas 6y ago
        So, if we're talking about reworking everything, then ... just burn those middleboxes. IPv6 already mandates path MTU discovery and min MTU of 1280.
- zrm 6y ago
  > I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection. The better way to do it is to forget about a lookup service and make the AS number a part of the IP address. This is why you do want 128-bit addresses. You could make the AS the first 32 bits of the address and then each AS would have four billion /64 networks. But in practice this is basically what you get with IPv6 anyway. The problem with IPv4 is that because there aren't enough addresses, you have people wanting to add dozens of network prefixes to the same AS because they couldn't get a single contiguous block large enough for their needs. With IPv6 you can give every AS a /32 with 96 bits worth of addresses in it and they'd never need another one.
  - talideon 6y ago
    That is genuinely genius. It's just a pity it didn't occur to anyone back in the day. Edit: OK, not sure why that got a downvote. Did somebody think I was being sarcastic or something?
  - cryptonector 6y ago
    Well, sure, if address portability doesn't matter. Which... it kinda doesn't, so, sure. But AS numbers don't need to be much bigger than 24 bits, so 64 bits for addresses is plenty :)
    - zrm 6y ago
      Existing AS numbers are 32-bit, but sure, 24 is probably enough. The problem is with 64-bit addresses you'd only have 40 bits left for the whole AS. They'd quickly run out if they gave each customer a 32-bit block, so they'd have to use 20-bit blocks or so. Then you have corporate customers who want to do complex internal subnetting, for which 20-bit wide blocks are administratively burdensome. 10.0.0.0/8 is 24-bit and they already run into problems there. They start having to use variable-sized subnets because the main office needs a 14-bit wide block but you don't have enough addresses to give every office that many, and then you have to renumber any time the size of an office changes, and probably renumber two other offices to free up a large enough contiguous address block. That all goes away if you can give every customer billions of addresses and they don't have to worry about their subnets being "too big" which means they never end up being too small.
jeroenhd 6y ago
I wouldn't bother with AS numbers in IP packet headers because it requires a mechanism of syncronising AS routes on the client side while the client should not be bothered with routing. The idea of BGP works fine but needs to have the proper security measures in place. I don't think TCP/IP should contain complex routing systems like that. I'd love to have IPsec to become the HTTPS for all protocols but there's no way that's going to happen without a proper mechanism to support random connections. My attempts at making IPsec work for communication between devices (so not just L2TP VPNs) so far have all been thwarted by complicated software configurations and outdated guides with questionable security recommendations.
- talideon 6y ago
  Of having AS numbers in the IP packet isn't actually all that bad. It's just a matter of where. This comment (https://news.ycombinator.com/item?id=23418691 https://news.ycombinator.com/item?id=23418691) from elsewhere on the thread suggests making the ASN the top 32 bits of the IPv6 address, which would solve a whole slew of issues. Clients don't (and shouldn't) care about the routing information built into the address, but building the ASN into the IP address isn't so bad. And to keep things compact, the ASN could be in little endian order.
ThePowerOfFuet 6y ago
Did you hard-wrap your text when you submitted your comment? If so, please don't do that.
- AnonC 6y ago
  They used indentation, which works badly for longer lines on mobile on HN. A better way would’ve been to just used bullets and newlines.
api 6y ago
I would definitely shorten IPv6. If IPv6 had been 64-bit it would already have replaced IPv4. The loooooooong addresses are a huge usability problem, and usability is the largest influencing component for adoption. Advocates seem to respond by saying "use DNS," which shows me that they've never really done any IT work or are forgetting their experience. Every IT person knows "its always DNS." When DNS is down, the first thing you have to do is type IPs. You also have to type IPs a lot when setting things up, often on keyboards hanging off things in data centers and other inconvenient spots. Don't get me started on embedded stuff. If IPv6 continues to stall, I think it might be worth introducing an RFC to retroactively shorten it. You'd leave the addresses the same really but you'd re-interpret the first 64 bits as the IP and the last 64 bits as a kind of extended port field. Specifying those bits is optional and they default to zero. Then change assignment recommendations so every ISP endpoint gets at least a /48 (/40 preferred, /32 for business and larger links) and deprecate SLAAC in favor of DHCP6. Lastly change the representation to something like: feed.d00d.dead.beef[.deadbeefcafebabe] (that's valid hex for anyone who doesn't know that's valid hex) Anything whose least significant bits are all zero like feed.d00d.0.0 would of course be an IPv4 address.
- zrm 6y ago
  There are various ways to make this less painful. To start with, use anycast DNS so you don't have to type the address of your DNS server(s) into anything, and have a local DNS server with your local names in it so they all still work even if upstream is down. Then give important machines simple addresses. Assigning your DHCP server [network prefix]::3 and your file server [network prefix]::4 instead of [network prefix]:[64-bit random number] simplifies things a lot. You can also do this with link-local addresses, so then your local file server can be accessed as fe80::4, or something not too far away from that with ULAs if it's not on the same network segment, e.g. fc00:abcd::4.
  - api 6y ago
    That sounds complex. That's fine for large operations or operations with deep technical talent, but what about the vast majority of people who have less expertise and less time/resources to deploy complex configurations? Also what about the vast, vast number of cases where you want to address private backplane networks and do things like "ping 10.0.0.2"? People still largely use V4 there even if they have V6 because V6 is too inconvenient. DNS fixes this problem on connected, configured systems when everything is working property. It does not fix the problem when there are issues or when things are being set up, developed with, debugged, etc.
C1sc0cat 6y ago
Produce a replacement for IPv6 that interworks better with IPv4 - then take Ipv6 out back and drown it in Lake Geneva
- neilalexander 6y ago
  > interworks better You know that they are totally separate protocols, right?

gruez 6y ago

>reduce routing table sizes by using explicit AS routing >that would require a decent network prefix to AS number lookup service I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection. > - maybe reduce IPv6 address sizes to 64 bits why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.

xxpor 6y ago
>why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways. It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns. BTW, if we're going to radically reimagine the internet, we should really push for a 9000+ MTU.
- mytailorisrich 6y ago
  I think the point of 128 bit addresses in IPv6 is that it is effectively unlimited and thus won't cause problems and can make address allocation simpler. It's a bit like the maxima in ZFS. Current technology allows to pick maxima so large that we can just forget about them, so why not do it?
  - xxpor 6y ago
    Oh I'm not advocating for it, I'm just saying that'd be the argument. I think avoiding a new L3 transition ever again is well worth the tradeoff.
- gruez 6y ago
  >It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns. So in cases where we're packet limited and not bandwidth limited we'd get a 1.1% throughput boost (1460 IP payload vs 1476). Seems like a fair tradeoff for never having to worry about NAT or address exhaustion ever again.
- betaby 6y ago
  1. All Tier1 ISP have mtu of at least 4470 since forever. 2. Most Tier1 ISP have 9000 ip mtu for a long time.
  - xxpor 6y ago
    Eyeball networks don't though. In fact, a decent number (at least in the US) still run PPPoE, shaving off even more.
    - betaby 6y ago
      Consumer networks lags badly, indeed. And inventing random new protocols won't fix limitations of MTU.
  - gruez 6y ago
    How does that work with connections (eg. consumer ISPs) that use <= 1500 MTU? If there's even one router in your path that doesn't accept high MTUs, any benefits will evaporate. So basically high MTUs are only really useful for datacenter <-> datacenter connections, where you can reliably get high MTUs throughout the entire path.
    - pas 6y ago
      So, if we're talking about reworking everything, then ... just burn those middleboxes. IPv6 already mandates path MTU discovery and min MTU of 1280.
zrm 6y ago
> I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection. The better way to do it is to forget about a lookup service and make the AS number a part of the IP address. This is why you do want 128-bit addresses. You could make the AS the first 32 bits of the address and then each AS would have four billion /64 networks. But in practice this is basically what you get with IPv6 anyway. The problem with IPv4 is that because there aren't enough addresses, you have people wanting to add dozens of network prefixes to the same AS because they couldn't get a single contiguous block large enough for their needs. With IPv6 you can give every AS a /32 with 96 bits worth of addresses in it and they'd never need another one.
- talideon 6y ago
  That is genuinely genius. It's just a pity it didn't occur to anyone back in the day. Edit: OK, not sure why that got a downvote. Did somebody think I was being sarcastic or something?
- cryptonector 6y ago
  Well, sure, if address portability doesn't matter. Which... it kinda doesn't, so, sure. But AS numbers don't need to be much bigger than 24 bits, so 64 bits for addresses is plenty :)
  - zrm 6y ago
    Existing AS numbers are 32-bit, but sure, 24 is probably enough. The problem is with 64-bit addresses you'd only have 40 bits left for the whole AS. They'd quickly run out if they gave each customer a 32-bit block, so they'd have to use 20-bit blocks or so. Then you have corporate customers who want to do complex internal subnetting, for which 20-bit wide blocks are administratively burdensome. 10.0.0.0/8 is 24-bit and they already run into problems there. They start having to use variable-sized subnets because the main office needs a 14-bit wide block but you don't have enough addresses to give every office that many, and then you have to renumber any time the size of an office changes, and probably renumber two other offices to free up a large enough contiguous address block. That all goes away if you can give every customer billions of addresses and they don't have to worry about their subnets being "too big" which means they never end up being too small.

jeroenhd 6y ago

I wouldn't bother with AS numbers in IP packet headers because it requires a mechanism of syncronising AS routes on the client side while the client should not be bothered with routing. The idea of BGP works fine but needs to have the proper security measures in place. I don't think TCP/IP should contain complex routing systems like that. I'd love to have IPsec to become the HTTPS for all protocols but there's no way that's going to happen without a proper mechanism to support random connections. My attempts at making IPsec work for communication between devices (so not just L2TP VPNs) so far have all been thwarted by complicated software configurations and outdated guides with questionable security recommendations.

talideon 6y ago
Of having AS numbers in the IP packet isn't actually all that bad. It's just a matter of where. This comment (https://news.ycombinator.com/item?id=23418691 https://news.ycombinator.com/item?id=23418691) from elsewhere on the thread suggests making the ASN the top 32 bits of the IPv6 address, which would solve a whole slew of issues. Clients don't (and shouldn't) care about the routing information built into the address, but building the ASN into the IP address isn't so bad. And to keep things compact, the ASN could be in little endian order.

ThePowerOfFuet 6y ago

Did you hard-wrap your text when you submitted your comment? If so, please don't do that.

AnonC 6y ago
They used indentation, which works badly for longer lines on mobile on HN. A better way would’ve been to just used bullets and newlines.

api 6y ago

I would definitely shorten IPv6. If IPv6 had been 64-bit it would already have replaced IPv4. The loooooooong addresses are a huge usability problem, and usability is the largest influencing component for adoption. Advocates seem to respond by saying "use DNS," which shows me that they've never really done any IT work or are forgetting their experience. Every IT person knows "its always DNS." When DNS is down, the first thing you have to do is type IPs. You also have to type IPs a lot when setting things up, often on keyboards hanging off things in data centers and other inconvenient spots. Don't get me started on embedded stuff. If IPv6 continues to stall, I think it might be worth introducing an RFC to retroactively shorten it. You'd leave the addresses the same really but you'd re-interpret the first 64 bits as the IP and the last 64 bits as a kind of extended port field. Specifying those bits is optional and they default to zero. Then change assignment recommendations so every ISP endpoint gets at least a /48 (/40 preferred, /32 for business and larger links) and deprecate SLAAC in favor of DHCP6. Lastly change the representation to something like: feed.d00d.dead.beef[.deadbeefcafebabe] (that's valid hex for anyone who doesn't know that's valid hex) Anything whose least significant bits are all zero like feed.d00d.0.0 would of course be an IPv4 address.

zrm 6y ago
There are various ways to make this less painful. To start with, use anycast DNS so you don't have to type the address of your DNS server(s) into anything, and have a local DNS server with your local names in it so they all still work even if upstream is down. Then give important machines simple addresses. Assigning your DHCP server [network prefix]::3 and your file server [network prefix]::4 instead of [network prefix]:[64-bit random number] simplifies things a lot. You can also do this with link-local addresses, so then your local file server can be accessed as fe80::4, or something not too far away from that with ULAs if it's not on the same network segment, e.g. fc00:abcd::4.
- api 6y ago
  That sounds complex. That's fine for large operations or operations with deep technical talent, but what about the vast majority of people who have less expertise and less time/resources to deploy complex configurations? Also what about the vast, vast number of cases where you want to address private backplane networks and do things like "ping 10.0.0.2"? People still largely use V4 there even if they have V6 because V6 is too inconvenient. DNS fixes this problem on connected, configured systems when everything is working property. It does not fix the problem when there are issues or when things are being set up, developed with, debugged, etc.

C1sc0cat 6y ago

Produce a replacement for IPv6 that interworks better with IPv4 - then take Ipv6 out back and drown it in Lake Geneva

neilalexander 6y ago
> interworks better You know that they are totally separate protocols, right?