::ffff:<a.b.c.d.>, eg ::ffff:192.0.2.42, but that is mostly (or entirely?) deprecated. The IPv4 mapped addresses give a range of nice security problems where people forget to close down their IPv6 firewall for this and thus allow IPv4 addresses into the IPv6 world and there where some other reasons.
Huh? A badly run firewall is a badly run firewall. 6-to-4 mapping doesn't really change this. So, I don't buy that reason. However, if it's deprecated, then, I guess it's deprecated so no need to go into the other reasons.
2002:<AB>:<CD>::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4, quite in use and works fine when the 6to4 relays are close-by for both ends.
OK... Seems a bit messier, and more wasteful of address space, but, if we want to blow away 4 billion /48s to accomodate v4 connectivity, it's not like we'll miss them.
Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then you thus also have 2002:c000:22a::/48 or larger of course, depending on your IPv4 space, though a /48 should be enough for most folks.
Actually, I think that would be 2002:c000:0200::, but, that's not a /48, it's a /40 (2002:c000:0200:: to 2002:c000:02ff::). One of us must be confused.
Tada, because you have one single IPv4 address, that is most likely already PI in IPv4, you also have a IPv6 prefix that is PI.
Agreed... That's pretty much what I've been saying (sort of).
Now can everybody stop complaining that the installed IPv4 base already has PI and needs it too for IPv6, use above solution and get it over with. Also if you are multihomed by multiple IPv4 prefixes you can do that with the above too, just RA multiple prefixes on your network.
I'm perfectly willing to live with that, but, a bunch of people are saying that that's "Not deployment of v6", "an ugly hack", and, "we don't want to keep that alive any longer than we have to." As such, there needs to be some other solution. Also, eventually, there will need to be a solution for organizations that don't have and can't get v4 space but still have the same requirements and meet the same criteria as orgs that can get v4 space today.
There is one catch-22 though, according to RFC3056 Section 2.2: 8<------------------- On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. ------------------->8 Because it would introduce a lot of IPv4 routes into the IPv6 routing tables...
Then that isn't really a solution.
As at the moment most ISP's don't filter >/48 this should not be much of a problem. And folks, don't forget to setup your _own_ 6to4 relay otherwise your connectivity will be terrible.
So I don't understand how this ends up actually working. How does the rest of the world know which 6to4 relay to send which IPv4 prefixes to? Owen -- If it wasn't crypto-signed, it probably didn't come from me.