You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.
On the shotgun, or adjacent, I do tend to prefer ammo classes for my nets... 10.22.x.y, where x may be 1, 38, 45, etc. Allows for site to site vpn with friends/family a bit easier to remember.
Google's DNS worked fine, but Cloudflare's didn't. No idea if they ever fixed it... I'm using it as a backup for my main connection, eventually I'll setup autofailover on my router (OpnSense). For now, I just swap the cables.
https://medium.com/@mrtcve/atts-misuse-of-cloudflare-dns-ip-...
If you're gonna do that, though, it's better if you use fd00:... or one of the other assigned ranges so it's still in the standard range. OSes use this as a heuristic for source address selection.
It's a much better compromise and ergonomics to migrate from IPv4 to an IPv4 respecting successor, where IPv6 is just the academic snobbery and utterly alien mental model for not-enough benefits.
For the same reason Unix stuck around and beat up its own successor Plan 9/inferno. That inertia even decades later is the same reason IPv4 still beats IPv6.
IPv8 is more of a linux to unix than a plan 9.
192.168.1.0/24 -> fd00:1::/64
192.168.2.0/24 -> fd00:2::/64
192.168.240.0/24 -> fd00:240::/64
It's not a great idea, but its no harder.
No need to mess around with setting up DHCP, remembering if your router is top or bottom of the subnet, and if you want 500 devices on a single subnet that's no problem.
Now if you still need ipv4 then yes, ipv6 is stupid as you have double the pain for none of the gain, but if you are ip6 only then its far easier.
I know you can just block inbound non-established connections, but it feels like an extra step and complexity. Not to mention, that I really don't understand how IPs are supposed to be provisioned to devices on IPv6. Is there like a 50-100 page book you can recommend "for dummies" on IPv6, that hopefully contains at least a tiny amount of how to configure a common router and/or linux host.
SLAAC is the only way that works across all IPV6 devices. In that mode, the router advertises the prefix and the device assigns its own address (prefix + its mac address).
DHCPv6 exists but is poorly supported. It sucks for people who like assigning IPs individually from an authoritative place (through static dhcp entries on the router). But people like us are "doing it wrong", you see? We must accept that in this brave new worlds an IP means nothing.
So it seems like it helps ISPs and large networks router… but they never had problems with address space running out at the high levels and almost all likely need to support v4 anyhow.
I think it’s been long enough to be honest that ipv6 was a spectacular failure by complicating an already complicated system into something no one actually asked for.
No human said “hey, networking sucks. Please make it much harder at my level!!”.
Lte and 5G can be v6 only, usually they also have NAT64 and DNS64 so you can get everywhere, but the less stuff that needs v4, the smaller their nat boxes are.
like 1.1.1.1/192.168.45.4 ... for a router that understands IPv6, that's the direct route to the sub-network, otherwise it will have to use IPv4, and the subnet route is treated as NAT and otherwise isolated.
To me, that would make more sense... then internal IPv6 might be practically limited to 10. and 102.168. in the nearer term, but adoption would be MUCH simpler in practice, and distribution would mostly already be established, however unfairly, but can then be broken into single addresses and vNext adoption could be that much quicker as a result of piggybacking.
I'm not familiar with IPv6's details, could you elaborate on this? To me, this reads like you're saying that IPv6 solves the problem by having low adoption rates rather than an actual function of the protocol.
The point of IPv6 was to make the addresses so long they are easy to manage.
lol, there is no doubt that had a massive opposite effect. To the point of nearly killing it in terms of willingness to adopt.
Not to mention, at home, most of the ads I do see (PiHole) are IPv6 addresses.
So yeah, having to relearn a bunch of basic network knowledge that worked just fine for decades is a PITA, and I’m 100% positive a design process that focused more on the people that need to configure networks could have yielded a much friendlier, and therefore a much easier to adopt standard.
its really extremely simple, just dont NAT, is that really so hard? just because you dont NAT, doesnt mean you have to let the traffic pass through, that is also an extremely simple concept, no?
Split subnets at four bit chunks.
Allocated networks, like to a home or small office, should be /56 or /60.
Then you have to think about link-local addresses and privacy addresses, and how to hand out IPv6 and configure DNS: SLAAC vs. DHCPv6 or some combination.
I have a rough draft of a beginner document but it's not ready. :)
Going smaller than /64 is against best practice and unnecessary. People coming from IPv4 need to understand that trying to be careful with subnet sizing for purposes of preserving space is not a thing in IPv6 below /64. Maybe if a residential user has a /64 from their crappy ISP settings they'd need to do it, but not in a properly configured scenario and certainly not in enterprise.
So I have 1.2 million million million million IPv6 addresses available.
That ought to be enough, eh?
There fixed that for you.
It's not about low adoption, it's that there are unimaginably many IPv6 addresses.
...which is a major reason for why it has low adoption
fc00::/7 is for "Unique Local Addresses". Basically, private, non-globally-routable addresses from which you can freely pick space. Kind of like RFC1918. It's deliberately huge and you should only use as much from it as you need. The idea being that if you merge with another organization or connect to them via VPN, it's unlikely your addresses will collide like with RFC 1918.
There's even a website (sites?) to register your ULA space on a volunteer basis to reduce collision chances.
Anyone in IT who allocates 1.1.1.0/24 because 192.168.0.0/24 is hard, should be allocated to trash pickup.
IPs having a global distinction between public/private is a convention, but local routing can widely differ.
Same with the "China Cyberattacks" - the guys sitting on top of my outgoing fiber can simulate any IP address they want to me.
192.0.0.0/24, 10/8, 172.16/12, and various other subslices of 192/8 are reserved for local use and are not publicly routable.
22.0.0.0/8 - it's basically free real estate!
Just to chime in agreeing with sibling comments, the issue is when it's not about just your house and you're deep into self-hosted stuff with a lot of different properties and businesses other people's houses all sharing resources. Without a lot of coordination and consideration, which in practice doesn't really happen easily given the adhoc nature such things tend to organically develop out of, and all the random stuff that wants specific addresses at least for setup, it actually gets pretty easy to run into collisions. Allocations typically are definitely inefficient in many respects but also made sense in the context they were first done and of course can be a certain amount of effort to change.
In an ideal world I sorta feel like "IPv6" should have been more along the lines of <12 octet prefix>:<IPv4>, everyone gets a prefix or set of prefixes that they actually own and are consistent worldwide, or at least only change when geographic location changes, and then can just have the entire 32-bit IPv4 space for LAN however they want. Then you only have to care about prefix between LANs and it could all be extremely automated, internally you only need to use something that looks like IPv4 with the network hardware transparently able to handle prefixes for WAN. Backwards compatibility story would be a lot more straight forward too. Oh well.
@kotaKat: that's a great idea and I don't know why I forgot I played with that like 15 years ago. Really handy as a backup space that almost certainly won't collide with any commercial hardware at least.
But one of our vendor networks uses 10.32.x.x/32 for various radio gateways, and the radios themselves all locally expose (this is where I give away too big a clue as to what I do) 10.0.0.101 as a management address that emits important link status data.
So you can imagine what a godawful bùrach everyone's routing tables are.
Crucially, we set aside the common 10.1 and 10.10 ranges as nonroutable, so any devices that default into those have to be dealt with before they can live on the wider network.
Newcomers get handed a block and have to renumber, or NAT into it, or whatever, but they cannot emit bogons. At a small scale (first-name basis), this works.
The Canadian Navy very recently made a major choice and agreed with you
https://www.google.com/search?client=firefox-b-d&q=hanwha+oc...
and while i currently don't hate china as much as i do US rn (because canadian; sorry) i can also say -- due to being an aforementioned leaflandian -- that due to very personal experience i have zero faith in anything from china that has the ability to connect to any type of network :')
And so yeah at this point if I can't at the very least get a whatever-wrt firmware (preferably a proper linux distro nowadays; not to say the *-wrt firmwares aren't a real OS but, y'know) on the device i just avoid them entirely since, well... it's all i can do at this point because even if there were baked in hardware-based backdoors i as an individual can't do much more than that.
Old thin clients are typically in the same hardware class, and probably cheaper by the time you add the exploding MSRP of a Pi, and a PSU, and a case and heatsink, and maybe some storage that doesn't suck ass. But if you already own the Pi, yeah, go for it.
Least you can do.
You can curse the storm, but the wind will come.
Was the website's security based on MAC, which presumably is supplied by the client? If so, I guess.. typical IoT.
Short story: buy one cheap dongle on Amazon, dump the MAC (00:11:22:AA:BB:CC IIRC; it's been 15 years since I cared) and you have auth to all of the apps everywhere.
Reminder: the Bluetooth logo comes, mostly, from self-certification.
Internally they're all Bluetooth to serial chips, and another pic16xxxx chip which does serial to canbus.
I guess the Bluetooth serial chips probably have programmable Mac addresses, but equally they normally ship with a globally default one unless you flash a different one onto it.
You could fix this by adding an exception to the CSS rule so it skips links starting with your site's name:
a[href*="://"]:not([href^="https://hhh.hn"])::after(Yes ok, RSA4096 is technically a matter of cost, you just need an infinite amount of money)
RE obfuscation and nation states - nation states have finite budgets too, both in terms of resources and attention. They can crack any system at any time, but they can't afford to crack all of the systems all of the time.
Entirely without LLMs, I'm imagining an office of North Korean compsci graduates doing astonishingly tedious tasks, for whom an office job on a basic Linux computer and slightly better diet and nice apartment put them in the top 1-2% of living standard in the country.
Anyone who cares about security will be using App Attest or the Google store equivalent.
I have something hilarious to tell you about IoT apps
Why? I rarely have security objectives where remote attention would help, and it has a huge impact on user freedom. For B2C attestation is just an evil captcha.
*almost, I have two things that need an app. My Vaillant boiler and my Yale alarm system. Both apps are terrible, but I have a 10 year warranty on the boiler and my alarm is up to scratch from a home insurance point of view.**
Vailant boiler - I wonder if there's a debug interface you can use. Not knowing specifics of your model, i foudn this: https://github.com/jayme-github/esphome_vaillant
Codex can help probably further heh.
https://yalehome.co.uk/yale-sync-hub
It's not really something I want 'home rolled', I just want it to work.
Same goes for the boiler really. If it stops working I can phone Valliant and they'll send someone round to fix it.
Or... the Department of Warmongers (nee DoD) addresses on the device are evidence of a supply-side attack targeting the DoW and carried out using the aforementioned github admin token.
... I mean, while we're in here speculating about truffles and all.
With many IoT type things I block access to the public internet. I think with cameras specifically a lot of people even set it up physically on a different network that can only talk to the NVR.
But tldr, basing the cameras on IP invites some of the things in this article. Anyone deploying these devices needs to think about securing them.
I feel like every security blog (or even just tech blog) I've read recently has had paragraphs and paragraphs of largely LLM generated explainer waffle. This felt refreshingly focused and to the point.
I have looked around before but I only found genuinely dev-oriented kits that weren't even in a shell, and crazy priced.
edit: seems there are some options now (or I missed them before), e.g. https://www.goodcam.io/#for-independent-developers
Some cameras do support thingino, so you can override their firmware. Then there's this: https://openipc.org/supported-hardware/featured
> Stránka nenalezena
> There's been a glitch...
> We're not quite sure what went wrong. You can go back, or try looking on our homepage.