On 20 Oct 2012, at 05:41, Mikael Abrahamsson
<swmike(_at_)swm(_dot_)pp(_dot_)se> wrote:
On Fri, 19 Oct 2012, Steve Atkins wrote:
(I'm betting that "mask the bottom 64 bits before querying" would work just
fine, but I don't think we have enough v6 space in use yet to say for sure.)
I agree. Although I believe some ISPs will put multiple customers in a single
/64, this is mostly going to be dynamic customers anyway (multiple laptops on
a wifi for instance), and those I would imagine are treated with the same
policy so it doesn't really matter. Per /64 handling is a reasonable tradeoff
between granularity and practicality in my mind.
A /64 basis seems to be the most sensible starting point, from which one could
'suck it and see'.
In client scenarios where multiple users share a /64, e.g. in a wifi hotspot,
then they are probably sharing one public IPv4 address with IPv4 NAT now.
In data centre scenarios, what do we expect there? It's not clear from
draft-lopez-v6ops-dc-ipv6-03. It may depend on whether the hosting is physical
or virtual? The allocated prefix is likely to be quite stable.
In home networks, the current trend in Europe seems to be /60 to /56, though
some offer /64 or /48. In some cases the equipment can only handle /64 now,
but expect that to shift to /56 or /60 later. The work on
draft-ietf-homenet-arch-05 expects the ISP to offer multiple /64's. It seems
many ISPs will vary the prefix offered over time much as with dynamic IPv4
addresses today. In some countries, that's apparently a legal requirement.
In enterprises, /48, and more likely to be stable.
Our evidence from incoming spam is that most of it comes via dual-stack list
servers. There's very little evidence of spam coming from autoconfigured
addresses that would indicate client senders.
Tim
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg