There's a difference between IPv6-ready and IPv6-only. Those 20-year-old printers that only work on v4 will continue to work on the v4 part of the dual-stacked internal network; replacing them isn't a requirement for deploying v6. (It is a requirement for removing v4, but that's the long-term goal, not the immediate one.)
I'll describe the v4 scenario first, and then map it into v6. I'll use a typical cable ISP setup as the example.
When you plug your router into the modem and do DHCP, you'll get an IP on its upstream port, let's say 44.230.129.42/22. This means you have a single IP (44.230.127.42) taken out of the transfer net (44.230.128.0/22 -- i.e. 44.230.128.0 to 44.230.131.255). You share this transfer net with about a thousand other customers of the ISP. Your ISP only lets you use one IP from this range, because it doesn't have enough to let you use more.
On your router's LAN-facing interface, you then assign 192.168.1.1/24 -- i.e. it uses the IP 192.168.1.1, and the subnet for your LAN is 192.168.1.0/24 (= 192.168.1.0 to 192.168.1.255). Your router routes between these two subnets. (Because 192.168.x.x is a private range, you have to do NAT to hide it from your ISP, or your return packets will never make it back to you.)
The key point here is that there are (and must be) two separate network ranges involved -- 44.230.128.0/22 and 192.168.1.0/24. There has to be two separate network ranges because there's two separate networks involved. (It has nothing to do with the fact that the ISP will only let you use one IP from 44.230.128.0/22.)
Now, moving into v6. v6 needs the same setup: one subnet between your ISP and your router, and one subnet for your local LAN. However, because there's no NAT, the subnet has to come from your ISP.
So, for instance, the ISP might use 2001:558:db8:128::/64 for the transfer net, and give you 2601:b:42:0::/64 for your LAN. When you connect your router to your modem, the router would get an IP like 2001:558:db8:128::42 on the transfer net's/64. The local range, 2601:b:42:0::/64, would then be routed to 2001:558:db8:128::42 (i.e. the ISP router would be configured to say "Any packets destined to an IP in 2601:b:42:0::/64? Send them over to 2001:558:db8:128::42. He'll know what to do with them.") You'll put 2601:b:42:0::1/64 on the LAN-facing interface of your router, and there you go: we've replicated the v4 situation in v6, but now with no NAT.
Now, you'll note that 2001:558:db8:128::/64 is really big, and it has enough IPs to number all of your devices. Heck, it has enough IPs to number every device on the internet. But it's in the wrong place for devices on your home network -- it's on the network between your router and your ISP. The devices on your home network can't use IPs from the transfer network, because they're not on the transfer network.
The great-grandparent post was complaining that he didn't have the second subnet, the one from 2601:b::. His router had an IP on the transfer net, sure, and he might even be allowed to use lots of IPs from the transfer net... but all of those IPs were for use on the transfer net itself, not behind his router on his home LAN.
OK I have a ISP whose given me a/64 and one v4 address
When you say "given me a/64" here, you're thinking of the second subnet, the one from 2601:b::. You can put that on your LAN just fine, but the packets for that that subnet need to be transported to your router somehow, and that's done over the transfer net. (The caveat, which I mentioned in my last post, is that this only applies to uplink networks that are Ethernet-like. If your uplink is an actual PtP link, like the PPP which DSL usually uses, then a transfer net isn't necessary.)
(This post duplicates much of the explanation from the sibling thread -- sorry about that, but I couldn't bear to throw it away after writing all this;) )
The unique part about his equipment is that it's actually working like it's supposed to. The all-zeros address is the subnet-router anycast address, and if you attempt to talk to it, you should receive a reply from one of the routers on the subnet.
Linux implements this. If forwarding is enabled for an interface, then it will respond to traffic to the all-zeros address on any subnets on that interface.
(I'm not quite sure what happens for internal traffic if you have multiple routers on a single subnet. Maybe you'll end up sending packets to whichever one responds to NDP first? It's not an issue for traffic from outside the subnet, since that will just naturally hit one of the routers, which will handle the response.)
He's talking about a transfer net. The home LAN doesn't get the/64 because the/64 is on the transfer net between the router and the ISP, and it can't magically go through the router to the LAN. You need a separate/64 (or larger) for the LAN side.
In order to use the addresses on the transfer network, you'd have to connect all of your devices up to your modem using a switch. But that's incompatible with v4, because your ISP will only give you one v4 address, so all of those extra devices would be v6-only.
The caveat is that a transfer net is only necessary if your upstream isn't marked NOARP (i.e. if it's Ethernet), which is typical of cable ISPs. If your upstream is a true point-to-point link, such as a PPP tunnel, then you don't need the transfer net at all. There are only two nodes on a PtP link, so there's no need to use IPs to identify which node you want to send traffic to: you just shove it down the link and it shows up at the other end. Most DSL ISPs can thus get away without using a transfer net.
And yes, there are uses for more than one/64 on a home LAN. Segregated wired/wireless is a common one, particularly with guest wifi networks (which typically use a separate subnet). Another is any situation where people cascade routers and end up with double NAT at the moment -- in v6 land, you handle that with DHCPv6-PD, which allows the second router to request a routed subnet from the first.
The use of "backflips" suggests they've done something wrong. Yet the summary seems to say that there were complaints about the application process, and that ICANN has responded to those complaints by improving the process -- or at least altering it so as to remove the parts that were being complained about. In fact it doesn't even have anything negative to say about the news itself, other than the headline.
They actually listened to criticism and removed the cause of it. What more do people want of them?
(Other than coming to their senses and aborting the whole thing, of course.)
There's nothing to automatically tunnel v4 on top of v6. You're expected to do v4 beside v6, using all the existing mechanisms to automatically deploy v4 -- they already work quite well, after all.
If you really do only get IPv6 from your ISP, then you can't make v4 connections to the internet. That's not very useful, so you're not going to see IPv6-only ISPs any time soon. (You can still use v4 privately on your own LAN though, and e.g. Hamachi will work as well as it ever does, so long as you can connect to the Hamachi servers over v6.) ISPs will use NAT to continue giving people v4 addresses for quite a while yet, and presumably charge extra to people who want a proper non-NATed IP for inbound connections.
(There is a semi-exception in the form of NAT64, which maps the IPv4 space into a/96 in v6. In principle you could then NAT46 back again on your local router, and you'd have v4 access with the link between you and your ISP being v6-only. I don't think we'll be seeing much of that from home ISPs though, because it's easier to just do dual stack.)
Do finish the sentence. I guess you wanted to say ", there aren't.", which also implies that they're not behind NAT either.
And if they're not behind NAT in the first place, then the whole original argument of "IPv6 will be less secure than IPv4 because your stuff won't be behind NAT" doesn't even apply, does it?
And if you're thinking of putting them behind NAT "for the security" -- just put them behind a firewall instead. The hardware and software required to do so is the same, and the configuration is very similar. (With a firewall, you also have the option of implementing it on the device itself rather than needing a separate device, although as my sibling poster points out it's kinda rare for embedded hardware to have such support.)
If I have a ipv6 address how do I guarantee all my "old" ipv4 games work ?
Simple: you use IPv4. You don't "switch" your network to IPv6, you use IPv6 on it at the same time as IPv4. Your existing v4 stuff continues to work as well as it would have done if you didn't have v6 too. (This is the usual way of doing v6 deployments, called "dual-stack".)
This is basically the situation we have today with old IPX games, just we're at the beginning of the transition rather than at the end.
I was expecting Slashdot users, of all people, to at least have heard of firewalls... but alas, once again I see how naive my expectations are.
Just to head off the other common complaint, I'd like to mention another recent invention called DNS, which allows people to use textual strings as aliases to IP addresses, saving them from needing to remember the latter all the time.
There's more to it than the ratio between min and max values over a period of months.
The exchange rate only needs to stay steady for as long as it takes for someone to exchange dollars into BTC, send them to the person they're buying something from, and for that person to exchange the BTC back into dollars, which takes about a few hours or so.
Looking at the past few months of data, the biggest 6-hourly increase was about 10% on the 15th of June. A seller could easily hedge against that by charging 10% extra for Bitcoin users. If the exchange rate drops 10%, then the seller gets what they would have got originally. If, as it did on the 15th, the exchange rate raises by 10%, the seller gets 20% on top of the sale price in pure profit. To me, that seems like a pretty damn good deal for the seller.
Personally, I feel that a 10% Bitcoin fee on every transaction would be too much for me to use Bitcoin. However, looking at the last few months of exchange rate, changes of 10% have been rare, so you wouldn't need to charge 10% on every transaction. You could charge 5%, say, and put the profit toward covering the (rarer) bigger drops. You'd have to do some analysis to figure out how little you could charge while still making a profit, but I suspect that you could get it below the percentage fees charged by credit card companies, meaning you could actually give people a discount for using Bitcoin instead of a credit card.
If you can pull that off, then yes. I would call that stable.
Except we managed to slip stack upgrades into the vast majority of Windows, Linux, OSX and BSD installs out there without any hassle. That's clearly not the bit that needs to be easier.
The bit we're stuck on is actually configuring networks to use the new protocol. This is something that your "let's just increase the number of bits in v4" approach won't help with at all, because you'd still have to do the configure step, and that would have involved the same amount of effort as with v6.
But then we're just back to the IPv4 situation, with them only being able to distinguish between networks rather than individual machines. At that point, the original complaint of "they'll be able to distinguish between individual machines" starts looking rather silly.
The first part isn't really almost fixed to 2001 -- the actual RIR allocations are listed here. The RIRs have/12 blocks assigned to them, with space to expand that to a/7. They also have older/23 blocks allocated out of 2001::/16. The first part might look like it's fixed to one of a few values, but that's because the address space is big enough that the RIRs haven't needed to use those bits yet. They'll use them when they need to.
Likewise, the minimum ISP allocation is/32, but each/32 is actually taken from a/29 reservation that the ISP can grow into. ISPs that are already large get bigger allocations -- mine has a/24, with a/21 to grow into. Allocation isn't done strictly on word boundaries.
It's perfectly fine for sufficiently large companies to get allocations in the/32 range. We have a billion/32s available. That's only one per seven people, sure, but we've just said we're talking about very large companies -- they have a lot more than seven employees each. (Of course the allocation should reflect the size of the company's network; if they're too big for a/48 but too small for a/32 then they should get something inbetween. I've seen/40 and/44 allocations to universities, for instance.)
Even taking the HD-ratio into account doesn't change things that much. If you use a HD-ratio of 0.8 (which is fairly low; IPv4 was around that number in 1998-99 or so) my "5000/person" figure from before becomes something more like 10-20/48s per person. This is a number a person can realistically manage to hit, but I still don't see everybody on the planet managing that.
Finally, we have five more unused/3s that we can do this all over again in. We could even change the allocation strategy in those/3s, if we discover that our current strategy is bad. I don't think we'll fill 2000::/3, but there's an escape plan available if we do. We could have done it using your split, but we didn't, and from the numbers I don't believe the split we did decide on is going to be problematic.
I agree that 2^64 hosts is a bit more than you can sanely fit on a subnet. I am not convinced that moving the boundaries over so that/48 and/64 become/64 and/80 (or/96) would have been useful though.
My justification for this is that there are 5000/48s available per person on the planet, where each/48 is enough for an entire network. How many people do you know who manage 5000 administratively-separate networks? That would need to be everyone for the current use of/48 to be a problem.
And even if that does happen, that's only out of 2000::/3. We still have five more/3 blocks available, so we can do it all over again if we really need to.
(I take it you meant characters or nibbles in your first paragraph; a full v6 address is 128 bits = 16 bytes.)
Until they discover that Windows has privacy addresses turned on by default, which basically means that their address-based cookies are cleared every day.
IPv6 is just annoying! What's the deal anyway with 2^64 devices on your personal network? This is way over-specified.
Having more addresses than you need is annoying? I'd have thought having too few (i.e. the current situation in v4) would be the more annoying situation.
He specifically mentioned IPv6 though, and in IPv6 the address space is so massive that you can (and do) hop IPs regularly -- rather than hiding behind a single address, you instead use new ones constantly. There's no way to tie the IP to the computer, because by the time the **AA come knocking with the IP they logged, the computer has long since forgotten it.
Slashdot Mirror
It's an AGPLed, federated social network/protocol, kinda like a cross between Facebook and e-mail or XMPP.
There's a difference between IPv6-ready and IPv6-only. Those 20-year-old printers that only work on v4 will continue to work on the v4 part of the dual-stacked internal network; replacing them isn't a requirement for deploying v6. (It is a requirement for removing v4, but that's the long-term goal, not the immediate one.)
It's not like a couple of /8s will make much difference either. One /8 lasts for about a month or so.
Giving back IP space is a waste of effort. Exert that effort towards your IPv6 migration instead.
I'll describe the v4 scenario first, and then map it into v6. I'll use a typical cable ISP setup as the example.
When you plug your router into the modem and do DHCP, you'll get an IP on its upstream port, let's say 44.230.129.42/22. This means you have a single IP (44.230.127.42) taken out of the transfer net (44.230.128.0/22 -- i.e. 44.230.128.0 to 44.230.131.255). You share this transfer net with about a thousand other customers of the ISP. Your ISP only lets you use one IP from this range, because it doesn't have enough to let you use more.
On your router's LAN-facing interface, you then assign 192.168.1.1/24 -- i.e. it uses the IP 192.168.1.1, and the subnet for your LAN is 192.168.1.0/24 (= 192.168.1.0 to 192.168.1.255). Your router routes between these two subnets. (Because 192.168.x.x is a private range, you have to do NAT to hide it from your ISP, or your return packets will never make it back to you.)
The key point here is that there are (and must be) two separate network ranges involved -- 44.230.128.0/22 and 192.168.1.0/24. There has to be two separate network ranges because there's two separate networks involved. (It has nothing to do with the fact that the ISP will only let you use one IP from 44.230.128.0/22.)
Now, moving into v6. v6 needs the same setup: one subnet between your ISP and your router, and one subnet for your local LAN. However, because there's no NAT, the subnet has to come from your ISP.
So, for instance, the ISP might use 2001:558:db8:128::/64 for the transfer net, and give you 2601:b:42:0::/64 for your LAN. When you connect your router to your modem, the router would get an IP like 2001:558:db8:128::42 on the transfer net's /64. The local range, 2601:b:42:0::/64, would then be routed to 2001:558:db8:128::42 (i.e. the ISP router would be configured to say "Any packets destined to an IP in 2601:b:42:0::/64? Send them over to 2001:558:db8:128::42. He'll know what to do with them.") You'll put 2601:b:42:0::1/64 on the LAN-facing interface of your router, and there you go: we've replicated the v4 situation in v6, but now with no NAT.
Now, you'll note that 2001:558:db8:128::/64 is really big, and it has enough IPs to number all of your devices. Heck, it has enough IPs to number every device on the internet. But it's in the wrong place for devices on your home network -- it's on the network between your router and your ISP. The devices on your home network can't use IPs from the transfer network, because they're not on the transfer network.
The great-grandparent post was complaining that he didn't have the second subnet, the one from 2601:b::. His router had an IP on the transfer net, sure, and he might even be allowed to use lots of IPs from the transfer net... but all of those IPs were for use on the transfer net itself, not behind his router on his home LAN.
When you say "given me a /64" here, you're thinking of the second subnet, the one from 2601:b::. You can put that on your LAN just fine, but the packets for that that subnet need to be transported to your router somehow, and that's done over the transfer net. (The caveat, which I mentioned in my last post, is that this only applies to uplink networks that are Ethernet-like. If your uplink is an actual PtP link, like the PPP which DSL usually uses, then a transfer net isn't necessary.)
(This post duplicates much of the explanation from the sibling thread -- sorry about that, but I couldn't bear to throw it away after writing all this ;) )
The unique part about his equipment is that it's actually working like it's supposed to. The all-zeros address is the subnet-router anycast address, and if you attempt to talk to it, you should receive a reply from one of the routers on the subnet.
Linux implements this. If forwarding is enabled for an interface, then it will respond to traffic to the all-zeros address on any subnets on that interface.
(I'm not quite sure what happens for internal traffic if you have multiple routers on a single subnet. Maybe you'll end up sending packets to whichever one responds to NDP first? It's not an issue for traffic from outside the subnet, since that will just naturally hit one of the routers, which will handle the response.)
He's talking about a transfer net. The home LAN doesn't get the /64 because the /64 is on the transfer net between the router and the ISP, and it can't magically go through the router to the LAN. You need a separate /64 (or larger) for the LAN side.
In order to use the addresses on the transfer network, you'd have to connect all of your devices up to your modem using a switch. But that's incompatible with v4, because your ISP will only give you one v4 address, so all of those extra devices would be v6-only.
The caveat is that a transfer net is only necessary if your upstream isn't marked NOARP (i.e. if it's Ethernet), which is typical of cable ISPs. If your upstream is a true point-to-point link, such as a PPP tunnel, then you don't need the transfer net at all. There are only two nodes on a PtP link, so there's no need to use IPs to identify which node you want to send traffic to: you just shove it down the link and it shows up at the other end. Most DSL ISPs can thus get away without using a transfer net.
And yes, there are uses for more than one /64 on a home LAN. Segregated wired/wireless is a common one, particularly with guest wifi networks (which typically use a separate subnet). Another is any situation where people cascade routers and end up with double NAT at the moment -- in v6 land, you handle that with DHCPv6-PD, which allows the second router to request a routed subnet from the first.
Clearly the proprietary driver is much better then, since it allows me to do whatever I like with your computer.
The use of "backflips" suggests they've done something wrong. Yet the summary seems to say that there were complaints about the application process, and that ICANN has responded to those complaints by improving the process -- or at least altering it so as to remove the parts that were being complained about. In fact it doesn't even have anything negative to say about the news itself, other than the headline.
They actually listened to criticism and removed the cause of it. What more do people want of them?
(Other than coming to their senses and aborting the whole thing, of course.)
There's nothing to automatically tunnel v4 on top of v6. You're expected to do v4 beside v6, using all the existing mechanisms to automatically deploy v4 -- they already work quite well, after all.
If you really do only get IPv6 from your ISP, then you can't make v4 connections to the internet. That's not very useful, so you're not going to see IPv6-only ISPs any time soon. (You can still use v4 privately on your own LAN though, and e.g. Hamachi will work as well as it ever does, so long as you can connect to the Hamachi servers over v6.) ISPs will use NAT to continue giving people v4 addresses for quite a while yet, and presumably charge extra to people who want a proper non-NATed IP for inbound connections.
(There is a semi-exception in the form of NAT64, which maps the IPv4 space into a /96 in v6. In principle you could then NAT46 back again on your local router, and you'd have v4 access with the link between you and your ISP being v6-only. I don't think we'll be seeing much of that from home ISPs though, because it's easier to just do dual stack.)
Do finish the sentence. I guess you wanted to say ", there aren't.", which also implies that they're not behind NAT either.
And if they're not behind NAT in the first place, then the whole original argument of "IPv6 will be less secure than IPv4 because your stuff won't be behind NAT" doesn't even apply, does it?
And if you're thinking of putting them behind NAT "for the security" -- just put them behind a firewall instead. The hardware and software required to do so is the same, and the configuration is very similar. (With a firewall, you also have the option of implementing it on the device itself rather than needing a separate device, although as my sibling poster points out it's kinda rare for embedded hardware to have such support.)
If I have a ipv6 address how do I guarantee all my "old" ipv4 games work ?
Simple: you use IPv4. You don't "switch" your network to IPv6, you use IPv6 on it at the same time as IPv4. Your existing v4 stuff continues to work as well as it would have done if you didn't have v6 too. (This is the usual way of doing v6 deployments, called "dual-stack".)
This is basically the situation we have today with old IPX games, just we're at the beginning of the transition rather than at the end.
I was expecting Slashdot users, of all people, to at least have heard of firewalls... but alas, once again I see how naive my expectations are.
Just to head off the other common complaint, I'd like to mention another recent invention called DNS, which allows people to use textual strings as aliases to IP addresses, saving them from needing to remember the latter all the time.
There's more to it than the ratio between min and max values over a period of months.
The exchange rate only needs to stay steady for as long as it takes for someone to exchange dollars into BTC, send them to the person they're buying something from, and for that person to exchange the BTC back into dollars, which takes about a few hours or so.
Looking at the past few months of data, the biggest 6-hourly increase was about 10% on the 15th of June. A seller could easily hedge against that by charging 10% extra for Bitcoin users. If the exchange rate drops 10%, then the seller gets what they would have got originally. If, as it did on the 15th, the exchange rate raises by 10%, the seller gets 20% on top of the sale price in pure profit. To me, that seems like a pretty damn good deal for the seller.
Personally, I feel that a 10% Bitcoin fee on every transaction would be too much for me to use Bitcoin. However, looking at the last few months of exchange rate, changes of 10% have been rare, so you wouldn't need to charge 10% on every transaction. You could charge 5%, say, and put the profit toward covering the (rarer) bigger drops. You'd have to do some analysis to figure out how little you could charge while still making a profit, but I suspect that you could get it below the percentage fees charged by credit card companies, meaning you could actually give people a discount for using Bitcoin instead of a credit card.
If you can pull that off, then yes. I would call that stable.
Except we managed to slip stack upgrades into the vast majority of Windows, Linux, OSX and BSD installs out there without any hassle. That's clearly not the bit that needs to be easier.
The bit we're stuck on is actually configuring networks to use the new protocol. This is something that your "let's just increase the number of bits in v4" approach won't help with at all, because you'd still have to do the configure step, and that would have involved the same amount of effort as with v6.
They will.
But then we're just back to the IPv4 situation, with them only being able to distinguish between networks rather than individual machines. At that point, the original complaint of "they'll be able to distinguish between individual machines" starts looking rather silly.
Privacy addresses?
I mentioned them to you when you last posted that. Do you not read the replies to your own posts?
Because whoever made the installer did it wrong. When presented with the GPL in an installer, the button should read "Next" or "Continue".
You do not need to accept the GPL just to use GPLed software.
But they should have made IPV6 backwards compatible
Could you explain how? Because I've seen so many people suggest this, and not one has explained how it would be done.
I believe the primary reason is because it's not possible, but maybe you'll be the person to correct me.
The first part isn't really almost fixed to 2001 -- the actual RIR allocations are listed here. The RIRs have /12 blocks assigned to them, with space to expand that to a /7. They also have older /23 blocks allocated out of 2001::/16. The first part might look like it's fixed to one of a few values, but that's because the address space is big enough that the RIRs haven't needed to use those bits yet. They'll use them when they need to.
Likewise, the minimum ISP allocation is /32, but each /32 is actually taken from a /29 reservation that the ISP can grow into. ISPs that are already large get bigger allocations -- mine has a /24, with a /21 to grow into. Allocation isn't done strictly on word boundaries.
It's perfectly fine for sufficiently large companies to get allocations in the /32 range. We have a billion /32s available. That's only one per seven people, sure, but we've just said we're talking about very large companies -- they have a lot more than seven employees each. (Of course the allocation should reflect the size of the company's network; if they're too big for a /48 but too small for a /32 then they should get something inbetween. I've seen /40 and /44 allocations to universities, for instance.)
Even taking the HD-ratio into account doesn't change things that much. If you use a HD-ratio of 0.8 (which is fairly low; IPv4 was around that number in 1998-99 or so) my "5000/person" figure from before becomes something more like 10-20 /48s per person. This is a number a person can realistically manage to hit, but I still don't see everybody on the planet managing that.
Finally, we have five more unused /3s that we can do this all over again in. We could even change the allocation strategy in those /3s, if we discover that our current strategy is bad. I don't think we'll fill 2000::/3, but there's an escape plan available if we do. We could have done it using your split, but we didn't, and from the numbers I don't believe the split we did decide on is going to be problematic.
I agree that 2^64 hosts is a bit more than you can sanely fit on a subnet. I am not convinced that moving the boundaries over so that /48 and /64 become /64 and /80 (or /96) would have been useful though.
My justification for this is that there are 5000 /48s available per person on the planet, where each /48 is enough for an entire network. How many people do you know who manage 5000 administratively-separate networks? That would need to be everyone for the current use of /48 to be a problem.
And even if that does happen, that's only out of 2000::/3. We still have five more /3 blocks available, so we can do it all over again if we really need to.
(I take it you meant characters or nibbles in your first paragraph; a full v6 address is 128 bits = 16 bytes.)
Yes, as I was saying, privacy addresses. What good does tracking the IP address do when they switch to a new IP every 24 hours?
Until they discover that Windows has privacy addresses turned on by default, which basically means that their address-based cookies are cleared every day.
IPv6 is just annoying! What's the deal anyway with 2^64 devices on your personal network? This is way over-specified.
Having more addresses than you need is annoying? I'd have thought having too few (i.e. the current situation in v4) would be the more annoying situation.
He specifically mentioned IPv6 though, and in IPv6 the address space is so massive that you can (and do) hop IPs regularly -- rather than hiding behind a single address, you instead use new ones constantly. There's no way to tie the IP to the computer, because by the time the **AA come knocking with the IP they logged, the computer has long since forgotten it.
How would IPv6 help?