Re: v6 subnet size for DSL & leased line customers

On 26 dec 2007, at 19:22, Tony Li wrote:

> This doesn't resolve the real underlying problem:
Ethernet is  
> inherently insecure.  MAC addresses can be forged,
protocols (ARP,  
> ND) can be forged and at this point, there's not much
that we can do  
> about it.  Architecturally, we need authentication over
each and  
> every control plane packet sent.  Getting there without
invoking the  
> full complexity of a public key infrastructure is still
an unsolved  
> problem, AFAIK.

Actually, for this particular purpose, this is mostly a
solved  
problem, although there is of course no free lunch.

Many switches can enforce a MAC/port relationship, so that
MAC  
addresses can't be spoofed.

Neighbor discovery and router advertisements can be secured
with SEND  
(SEcure Neighbor Discovery). This happens through CGAs,  
cryptograpically generated addresses. Basically, the lower
64 bits of  
the IPv6 address contains a hash over a public key. This
makes it  
possible to prove ownership over an address.

The not free part is that you need to configure certificates
for trust  
relationships = the routers that may be default gateways.

In a message written on Wed, Dec 26, 2007 at 09:19:54PM
+0100, Iljitsch van Beijnum wrote:
> Many switches can enforce a MAC/port relationship, so
that MAC  
> addresses can't be spoofed.

Which gets to the crux of my question.

If you're a shop that uses such features today (MAC/Port
tracking,
DHCP snooping, etc) to "secure" your IPv4
infrastructure does IPv6
RA's represent a step backwards from a security perspective?
 Would
IPv6 deployment be hindered until there is DHCPv6 snooping
and
DHCPv6 is able to provide a default gateway, a-la how it is
done
today in IPv4?

It would be very interesting to me if the answer was
"it's moot
because we're going to move to CGA's as a step
forward"; it would
be equally interesting if the answer is "CGA isn't
ready for prime
time / we can't deploy it for xyz reason, so IPv6 is less
secure
than IPv4 today and that's a problem."

-- 
       Leo Bicknell - bicknellufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bic
knell/
Read TMBG List - tmbg-list-requesttmbg.org, www.tmbg.org

> Personally, I'm not a big fan of DHCPv6. First of all,
from a  
> philosophical standpoint: I believe that stateless
autoconfiguration  
> is a better model in most cases (although it obviously
doesn't support  
> 100% of the DHCP functionality). But apart from that,
some of the  
> choices made along the way make DHCPv6 a lot harder to
use than DHCP  
> for IPv4. Not only do you lack a default gateway (which
is actually a  
> good thing for fate sharing reasons) but also a subnet
prefix length  
> and any extra on-link prefixes. So even if you do
address  
> configuration with DHCPv6 you need RAs for that other
information.  

Which is probably going to make IPv6 deployment slower in
service
provider environments.

> There's also tons of ways to complicate your life by
mixing stateless  
> autoconf and DHCPv6, especially since most systems
don't support  
> DHCPv6 unless you install additional software. Last but
not least,  
> DHCPv6 has a stateful mode that's appropriate for
address assignment  
> or prefix delegation, and a stateless mode that's more
efficient for  
> the configuration of information that's not
client-specific.  
> Unfortunately, it's up to the client to initiate the
desired mode.  
> Then there are the M and O bits in RAs that tell you
whether to do  
> DHCPv6 but a number of DHCPv6 aficionados look like
they want to  
> ignore those bits.

Again, this is something that's going to slow down
deployment in
service provider environments. Providers are comfortable
with the IPv4
DHCP model (which is definitely not stateless) and many of
us would
like to keep this.

> What this all boils down to is that if you want to
deploy DHCPv6 you  
> need to install software on a lot of systems and modify
a lot of  
> configurations. If you're going to do all that, it's
easier to simply  
> configure this stuff manually. The only downside to
that is that it's  
> not compatible with easy renumbering, but then, you
need to do more  
> than just automate address assignment to support easy
renumbering.

"Configure this stuff manually" may work for a
small number of
customers. It is highly undesirable (and probably won't be
considered
at all) in an environment with, say, 1 million customers.

Steinar Haug, Nethelp consulting, sthaugnethelp.no

On 27 dec 2007, at 11:57, sthaugnethelp.no wrote:

> "Configure this stuff manually" may work for
a small number of
> customers. It is highly undesirable (and probably won't
be considered
> at all) in an environment with, say, 1 million
customers.

Of course not. But RAs on a subnet with a million customers
doesn't  
work either, nor does DHCP on a subnet with a million
customers.

If we're talking about provisioning cable/DSL/FTTH users,
that's a  
completely different thing. Here, DHCPv6 prefix delegation
to a CPE  
which then provides configuration to hosts on its LAN side
would be  
the most appropriate option. However, the specifics of that
model need  
to be worked out as there are currently no ISPs and no CPEs
that do  
that, as far as I know.

On Thu, 27 Dec 2007 12:11:54 +0100
Iljitsch van Beijnum <iljitschmuada.com> wrote:

> 
> On 27 dec 2007, at 11:57, sthaugnethelp.no wrote:
> 
> > "Configure this stuff manually" may work
for a small number of
> > customers. It is highly undesirable (and probably
won't be considered
> > at all) in an environment with, say, 1 million
customers.
> 
> Of course not. But RAs on a subnet with a million
customers doesn't  
> work either, nor does DHCP on a subnet with a million
customers.
> 
> If we're talking about provisioning cable/DSL/FTTH
users, that's a  
> completely different thing. Here, DHCPv6 prefix
delegation to a CPE  
> which then provides configuration to hosts on its LAN
side would be  
> the most appropriate option. However, the specifics of
that model need  
> to be worked out as there are currently no ISPs and no
CPEs that do  
> that, as far as I know.

I haven't had a chance to test it, but according to
"Deploying IPv6
Networks", IOS can support DHCPv6 based prefix
delegation. It even
supports multiple downstream interfaces on the CPE - you
configure the
subnet number you want on each of the interfaces, and the
CPE will
configure the DHCP-PD learned /48 on the front of them
automatically
and then start announcing those prefixes in RAs out those
interfaces.

Regards,
Mark.

-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"