v6 subnet size for DSL & leased line customers
Iljitsch van Beijnum
iljitsch at muada.com
Thu Dec 27 10:27:13 UTC 2007
On 26 dec 2007, at 22:40, Leo Bicknell wrote:
> 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."
With IPv4, a lot of these features are developed by vendors and
(sometimes) later standardized in the IETF or elsewhere. With IPv6,
the vendors haven't quite caught up with the IETF standardization
efforts yet, so the situation is samewhat different. For instance,
SEND/CGA is excellent work, but we've only recently seen the first
implementations.
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.
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.
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.
I don't think IPv6 address configuration in general and DHCPv6 in
particular will ever be fully equivalent to how things work with IPv4.
This is really the place where the differences between the two
protocols are the biggest. For those of us who are familiar with IPX,
AppleTalk, CLNP and IPv4: IPv6 basically uses the address
configuration methods from all of those, no wonder it can get a bit
complex.
That being said, please go to your vendors and tell them what you
need. Preferably at a high level, so they can provide the
functionality in the optimal way, rather than just revert back to the
IPv4 way of doing things.
More information about the NANOG
mailing list