On the other hand, if they cannot get credit, they really cannot afford to buy that house. They might be able to make the payments, otherwise, but lenders are a lot more risk averse -- and for damn good reason. Rents then naturally rise to the levels of a mortgage and *bam* the people who couldn't get financing also cannot stockpile cash to improve their ability to secure financing.
And yet, I see all the "for rent" and "space available" signs around town listing rents at basically the same rates I paid a decade ago.
The client MUST include its hardware address in the 'chaddr' field, if necessary for delivery of DHCP reply messages.
The word used is SHOULD. There are still plenty of DHCP systems that request (require) a broadcast reply. Go listen to the broadcast traffic on your cablemodem.
And I'm FAR TOO well aware of systems using the wrong hardware address in their requests -- more than one nic, and it uses the MAC from the first nic in all queries no matter which nic it's asking about or using. (and this is from an ISC DHCP client!)
TL;DR chaddr [Client Hardware ADDRess] is 16 bytes of whatever the client puts there.
(Replies in my network are broadcast so the boot agent can see them.)
Stock android has no means to handle DHCPv6. It's not there. At all. You can (maybe) root your device and (maybe) add it yourself. But that's beyond 99% of android users. ("root, run custom rom downloaded from internet" - lots of people do that.)
You can call it BS all you want, but there are environments where legal accountability is a requirement. Could you side-step their tracking voodoo? Probably, but that's even more tinkering with your android device.
Using the MAC as an ID is a flawed method. Devices come and go, MACs change (because the NIC changed, etc.) Ultimately -- and here's the end of it -- you'd have to be maintaining a registry of every device's MAC within your network to know what's what, where, and who's using it. Just gleaning a "list of mac's" is simple enough, albeit a tedious pain in the ass: arp tables, cam tables, watching broadcast traffic, etc. Knowing the location of each device gets a lot more tricky; sure wired devices will be tethered somewhere off a switch port, but that's not always enough. Wireless devices, on the other hand, can be anywhere. And none of that addresses who's device it is, who's using it, and exactly what it is. (OUI's only go so far, and assume no one is forging their MAC.)
When someone carries a device into the office, does something questionable with it, and then leaves, tracking the who/what/where/when becomes much harder. When the questionable act isn't mentioned for weeks or months, it can become impossible.
Case in point, I had to trace down a "hacker box" in the network. It was a lot easier because it was ON and ACTIVE at the time. Looking through cam tables, I could only go so far as an unmanaged hub. (yes, this company still used far too many hubs. even in 2003.) Careful inspection of the hub (and unplugging one port at a time), localized it to a desk. An unoccupied cubical, in fact. By the time I got to that desk, the machine had been turned off (it was still warm), the "warez" hard drive had been removed (windows registry remembers it), and the non-company 3com nic had been removed (again, registry -- which is how I knew 100% that's the machine I'm looking for.) That was the company computer for that desk, which is the only reason it was still there. Had he used one of his own machines, it could've simply disappeared without a trace. Moral of the story: I had a MAC, and it didn't tell me shit. The "who" was only discovered because his coworkers ratted him out:-) ("Who's been using X's computer?" They didn't know he was doing anything stupid with it.) And that only worked because it was in real time; had it been brought up a month later (nothing to trace) (and there not been a hub muddying the picture), any history logs would simply have ended with "I don't know. It was something at X's desk" [X having left the company many months ago. X's computer official off since it's builtin NIC, registered in company inventory, wasn't being used.]
so you are going to need to know, in advance, who's MAC is who's. You'd need that knowledge for a DHCP server too...
One does not pre-program the DHCP server with a list of MACs, nor does every client identify itself by MAC -- the client-id can be many things, MAC being but one of them.
In order for you to get the reply back from the DHCP server, it needs your MAC address.
*sigh* No it doesn't. A unicast reply needs a destination MAC, either the end client or a relay agent. A broadcast reply, however, DOES. NOT.
*sigh* Those devices ARE BROKEN! And the entire networking world knows it. SLAAC still requires::/64, as far as I'm aware. However, privacy extensions no longer mandate this brain damage.
Hundreds of people have warned, just as I have, that people can be (and WILL be) stupid, and thus make these blanket assumptions.
No. No sane person assumes the size of a non-local network. A lot of the world does, in fact, bow to the stupid that is SLAAC, but it's not "everywhere", nor do hardware vendors worth their salt make any such assumptions or impose restrictions -- your network can be any size you wish. Your ISP is likely to assign you a::/64 (60, or 56) because it's the lowest common denominator. (and because they tend to use cheap trash for CPEs.) Giving you anything smaller, while technically feasible, creates hurdles for people with little to no networking expertise.
And if you have android devices, it's the only way to get the damned things on your IPv6 network.
Please stop with this 64+64 BULLSHIT. There is no "host part" and "network part" in IPv6. (there isn't, anymore, in IPv4 either.) IPv6 is 100% CLASSLESS. The only thing that (currently) demands the 64/64 split is SLAAC -- BTW, it started at 80/48 -- and a network is not REQUIRED to run SLAAC. (which is the heart of the entire roasting of Google here.)
You CANNOT make such an assumption about a non-local network. You MUST know the prefix-length to know what part is "network" and which is "host". You can look up the entire 128bit address to find the assigned block (a::/48 or::/32 most likely), but beyond there, you rather literally have to be there.
DHCPv6 also lacks an authentication mechanism... in fact ICMPv6 has RA guard
Neither does ICMPv6 RA. And RA Guard is a layer-2 hack to block the packets -- i.e. must be supported by your switches, unmanaged switches (99.999999999% of home hardware) by definition cannot implement it, older switches never will.
(For the record, IPv4 had the same thing: ICMP Router Advertisement. It was abandoned before most of us were even aware of "IP", as a colossally bad idea. A completely non-authenticatable system of broadcasting "hey! I'm a router, give me all your traffic"; the networking equiv of the Free Candy Van. Why not do away with routers entirely and go back to proxy-arp!)
It's not so much the client OSes that are the problem (they are, but a smaller one.) The real issue is updating the routing hardware with modern compliant software. For the home user, that's a real issue because they know nothing about any of this networking IPvWhatever crap, or their ISP or vendor hasn't or isn't making any updates. In the enterprise, they turned to DHCPv6 years ago and don't give a single shit about the further convolutions of the protocol -- too little, too late. ("What? We have to throw away $mil in hardware to upgrade to IOS 16.5XT to get $New-Knob-X that Windows 11 requires?!? Screw that mess." Also, that's big (read: F'ing HUGE) reason why IPv6 adoption has been so glacial. It's a never-finished protocol that's poorly suited to the way we actually use networks. I have gear that's nearly 30 years old, and it still works perfectly fine with modern IPv4 (TCP) systems -- 30yo network stack, but windows 10 can telnet to it just fine. An IPv6 stack from just a decade ago doesn't fair so well; an original '90s stack won't work at all.)
DHCPv6 was "bolted on" 12+ years ago. It is an IETF STANDARD part of IPv6. Implementation is not "optional". Google simply refused to add it because they're butt-hurt that it *could* make certain features non-operational -- or more accurately, they don't want to do any of the work to make them possible. I can make XP and 2000 work properly within a stateful DHCPv6 only network (using a 3rd party dhcp client, because their ipv6 stacks are far too old), and other android devs HAVE added DHCPv6 support to their builds -- so we know, for a fact, it can be done, and rather trivially to boot.
The O flag (it's a single bit) simply tells the device it should search for OTHER informational elements from (wait for it...) A DHCPv6 SERVER. That is the "stateless" mode, which android ALSO doesn't support.
I suppose you are referring to the relatively recent (and not widely supported) RDNSS fields of the RA -- which do list DNS servers.
... except in a managed network (where something needs to keep track of what is what, and when.) Or in an IPv6 ONLY network. As I've bitched for years, a machine needs more than just an address to operate. At minimum, it needs a list of recursive DNS servers -- something that has now been bolted onto the still-a-bad-idea RA, if supported by your hardware (which is unlikely.)
You miss the entire point: on a managed IPv6 ONLY network, android devices have ZERO connectivity. As much as *you* don't want to setup such a network, there are PLENTY of others that HAVE. And the standard dictates that it be supported. Plus, it doesn't have to be a one-device-one-address-only system. If you need more than one address, ask for more than one. If you want to tether a network behind you, ask for an additional prefix, or bridge them into the same network and let them RA/DHCP for themselves. If you cannot get the additional space, you cannot support whatever feature required it. That's a very different experience than "no fucking connection?!? WTF!!!" (which is exactly where this is headed, and the network operator answer (per NANOG) is that your device is crap, you should complain to the idiots at Google -- one in particular, actually.)
Comcast uses DHCPv6-PD; you can get more than a single::/64. An RA can announce any sized network. Only the brain damage that is SLAAC that REQUIRES the prefix length to be 64.
Really? You have to tell your DHCP server the MAC of every device on your network?
Unless you're using static assignments ("reservations"), then you don't need to tell the server anything at all. The "MAC" of the device can change, btw. (different NIC, wireless vs. wired, etc.) And a MAC isn't the only thing the server can use. (in fact, I'm cursing Sun for the ALOM using the serial number instead of MAC for it's client-id.)
It didn't originally -- because the committee HATED DHCP (bootp). But it was added to the standard some years later. Google has flat refused to implement that part of the standard for many years now.
I am 99% CERTAIN this is all marketing driven bullshit. Engineers know better -- or at least those that aren't 20-something idiots that want everything to be facebook. (I'd blame that on lame marketing direction, too, but I know it's not. Google's push for young, hip, trend setters means they have a very shallow talent pool that has zero understanding of how to maintain a product brand and identity.)
It's not a matter of "it cannot be changed". They have no intention of undoing what they've done. If I were a judge and this were brought before me... "Put it back. Fine: $25,000 PER MINUTE that it is not restored."
The $2mil is replacing all that ancient crap, not just what the amiga has been maintaining for decades. I don't want to think what's controlling this place. (it's 30 years old, and the plenum confirms that!)
Actually, it is, however, I would call it a "byproduct of NAT". The traffic is dropped because there's no map to tell the NAT engine how to deal with it. A firewall does much more than simply track connections. (it pays attention to fragments, sequence numbers, etc.)
But it's far better than v4 NAT and it doesn't break the net the same way.
Nope. It's broken in exactly the same way: what I think my address is isn't what you see me as. If I tell you to connect back to me at (A), but beyond some point my address is actually (B), then the connection will not happen. v4 NAT has a HUGE number of "protocol helpers" that rewrite addresses within known protocols (SIP, FTP, etc.) to match the "new reality" beyond that point. IPv6 was designed from day-one to not have ANY tampering with packets in flight. (options can be added or removed, and TTL decremented, but any mucking with the payload is a no-no.)
Sellers, sure. Buyers, however, are very much hidden from public view. But yes, eBay does have data to hand over to a court that would help identify a specific person.
Slashdot Mirror
You'd be surprised just how hard it is to evict someone from a residential property.
(Commercial property, at least around here, 30 days and we can sell off or discard anything you left behind. And keep your deposit.)
On the other hand, if they cannot get credit, they really cannot afford to buy that house. They might be able to make the payments, otherwise, but lenders are a lot more risk averse -- and for damn good reason. Rents then naturally rise to the levels of a mortgage and *bam* the people who couldn't get financing also cannot stockpile cash to improve their ability to secure financing.
And yet, I see all the "for rent" and "space available" signs around town listing rents at basically the same rates I paid a decade ago.
RFC2131, Section 4.4.1
The client MUST include its hardware address in the 'chaddr' field, if necessary for delivery of DHCP reply messages.
The word used is SHOULD. There are still plenty of DHCP systems that request (require) a broadcast reply. Go listen to the broadcast traffic on your cablemodem.
And I'm FAR TOO well aware of systems using the wrong hardware address in their requests -- more than one nic, and it uses the MAC from the first nic in all queries no matter which nic it's asking about or using. (and this is from an ISC DHCP client!)
TL;DR chaddr [Client Hardware ADDRess] is 16 bytes of whatever the client puts there.
(Replies in my network are broadcast so the boot agent can see them.)
Stock android has no means to handle DHCPv6. It's not there. At all. You can (maybe) root your device and (maybe) add it yourself. But that's beyond 99% of android users. ("root, run custom rom downloaded from internet" - lots of people do that.)
You can call it BS all you want, but there are environments where legal accountability is a requirement. Could you side-step their tracking voodoo? Probably, but that's even more tinkering with your android device.
Using the MAC as an ID is a flawed method. Devices come and go, MACs change (because the NIC changed, etc.) Ultimately -- and here's the end of it -- you'd have to be maintaining a registry of every device's MAC within your network to know what's what, where, and who's using it. Just gleaning a "list of mac's" is simple enough, albeit a tedious pain in the ass: arp tables, cam tables, watching broadcast traffic, etc. Knowing the location of each device gets a lot more tricky; sure wired devices will be tethered somewhere off a switch port, but that's not always enough. Wireless devices, on the other hand, can be anywhere. And none of that addresses who's device it is, who's using it, and exactly what it is. (OUI's only go so far, and assume no one is forging their MAC.)
When someone carries a device into the office, does something questionable with it, and then leaves, tracking the who/what/where/when becomes much harder. When the questionable act isn't mentioned for weeks or months, it can become impossible.
Case in point, I had to trace down a "hacker box" in the network. It was a lot easier because it was ON and ACTIVE at the time. Looking through cam tables, I could only go so far as an unmanaged hub. (yes, this company still used far too many hubs. even in 2003.) Careful inspection of the hub (and unplugging one port at a time), localized it to a desk. An unoccupied cubical, in fact. By the time I got to that desk, the machine had been turned off (it was still warm), the "warez" hard drive had been removed (windows registry remembers it), and the non-company 3com nic had been removed (again, registry -- which is how I knew 100% that's the machine I'm looking for.) That was the company computer for that desk, which is the only reason it was still there. Had he used one of his own machines, it could've simply disappeared without a trace. Moral of the story: I had a MAC, and it didn't tell me shit. The "who" was only discovered because his coworkers ratted him out :-) ("Who's been using X's computer?" They didn't know he was doing anything stupid with it.) And that only worked because it was in real time; had it been brought up a month later (nothing to trace) (and there not been a hub muddying the picture), any history logs would simply have ended with "I don't know. It was something at X's desk" [X having left the company many months ago. X's computer official off since it's builtin NIC, registered in company inventory, wasn't being used.]
One does not pre-program the DHCP server with a list of MACs, nor does every client identify itself by MAC -- the client-id can be many things, MAC being but one of them.
*sigh* No it doesn't. A unicast reply needs a destination MAC, either the end client or a relay agent. A broadcast reply, however, DOES. NOT.
*sigh* Those devices ARE BROKEN! And the entire networking world knows it. SLAAC still requires ::/64, as far as I'm aware. However, privacy extensions no longer mandate this brain damage.
Hundreds of people have warned, just as I have, that people can be (and WILL be) stupid, and thus make these blanket assumptions.
No. No sane person assumes the size of a non-local network. A lot of the world does, in fact, bow to the stupid that is SLAAC, but it's not "everywhere", nor do hardware vendors worth their salt make any such assumptions or impose restrictions -- your network can be any size you wish. Your ISP is likely to assign you a ::/64 (60, or 56) because it's the lowest common denominator. (and because they tend to use cheap trash for CPEs.) Giving you anything smaller, while technically feasible, creates hurdles for people with little to no networking expertise.
And if you have android devices, it's the only way to get the damned things on your IPv6 network.
Please stop with this 64+64 BULLSHIT. There is no "host part" and "network part" in IPv6. (there isn't, anymore, in IPv4 either.) IPv6 is 100% CLASSLESS. The only thing that (currently) demands the 64/64 split is SLAAC -- BTW, it started at 80/48 -- and a network is not REQUIRED to run SLAAC. (which is the heart of the entire roasting of Google here.)
You CANNOT make such an assumption about a non-local network. You MUST know the prefix-length to know what part is "network" and which is "host". You can look up the entire 128bit address to find the assigned block (a ::/48 or ::/32 most likely), but beyond there, you rather literally have to be there.
Neither does ICMPv6 RA. And RA Guard is a layer-2 hack to block the packets -- i.e. must be supported by your switches, unmanaged switches (99.999999999% of home hardware) by definition cannot implement it, older switches never will.
(For the record, IPv4 had the same thing: ICMP Router Advertisement. It was abandoned before most of us were even aware of "IP", as a colossally bad idea. A completely non-authenticatable system of broadcasting "hey! I'm a router, give me all your traffic"; the networking equiv of the Free Candy Van. Why not do away with routers entirely and go back to proxy-arp!)
It's not so much the client OSes that are the problem (they are, but a smaller one.) The real issue is updating the routing hardware with modern compliant software. For the home user, that's a real issue because they know nothing about any of this networking IPvWhatever crap, or their ISP or vendor hasn't or isn't making any updates. In the enterprise, they turned to DHCPv6 years ago and don't give a single shit about the further convolutions of the protocol -- too little, too late. ("What? We have to throw away $mil in hardware to upgrade to IOS 16.5XT to get $New-Knob-X that Windows 11 requires?!? Screw that mess." Also, that's big (read: F'ing HUGE) reason why IPv6 adoption has been so glacial. It's a never-finished protocol that's poorly suited to the way we actually use networks. I have gear that's nearly 30 years old, and it still works perfectly fine with modern IPv4 (TCP) systems -- 30yo network stack, but windows 10 can telnet to it just fine. An IPv6 stack from just a decade ago doesn't fair so well; an original '90s stack won't work at all.)
DHCPv6 was "bolted on" 12+ years ago. It is an IETF STANDARD part of IPv6. Implementation is not "optional". Google simply refused to add it because they're butt-hurt that it *could* make certain features non-operational -- or more accurately, they don't want to do any of the work to make them possible. I can make XP and 2000 work properly within a stateful DHCPv6 only network (using a 3rd party dhcp client, because their ipv6 stacks are far too old), and other android devs HAVE added DHCPv6 support to their builds -- so we know, for a fact, it can be done, and rather trivially to boot.
The O flag (it's a single bit) simply tells the device it should search for OTHER informational elements from (wait for it...) A DHCPv6 SERVER. That is the "stateless" mode, which android ALSO doesn't support.
I suppose you are referring to the relatively recent (and not widely supported) RDNSS fields of the RA -- which do list DNS servers.
... except in a managed network (where something needs to keep track of what is what, and when.) Or in an IPv6 ONLY network. As I've bitched for years, a machine needs more than just an address to operate. At minimum, it needs a list of recursive DNS servers -- something that has now been bolted onto the still-a-bad-idea RA, if supported by your hardware (which is unlikely.)
You miss the entire point: on a managed IPv6 ONLY network, android devices have ZERO connectivity. As much as *you* don't want to setup such a network, there are PLENTY of others that HAVE. And the standard dictates that it be supported. Plus, it doesn't have to be a one-device-one-address-only system. If you need more than one address, ask for more than one. If you want to tether a network behind you, ask for an additional prefix, or bridge them into the same network and let them RA/DHCP for themselves. If you cannot get the additional space, you cannot support whatever feature required it. That's a very different experience than "no fucking connection?!? WTF!!!" (which is exactly where this is headed, and the network operator answer (per NANOG) is that your device is crap, you should complain to the idiots at Google -- one in particular, actually.)
Or stateless DHCPv6. Or in other words: they don't support DHCPv6 AT ALL.
Comcast uses DHCPv6-PD; you can get more than a single ::/64. An RA can announce any sized network. Only the brain damage that is SLAAC that REQUIRES the prefix length to be 64.
Really? You have to tell your DHCP server the MAC of every device on your network?
Unless you're using static assignments ("reservations"), then you don't need to tell the server anything at all. The "MAC" of the device can change, btw. (different NIC, wireless vs. wired, etc.) And a MAC isn't the only thing the server can use. (in fact, I'm cursing Sun for the ALOM using the serial number instead of MAC for it's client-id.)
It didn't originally -- because the committee HATED DHCP (bootp). But it was added to the standard some years later. Google has flat refused to implement that part of the standard for many years now.
I am 99% CERTAIN this is all marketing driven bullshit. Engineers know better -- or at least those that aren't 20-something idiots that want everything to be facebook. (I'd blame that on lame marketing direction, too, but I know it's not. Google's push for young, hip, trend setters means they have a very shallow talent pool that has zero understanding of how to maintain a product brand and identity.)
It's not a matter of "it cannot be changed". They have no intention of undoing what they've done. If I were a judge and this were brought before me... "Put it back. Fine: $25,000 PER MINUTE that it is not restored."
TL;DR... the HVAC systems are ancient.
The $2mil is replacing all that ancient crap, not just what the amiga has been maintaining for decades. I don't want to think what's controlling this place. (it's 30 years old, and the plenum confirms that!)
Have you met any modern highschool students? Most couldn't program their way out of "Hello World". And those who would attempt it want to use Java.
Actually, it is, however, I would call it a "byproduct of NAT". The traffic is dropped because there's no map to tell the NAT engine how to deal with it. A firewall does much more than simply track connections. (it pays attention to fragments, sequence numbers, etc.)
Nope. It's broken in exactly the same way: what I think my address is isn't what you see me as. If I tell you to connect back to me at (A), but beyond some point my address is actually (B), then the connection will not happen. v4 NAT has a HUGE number of "protocol helpers" that rewrite addresses within known protocols (SIP, FTP, etc.) to match the "new reality" beyond that point. IPv6 was designed from day-one to not have ANY tampering with packets in flight. (options can be added or removed, and TTL decremented, but any mucking with the payload is a no-no.)
Sellers, sure. Buyers, however, are very much hidden from public view. But yes, eBay does have data to hand over to a court that would help identify a specific person.
Of course, one must also get it safely to the surface of Mars.
Does no one remember Earth 2?