381–390 of 399 posts
Earlier quoted context omitted.
Just use home.arpa from https://tools.ietf.org/html/rfc8375 with a custom DNS server or host file. Or one of the many dynamic DNS systems.
Sure, because a custom DNS server is easy to set up.
Earlier quoted context omitted.
if it doesnt do ipv6 it's broken
I think that is an overstatement. A car is not broken because it does not drive on rail, you can get you to the same places. There is currently very little you cannot do without IPv6.
There are ways to solve the IPv6 problem - and ISPs in Europe have successfully rolled out both major variants, Dual Stack (Native IPv4 and v6 running alongside each other) or DSLite (Native IPv6 throughout the network, CGNat at the edge for tunnelled IPv4 traffic).
Liberty Global have opted for DSLite, the last major network of theirs will go live this year (Virgin Cable), BT and Sky (the two biggest xDSL providers) have been live for over a year at this point with Dual Stack.
Earlier quoted context omitted.
There are 3 problems with IPv6 - There is a lot in IPv6 that is different from IPv4. Ignoring if those changes are good or bad, it does make the transition harder. - IPv6 was promoted way before there was demand. To some extent it is good to prepare people (and vendors). But it does create the impression that IPv6 is a failure - Demand for IPv6 is highly asymmetrical. The party that is out of IPv4 addresses needs IPv…
I never truly delved into low level networking, but I generally got a grasp for IPv4, I can setup simple networks and I think that I understand what's going on on every level. Now despite the fact that I tried to understand IPv6 multiple times, I failed miserably all the time. I tried to setup IPv6-over-IPv4 OpenVPN, it did not work despite all efforts. IPv6 is just too complex. At this point I wish that IPv6 would b…
server-ipv6 your-ipv6-subnet-for-clients push "route-ipv6 subnet-you want-to-route" (either your real subnet, or 2000::/3 for all traffic).
You need the same for the IPv4 side of things too.
Clients need no change.
Earlier quoted context omitted.
As a network application developer I haven't felt much pain from NAT - I need to run a central server to relay connections, but that's about it. And oftentimes I need to run a central server anyway for discovery or authentication. (A few years ago I worked at a startup that enabled secure remote access to corporate networks, as in you could connect from a roaming laptop or mobile app into the network, browse the web,…
>we asked people to install and forward a port on their NAT for At this point I no longer believe you. Having worked in the ISP industry for quite some time, only a very small portion of the more technically advanced users can do this successfully. Most users dont remember their passwords to even get in their device. Just because windows firewall security is balls doesn't justify writing a nat helper or proxy for eve…
Earlier quoted context omitted.
This can be deployed quite quickly if mandated as a requirement for any ISP to operate (ISPs usually need some license from local municipalities or something of the sort). They'll implement it in an instant. Otherwise, they'll just sit doing nothing, and it remains a chicken and egg problem.
No, a municipality can require nothing beyond a business license to sell services in their jurisdiction.
What we really need is a killer app that requires end-to-end connectivity. Users have little reason to care about IPv6 right now because the existing ecosystem of services has evolved around the constraints of NAT. As IPv6 deployment expands hopefully we will reach a point where some great new application becomes economically viable. My biggest fear is such an application not emerging quickly enough. Without an imper…
"Users have little reason to care about IPv6 right now" Uhm, 'users' should not ever have to know what 'IP' even is! If they do, we have failed.
Earlier quoted context omitted.
I use copy and paste for both IPv4 and IPv6 addresses. I understand where you are coming from by adding a few more bytes to the address scheme but one of the things IPv6 was designed for was massive address aggregation which means really short routing tables. Your 192.192.168.168.0.0 (say) scheme does not go far enough. Also, your scheme needs to be efficient in the world of bits and bytes and I don't think it is. Yo…
The recommendation is to assign a /56 to end users from an ISP. That would give you plenty of subnets to work with. /56 == 256 /64s Each /64 == 18,446,744,073,709,551,616 addresses
Each subnet (/64) is 18,446,744,073,709,551,616 addresses - which is nice.
Earlier quoted context omitted.
More issues with IPv6 that are relevant for me as a techie: - Memorising an IPv4 address is about as easy as memorising a phone number, which is to say, fairly easy. I remember the iPv4 addresses of both my rental servers, every device on my home LAN, a bunch of public DNS servers if things go wrong, ...; there's no way I'm going to be able to do that for IPv6. - At least last time I tested it (more than 10 years ago…
NATs break end to end. This might be acceptable in a HTTP(s) only world though. Of course, some people aren't only using the Internet for browsing. The Internet of things will end up needing unique endpoints, and NAT does not play will with those either. India has a lot of people, and quite a few of them will be IPv6 only (or behind a very degraded carrier grade NAT). If you are talking to customers/clients/vendors t…
I was always curious about this argument -- do you mean that NAT elimination will allow any two arbitrary devices to communicate with each other?
I would think that even in IPv6 world, the firewalls would still be a necessity. Most ISP would continue shipping routers with stateful firewall enabled by default (to prevent internet exploits), so any peer-to-peer software would still have to deal with UPnP/STUN/TURN. Sure, the STUN protocol will be simplified a bit because it would not need to worry about IP changing, but it would still be way more complex than just a simple connect() call.
Note that the situation maybe better in some cases -- like for India or for cell phone networks -- but there would still be enough people behind the firewall to make arbitrary incoming connections unreliable.
Related: the privacy extensions seem to be a pretty bad idea. I have no idea how would I set up a firewall to say "allow incoming traffic to my main laptop, port 22222" if it's IP address always changes. Ideas like "disable privacy extensions" and "filter by MAC" have their own significant downsides.
Earlier quoted context omitted.
You're mixing up NAT and ingress blocking. A stateful firewall doesn't depend on NAT, we're just used to ingress blocking as a side effect of NAT.
If a firewall isn't doing ingress blocking then it doesn't really serve much of a purpose now does it? Ingress blocking being a side effect of NAT is the whole point of equating it to a firewall. It's roughly similar for all intents and purposes except that it also provides socket translation, and socket translation is really useful so every firewall worth mentioning also provides NAT. That ipv6 initially did not add…