Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The New Internet

tailscale.com

Post reply on HN
Print view View original

171–180 of 315 posts

Re: The New Internet

#171

Post by throw0101d »

Borg3 wrote: post #158
throw0101d wrote: post #146

Earlier quoted context omitted.

> Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. ARP poisoning is the least of ARP's problems. It can potentially have a blast radius that can bring down networks, and if it was actually sorted out, then things like BGP EVPN would not need to have been invented. One of touted benefi…

That is not ARP problem. Its called broadcast storm and its problem of stupid people and/or bad equipment. You can bring any network down with incompetence. Thats why newer switches have STP, DHCP Snooping, ARP security and so on. Now take a look at ND tables exchaustion alone. Trival attack to do on IPv6 segment. Is it solved yet? I dont know. I do NOT track it. The whole PnP (I call it Plug and Pray) is terrible ap…

> That is not ARP problem. Its called broadcast storm and its problem of stupid people and/or bad equipment. You can bring any network down with incompetence.

It's a footgun. All footguns have ways to not trigger them, but saying you can't blow off a leg is also inaccurate. Reducing the number of footguns laying about is generally a good thing

> Now take a look at ND tables exchaustion alone.

No different than ARP table exhaustion (a finite L2-L3 mapping table). "First hop security" is a thing in both protocols.

> So, IPv6 should be simple, easy to implement and so less prone to mistakes. All extras should be put layer up.

I would argue that IPv6 is simpler to get going than IPv4: to start you don't need BOOTP/DHCP. In fact IPv4 later took some ideas from IPv6, e.g., 169.254.0.0/16 link-local addresses:

    This document describes a method by which a host may automatically
    configure an interface with an IPv4 address in the 169.254/16 prefix
    that is valid for Link-Local communication on that interface.  This
    is especially valuable in environments where no other configuration
    mechanism is available.  The IPv4 prefix 169.254/16 is registered
    with the IANA for this purpose.  Allocation of IPv6 Link-Local addresses
    is described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].
* https://datatracker.ietf.org/doc/html/rfc3927

Re: The New Internet

#172

Post by api »

throw0101d wrote: post #165
api wrote: post #161

Earlier quoted context omitted.

There is another reason: the addresses are long and impossible to remember and hard to type. I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns. Even “small” usability differences can have a huge effect on adoption.

> There is another reason: the addresses are long and impossible to remember and hard to type. If only there was some mechanism in which we could use a human-friendly label and have that translated to a computer-usable address… > I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns. I don't bother remembering IPv4 addresses, so I'm not sure why I would bother to…

The problem is that DNS is not zero configuration. ARP and NDP are which is why nobody complains about Ethernet being hard to type. DNS has to be “stood up” which is a whole extra deployment.

In modern devops in particular it is common to create and tear down IP networks in seconds and sling stuff everywhere. The extra moving part is an extra thing to break.

DNS also runs over IP which means if IP is down DNS doesn’t work. What do you have to do then? You have to debug IP without DNS.

There is mDNS but it’s not reliable and doesn’t scale to large networks. It also runs on the IP layer so if there is a problem there it can break.

Re: The New Internet

#173

Post by phantompeace »

aquariusDue wrote: post #128
k_bx wrote: post #88

I'm one of the people who actually use Tailscale for production systems where there are servers physically close to me, or at some other controlled locations, and then there are hundreds of users hundreds kilometers away, all working via Tailscale. I should say two things. Tailscale is amazing and I love it. The system could not exist without it, or I'd have to have at least ten more people in my team to manage all t…

Would you mind going into more detail about the 4-core Linux Laptop as a production server via Tailscale, please? I too use Tailscale and love it for self-hosting internal stuff but I never thought about using it for public facing production stuff. Now I'm really curious to hear more about your setup (if you're willing to share of course).

Not the person you’ve asked but I regularly use it for backends for projects. Connect your database machine to your Tailscale network and have your code talk over the Tailscale IP to connect to it. I’ve served multiple Flask frontends that have talked to backends this way - works great! I use various cloud VMs to host the frontend, and they all talk to an Optiplex Micro box under my desk for their backends.

Re: The New Internet

#174

Post by throw0101d »

viraptor wrote: post #139
throw0101d wrote: post #132

Earlier quoted context omitted.

> What kind of Nat though? You can use upnp, predictable mapping, etc. and still allow the traffic through. Your computer can talk to your home router (CPE) and punch a hole for a connection, but if your WAN port does not have a public IP address, but rather itself also has a private address (probably 100.64/10), the CPE cannot talk to the ISP's router to punch a hole: * https://en.wikipedia.org/wiki/Carrier-grade_NA…

Double Nat on one side is not that universal. Across Europe and Australia I've seen it maybe once on a residential connection. I'm sure it's used, but the comment about the US in the post above just doesn't match my experience.

Great for you for not having to experience it, but that doesn't mean it sucks any less for those less fortunate:

> Our [Native American] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* Discussion: https://news.ycombinator.com/item?id=35047624

Re: The New Internet

#175

Post by throw0101d »

api wrote: post #172
throw0101d wrote: post #165

Earlier quoted context omitted.

> There is another reason: the addresses are long and impossible to remember and hard to type. If only there was some mechanism in which we could use a human-friendly label and have that translated to a computer-usable address… > I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns. I don't bother remembering IPv4 addresses, so I'm not sure why I would bother to…

The problem is that DNS is not zero configuration. ARP and NDP are which is why nobody complains about Ethernet being hard to type. DNS has to be “stood up” which is a whole extra deployment. In modern devops in particular it is common to create and tear down IP networks in seconds and sling stuff everywhere. The extra moving part is an extra thing to break. DNS also runs over IP which means if IP is down DNS doesn’t…

> The problem is that DNS is not zero configuration.

Certainly it is not-zeroconf, but it is the same not-zeroconf for both IPv4 and IPv6.

But extra work with DHCP is needed for IPv4, and extra-extra work if you need to do things like configure 'IP helper', whereas IPv6 can be configured using only a router (which you need regardless) and some on-link packets (RAs).

> DNS also runs over IP which means if IP is down DNS doesn’t work. What do you have to do then? You have to debug IP without DNS.

And? At least you have fe80/64 as a basic starting point. Run a tcpdump to see if you're on-link in any way (or in the correct VLAN), and if you are, you can then ping(6) ff02::2 to find if there any on-link routers. You've now debugged Layer 2 and Layer 3 connectivity. Tada.

You're making IPv6 (sound) way more complicated than it is. It is no more or less complicated than IPv4 or IPX/SPX or …. It's protocol data units at OSI Layer 2 or 3 in different formats with different fields.

Re: The New Internet

#176

Post by ndriscoll »

teddyh wrote: post #142
tomjen3 wrote: post #137

Earlier quoted context omitted.

I think that is excessively negative take. Tailscales value proposition is also "you can connect to your network wherever you are, safely, and others cannot". That does not go away because of IPsec.

Network- and location-based security is ultimately unworkable. It’s like if you, in order to work, had to go to a ”virtual office” to even send mail to your colleagues. Mail, and related internet-enabled services, should be accessible from anywhere , and be secured at the end points, not at the network layer. (Most attacks are internal, anyway.)

Most people do need to be on a VPN or in an office to work. That's entirely normal, and makes sense even if you also require authentication for applications.

Re: The New Internet

#177

Post by sidcool »

I love this blog post. It resonates so much. But I honestly don't know how to deploy applications efficiently without containerization. And where there's containers there's kubernetes. So on and so forth

Re: The New Internet

#179

Post by j2kun »

iovoid wrote: post #83

I think the author misdiagnoses the problem, and the proposed solution simply hides the centralization instead of removing it. The reason AWS is expensive is not because of IPv4, or the datacenters. It's mostly in their software/managed offerings, and the ability to quickly add more servers. If you are a "serious company" and you don't want to pay AWS or a similar company, renting a rack and colocating your own serve…

This rests on the incorrect assumption, pointed out in the post, that most applications need the kind of scale that warrants quickly scaling to more servers.

Re: The New Internet

#180

Post by Bluecobra »

vwkd wrote: post #117
Bluecobra wrote: post #41

> Every device gets an IP address and a DNS name and end-to-end encryption and an identity, and safely bypasses firewalls. Tailscale can certainly be blocked on NGFW firewalls like Palo Alto. I am not a BOFH, but also can’t have random employees circumventing security policies by setting up tailscale and leaving permanent backdoors in my corporate network. I remember the good old days when everyone had a public IP on…

> can’t have random employees circumventing security policies by setting up tailscale and leaving permanent backdoors in my corporate network Tailscale isn't exactly an open door. Only machines signed-in via SSO can access a Tailscale network. If you don't trust your employees to safeguard their credentials and machines then how do you trust them at all? Keep them in an airtight underground bunker chained to their de…

I'm talking about people who want to use Tailscale for personal reasons. For example someone can setup a Tailscale instance between their work computer and home computer and circumvent the corporate VPN/MFA policies for remote access. I doubt they being malicious but what if their home PC gets hit with malware? A threat actor could then use the existing Tailscale instance to get into the corporate network.
Post reply on HN