Re: [Asrg] Implementing IPv6 DNSBLs

On 12/11/10 7:19 AM, der Mouse wrote:
> > IPv6 represents an incomprehensibly large space.  [...]  Divided
> > evenly, this could allow every person on the planet to control 14
> > million networks, so why be frugal?
> Because it's not about just the numbers.  If it were, there'd be no
> IPv4 space crunch at all, rather than the minor one we have now.
>
> Like v4, v6 space is managed hierarchically, both in assignment and, in
> a different way, routing.  There is no surer way to run out of a finite
> resource than to think of, and treat, it as infinite.  We did that with
> v4.  We did that with our planet's ability to supply us with petroleum.
> We did that with our planet's ability to absorb and detoxify the
> various wastes we generate.  And, guess what?  We're coming up against
> the finiteness of these "infinite" resources.  Treat v6 the same way
> and the same thing will happen.
Check out the phone app ByeBye v4.  It currently shows IANA exhaustion 
in less than 72 days of the >100 million remaining v4 addresses.
http://ipv6.he.net/bgpview/bgp.html
Offers a view of current v6 assignments.

There are 3,849 routes with thousands having 96 bit (/32) or more ranges 
and some having 109 bit (/19) of the 128 bit address space.  While this 
represents a very small fraction of the possible v6 assignments, 
ignoring the lower 64 bits still exposes 32 to 45 bits of the routed 
portions of this space.
Just the routed portion of v6 represents tens of thousands times the 
range represented by the entire v4 address space, where each network may 
contain the entire v4 address space squared.  This suggests tracking 
just the global and subnet portion of v6 will likely require thousands 
of times more resources than that used for the entire v4.  The 
expenditure of these resources must also consider the exponentially 
growing v6 assignments.
The way you view IP address space _must_ fundamentally change.  Blocking 
lists containing individual addresses will _never_ be viable.  Defending 
critical infrastructure will likely involve reassignment within private 
namespace, rather than dependence upon blocking lists.  Acceptance of a 
v6 exchange initially expected use of IPsec after all.
For SMTP to survive, SMTP must cryptographically authenticate the domain 
of the server publicly issuing the message.  This domain must also 
encompass the entity accepting responsibility for the message's 
destination.  Unfortunately, DKIM falls short in this regard, and should 
be considered a defense against false-positive detections of phishing 
attempts and not a basis for reputation.
Perhaps keyassure or StartTLS might offer a cryptographic basis for 
email acceptance, which then implies one must depend upon a vetted list 
of known good domains.
> > The lower 64 bits, the v6 interface,
> There really is no such thing.  One relatively common way to assign v6
> addresses is to use a /64 with an EUI64 in the low 64 bits, but it's
> hardly the only way, and there definitely is no reason to assume
> everyone will do it.  (There are also reasons to not do it; it's
> extremely annoying to swap network cards, or move the disk to another
> machine, and have the machine silently change addresses on you.)
>
> Of course, if a DNSL decides that it will list at /64 granularity,
> that's its business.  Some v4 DNSLs are coarser than /32, too.  But
> anything that has the assumption that every /64 can be treated as
> homogenous wired into it will have a rather nasty awakening when it
> runs up against reality.
Nearly all network segments in v6 will be on a /64 network boundary. 
Routers control the upper 64 bits of this space, where hosts use the 
lower 64 bits. The smallest v6 subnet address range is equal to the 
current Internet squared.  See RFC2462 StateLess Address 
Auto-Configuration (SLAAC), and Section 5.4 Duplicate Address Detection 
(DAD).
Unfortunately, anyone that assumes blocking lists will be able to 
selectively exclude sections of the v6 Interface, or that these 
addresses will be typically assigned manually is likely in for a very 
rude awakening.  No doubt while people whisper sweet v6 DNSBLs into 
their ear. :^)
-Doug

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg