Depending on the model though, aftermarket (or even new old stock) is readily available. If you buy used business class laptops like I do, you’re all but guaranteed to be in good shape regarding at least batteries.
> The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM
Or have whatever deployment tool that currently populates the env vars instead use the same information to populate files on the filesystem (like mounting creds).
I guess it depends on what you mean by "impossible." If you only mean that it's theoretically possible, then sure, one can imagine a world where that is done. But even with IPv4's meager 32 bits of address space, it would explode TCAM requirements on routers if routers would start accepting announcements of /32s instead of the /24s that are accepted now. And /64 (or, jesus, /128) for IPv6? That's impossible.
But it's not the only way to tackle the problem of resolving layer 2 addresses, and you can do so without introducing the layering violations and expansive broadcast traffic that ARP implies (along with the consequent problems with WiFi and such).
For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
> For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.
And actually, you can never avoid a layering violation. The only thing that NDP avoids is filling in the source/destination IP portions with placeholders. In NDP, you fill the destination with some multicast IPv6 address. But that is window dressing. You still need to know that this L3-multicast IPv6 address corresponds to a L2-multicast MAC address (or just do L2 broadcast). The NDP source you fill with an L3 IPv6 address that is directly derived from your L2 MAC address. And you still get back a MAC address for each IPv6 address and have to keep both in a table. So there are still tons of layering violations where the L2 addresses either have direct 1:1 correspondences to L3 addresses, or you have to keep L2/L3 translation tables and L3 protocols where the L3 part needs to know which L2 protocol it is running on, otherwise the table couldn't be filled.
I think that's actually about avoiding NIC to CPU traffic. NICs have multicast address filters which determine which packets to receive, but they always receive broadcast packets. It would have been more useful in the 90s, when NICs weren't so programmable.
It's pretty silly anyway. NDP is more of a layering violation than ARP, because now IPv6 has a stupid circular dependency on itself. Mapping L3 addresses to L2 is a layer below 3, it is not part of layer 3, it is part of the sub-layer that adapts between 2 and 3. DHCP should be part of that sub-layer, too.
Did you know that for every kind of network that IP can run on top of, there's a whole separate standard specifying how to adapt one to the other? RFC 894 specifies how to run IP over Ethernet networks. RFC 2225 specifies how to run IP over ATM networks.
IMHO all this whining about "layering violations" is stupid. One will always need some kind of layer glue, neighbors bordering on each other need to know something about each other, correlate addresses, etc. It is impossible to do anything practical without such violations. And it doesn't really matter if that glue protocol belongs to the below layer, the above layer or is a weird hybrid of both. Because in the end, the glue will necessarily be a hybrid and it will be specific to the combination of both those layers.
The only thing one should really really really avoid is the TCP mistake of not just having some minimally necessary glue, but that tight coupling of TCP connections to IP addresses in the layer below.
It's a layering violation because it makes the inter-layer-glue more messy than it should be. IPv6 having a circular layer dependency on itself is not a good thing. It makes that glue messy. ARP is cleaner glue.
> Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.
True, but outside bottom-barrel switches, any switch that's not super old should support multicast, no?
Regarding the rest of your comment, I really don't see how all those things count as layering violations. Yes, there is tight coupling (well, more like direct correspondence) between l2 and l3 addresses. However, these multicast addresses are actual addresses furnished by IPv6; nodes answer on these addresses. Basically, the fact that there is semantic correspondence between l2 and l3 is basically an implementation detail. Whereas ARP even needs its own EtherType!
And, yes, nodes need to keep state. But why is that relevant to whether or not this is a layering violation? When two layers are separate, they need to be combined somewhere ("gluing the layers together"). The fact that the glue is stateless seems irrelevant. But again, I'm just a sysadmin.
The ARP part of the article makes the case that there is no need for a protocol to resolve IP addresses to MAC addresses, with the argument that if only the default gateway was a MAC address rather than an IP address, there would be no need for such a protocol.
NDP may very well be a nicer protocol than ARP, but following the logic of the article, the neighbor solicitation part of NDP would be just as unnecessary as ARP.
> For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
I disagree.
With IPv4, the layers aren't quite a stack, but, logically, there's Ethernet, and on top of Ethernet is the ARP layer, and on top of that is IPv4. With the exception of DHCP, correctly functioning IPv4 hosts will actually set their source address field and speak IPv4 properly.
With IPv6, there's Ethernet. On top of Ethernet is IPv6, except that no one knows how to communicate. So there are delightful kludges like the RFC 4291 "unspecified" address, and hosts sent a packet with an "unspecified" address to do duplicate address detection prior to actually using their assigned address. To me, this smells like much more of a layering violation than ARP. Not to mention that a network that wants to optimize ARP can optimize ARP without actually interfering with IPv4 packets, but a network that wants to optimize IPv6 neighbor detection needs to mess with IPv6 packets.
> The stuff on my network assigns itself ipv6 addresses based on their mac address? That's how you can do stateless ipv6?
Nit: per RFC8064[0], most modern, non-server devices do/should configure their addresses with "semantically opaque interface identifiers"[1] rather than using their MAC address/EUI64. That stable address gets used for inbound traffic, and then outbound traffic can use temporary/privacy addresses that are randomized and change over time.
Statelessness is accomplished simply by virtue of devices self-assigning addresses using SLAAC, rather than some centralized configuration thing like DHCPv6.
That'd be really cool. I'd never thought about enabling deeper graphical capabilities in a shell. But if you were to have a shell with rich objects rather than dumb bytes, that is a world that would open up!
PowerShell, for instance, has Format.ps1xml[0] that allows you to configure how objects get displayed by default (i.e. when that object gets emitted at the end of the pipeline). Such a concept could in principle be extended to have graphical elements. How cool would it be to have grep's output let you collapse matches from the same file!
I don't see how this generalizes into a security hole caused be lack of IPv6 knowledge. It just sounds like a random bug in Snapcast (great program!). If a user configures a program to only bind to loopback, but the program binds to other interfaces as well, that's a bug in the program.
There are sure to be dozens or hundreds of vulnerabilities like this, that's what I'm saying. I'm not even sure it's a bug in snapcast - very possible I configured it wrong without realizing.
Without knowing exactly what happened here, it could be hundreds, dozens, or zero other such vulnerabilities.
The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).
Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.
But as said, it's hard to get more concrete without knowing exactly what happened in your case.
> Linux file locking is to put it mildly, deficient.
Since the introduction of flock on Linux, how bad is it really though? I don't see why one would need kludges like filename.lock. Though of course flock is still an "honor system" as you put it.
reply