IPv6 Deployment for the LAN

Mailman List Mirror (Read Only)
1

Looking for general feedback on IPv6 deployment to the edge.

As it turns out delivering IPv6 to the edge in an academic setting has
been a challenge. Common wisdom says to rely on SLAAC for IPv6
addressing, and in a perfect world it would make sense.

Given that historically we have relied on DHCP for a means of NAC and
host registration, like many academic institutions, the idea of
sweeping changes to accommodate IPv6 was just not going to happen in
the near future.

The only solution that lets us expand our roll out IPv6 to the edge
without major changes to the production IPv4 network seems to point to
making use of DHCPv6, so the effort has been focused there.

Our current IPv6 allocation schema provides for a 64-bit prefix for
each network. Unfortunately, this enables SLAAC; yes, you can
suppress the prefix advertisement, and set the M and O flags, but that
only prevents hosts that have proper implementations of IPv6 from
making use of SLAAC. The concern here is that older hosts with less
than OK implementations will still enable IPv6 without regard for the
stability and security concerns associated with IPv6.

Needless to say, the thought of being able to enable IPv6 on a
per-host basis is met with far less resistance than opening up the
floodgates and letting SLAAC take control.

Ultimately, the best solution that I've been able to come up with is
to preserve the IPv6 allocation schema and reserve a 64-bit prefix for
each network, but for the initial deployment use an 80-bit one in its
place with the extra 16 bits given a value of 1. The advantages of
this: Guarantee that SLAAC will not be initiated for the prefix;
Allow for a migration path to 64-bit prefixes in the future; and, Make
it easy to identify a network that us making use of an 80-bit prefix
by setting the extra bits to a value of 1.

This allows us to be fairly confident that extending IPv6 to edge
networks will not impact production services, and focus on DHCPv6 for
host configuration and address assignment.

We have no problem using a 64-bit prefix and letting SLAAC take care
of addressing for certain networks where we actually manage the hosts,
so that has been included as an exception. All other networks,
however, will make use of DHCPv6 or manual configuration to receive
native IPv6.

So far, this has proven to work well with testing of various hosts and
applications.

Has anyone run into issues with applications in not using a 64-bit prefix?

Of course, the other challenge here is proper DHCPv6 client
implementations for host operating systems. Linux, Windows Server
2003 and later, Windows Vista, and Windows 7 all support DHCPv6.
Windows XP has a poor implementation of IPv6 but has the option of
using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a
challenge; it currently has no option for DHCPv6, though newer
releases provide for manual configuration of IPv6 addressing.

Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X?

Since the goal for this initial wave is to make IPv6 available to
those who request it or have a need for it, we feel its acceptable
that there will need to be some user participation in enabling IPv6
for a host. I think the hope is that more systems, like Windows 7,
will begin including mature DHCPv6 clients which are enables when the
M flag for a router advertisement is set and perhaps make it the
default behavior. Is this likely to happen or am I being too
optimistic?

Anyway, just thought I'd bounce it to NANOG and get some feedback.

2

As it turns out delivering IPv6 to the edge in an academic setting has
been a challenge. Common wisdom says to rely on SLAAC for IPv6
addressing, and in a perfect world it would make sense.

Ray,

Common wisdom says that?

Our current IPv6 allocation schema provides for a 64-bit prefix for
each network. Unfortunately, this enables SLAAC; yes, you can
suppress the prefix advertisement, and set the M and O flags, but that
only prevents hosts that have proper implementations of IPv6 from
making use of SLAAC. The concern here is that older hosts with less
than OK implementations will still enable IPv6 without regard for the
stability and security concerns associated with IPv6.

I thought someone had to respond to router solicitations for stateless
autoconfig of global scope addresses to happen. On Linux you just
don't run the radvd. On Cisco I think it's something like "ipv6 nd
suppress-ra" in the interface config. Does that fail to prevent
stateless autoconfig? Or is there a problem with the operation of
DHCPv6 if router advertisements aren't happening from the router?

Regards,
Bill Herrin

3

I thought someone had to respond to router solicitations for stateless
autoconfig of global scope addresses to happen. On Linux you just
don't run the radvd. On Cisco I think it's something like "ipv6 nd
suppress-ra" in the interface config. Does that fail to prevent
stateless autoconfig? Or is there a problem with the operation of
DHCPv6 if router advertisements aren't happening from the router?

The "ipv6 nd suppress-ra" config will only suppress unsolicited RA, it
will still respond to RA solicitations. Load it up in Wireshark and
you'll see. A lot of host implementations of IPv6 seem to enable
SLAAC as soon as they see any 64-bit prefix regardless of what flags
are set.

Making assumptions about IPv6 has proven to be unwise in my experience.

So far, the only thing that I've seen that is close to working is to
configure the router to not advertise the 64-bit prefix using "ipv6 nd
prefix <prefix> no-advertise", but at that point it seems easier to
just go with a 80-bit prefix and remove any doubt.

4

RA is generally required whether you use stateless or stateful autoconfiguration. You have to tell the hosts to send a DHCPv6 DISCOVER message by turning on the managed flag in the RA.

RA does not mean that SLAAC happens.

Ray, do you have examples of hosts or stacks that ignore AdvAutonomousFlag?

5

IETF has historically dropped the ball on delivering IPv4/v6 services securely, and all the development for IPv4 done outside the IETF hasn't been integrated into IPv6, which now shows when people are trying to deploy it.

There is now some working going on though, you should look into the SAVI working group, they have some nice work going on both for v4 and v6 in this space. The v6ops WG is also producing deployment models for securely deploying v6 in ISP environment.

6

Since the goal for this initial wave is to make IPv6 available to
those who request it or have a need for it, we feel its acceptable
that there will need to be some user participation in enabling IPv6
for a host.

To me, from a small ISP perspective, this is where the largest delima is....
what 'vendor' is already depolying end user equipment that is ipv6 ready??
Then there's the 'delivering the customer' their ipv6 block (hopefully
alongside their ipv4 block). Dual stack seems the way to go...

To me, there's still a lot of wiggle room on how this should be deployed to
the absolute edge.

What's folks experience in rolling this out the the customer ... be it DHCP
or SLAAC?? Also from a BBA perspective??

7

The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there.

[...]

Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control.

Hi, Roy --

Good summary, thanks for the write-up.

I reluctantly just use SLAAC on our own office LANs because, we're still quite a small and nimble team, therefore we can secure our network against our SLAAC security concerns by locking down access to the network. I realise this isn't going to work for everyone, as it doesn't fit well for the security needs of your much larger campus network. It also doesn't work for some of our customers who have DHCP in their toolbox for provision certain hosting environments.

DHCPv6 today lacks default-router option support, so you are left with some pretty awful choices if you don't want to use the router solicitation/advertisement, err, 'features' in SLAAC :

  - Static route on the device
    - Actually, you could use the *same* link-local address to keep this the same on all devices on your network, which you continue to support long after a "better" protocol comes along. This reduces your support overhead.

  - end user runs some routing protocol
    - I don't want to give my router the extra work though. And it feels like a stupid idea. And end user OSes don't tend to have them installed.

  - Don't roll v6 beyond engineering teams, until something better comes along
    - Sadly, I think that this is the option people are taking. :frowning:

I don't know the history of the process that led to DHCPv6 ending up crippled, and I have to admit that it's not clear how I signal this and to whom, but for the avoidance of doubt: this operator would like his tools back please. Support default-routing options for DHCPv6 !

Andy

8

> The only solution that lets us expand our roll out IPv6 to the edge
> without major changes to the production IPv4 network seems to point
> to making use of DHCPv6, so the effort has been focused there.
[...]
> Needless to say, the thought of being able to enable IPv6 on a per-
> host basis is met with far less resistance than opening up the
> floodgates and letting SLAAC take control.

Hi, Roy --

Good summary, thanks for the write-up.

I reluctantly just use SLAAC on our own office LANs because, we're
still quite a small and nimble team, therefore we can secure our
network against our SLAAC security concerns by locking down access to
the network. I realise this isn't going to work for everyone, as it
doesn't fit well for the security needs of your much larger campus
network. It also doesn't work for some of our customers who have DHCP
in their toolbox for provision certain hosting environments.

DHCPv6 today lacks default-router option support, so you are left with
some pretty awful choices if you don't want to use the router
solicitation/advertisement, err, 'features' in SLAAC :

I'm curious what the issue is with not having a default-router option
in DHCPv6?

If it's because somebody could start up a rogue router and announce
RAs, I think a rogue DHCPv6 server is (or will be) just as much a
threat, if not more of one - I think it's more likely server OSes will
include DHCPv6 servers than RA "servers".

9

I think what you really want is an on-link prefix option in DHCPv6. Or at least, you'd need that as well as a default router option.

As I've said before, RA does not mean SLAAC. DO NOT use the two words interchangeably.

We have two address configuration mechanisms, RA is the transport for one (SLAAC) and is the hint to use another (DHCPv6 stateful).
The use of RA does NOT require the use of either mechanism.
Without RA, we don't know which to use, without manual configuration. I for one don't want to have to fool around every time I move to a new network, and I'm a tech guy.

Can we put this in to a FAQ somewhere, I write this in almost every IPv6 thread that comes up on NANOG.

The reason Ray's perceived problem exists is that when using DHCPv6 stateful for address configuration, you should also include the prefix in an RA message. This is because DHCPv6 doesn't give out prefix lengths, it only gives out addresses.

There is an option (the A bit) with each prefix in an RA message, which says whether this prefix can be used for SLAAC or not (1 = SLAAC). Ray's perception (fear?) is that there are some implementations that will ignore the contents of this bit, and use the prefix for SLAAC regardless.

I'm interested to see if these implementations actually exist, I haven't come across any myself or heard of any - but I've not been looking.

Anyway, start here for a discussion of prefix lengths in DHCPv6:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg07412.html

10

I'm curious what the issue is with not having a default-router option
in DHCPv6?

This mechanism is provided by RA.
RA is needed to tell a host to use DHCPv6, so RA is going to be there whenever you have DHCPv6.
There's no point putting a default router option in to DHCPv6 at this point.

If it's because somebody could start up a rogue router and announce
RAs, I think a rogue DHCPv6 server is (or will be) just as much a
threat, if not more of one - I think it's more likely server OSes will
include DHCPv6 servers than RA "servers".

Perhaps, but if you're operating a LAN segment you're going to want to filter rouge RA and DHCPv6 messages from your network, just like you do with DHCP in IPv4.
Filtering RA and DHCPv6 are done in very similar ways.

11

Unfortunately, no. Many/most LAN switches don't support filtering
IPv6 traffic yet. Of those that do, most only support TCP/UDP ports
but not ICMPv6 types or RA specifically. Therefore, right now it is
probably easier to find support to filter DHCPv6 (udp source port 547)
than it is to find support to filter RA. This is a real problem even
for people who are not using IPv6 right now and have no desire to use
IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue
box on the LAN, breaking access to dual-stack servers on the Internet.
The impact is worse when you start trying to roll out IPv6 dual-stack
to selected servers on your own LAN.

12

This is true for now until we get switches with code to do this, and also doesn't change my point.

13

If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA "servers".

Disagree - rogue offers affect people without a lease, so the impact of an attack is not immediate. Filtering DHCP on v4 is well understood, an update to current operational practice rather than a new system.

14

Why?
Remember RA does not mean SLAAC, it just means RA.

15

"This is a real problem even for people who are not using IPv6 right now and
have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6
traffic to a rogue
box on the LAN"

Answer = "RA Guard" - push your vendor-of-choice to implement it :).

/TJ

16

"> RA is needed to tell a host to use DHCPv6
This is not ideal."

That is entirely a matter of opinion, and one frequently debated still.

FWLIW - I think RAs are a perfectly fine way to distribute information about
the router itself, and to provide hints about the environment (e.g. - "Yes,
we do Stateful DHCPv6 here ("+M", and "+O' as well" ...)

/TJ

17

Because RA assumes that all routers are created equal.
Because RA is harder to filter.
Because the bifercated approach to giving a host router/mask information and address information
  creates a number of unnecessary new security concerns.

I think those are the top 3. I can't think of the rest of the list off the top of my head as my
brain still thinks it's 5 AM.

Owen

18

"Because RA assumes that all routers are created equal.
Because RA is harder to filter.
Because the bifercated approach to giving a host router/mask information and
address information creates a number of unnecessary new security concerns."

Off the top of my head, the easiest answers are:
Default Router Preference, well supported on hosts and routers, doesn't
cover 100% of every corner case, but then again - nothing does :slight_smile:
RA Guard - push vendors to implement (otherwise, other
monitoring/preventative measures are available - but 3rd party)
And I still think the router is in a (much) better position to inform hosts
about the router's and link's information than some server three hops --->
that way.

/TJ

19

RA is needed to tell a host to use DHCPv6

This is not ideal.

Why?
Remember RA does not mean SLAAC, it just means RA.

Because RA assumes that all routers are created equal.

RFC4191

Because RA is harder to filter.

DHCP in IPv4 was hard to filter before vendors implemented it, too.

Because the bifercated approach to giving a host router/mask information and address information
  creates a number of unnecessary new security concerns.

Security concerns would be useful to explore. Can you expand on this?

20

Nathan Ward wrote:

RA is needed to tell a host to use DHCPv6

This is not ideal.

Why?
Remember RA does not mean SLAAC, it just means RA.

Because RA assumes that all routers are created equal.

RFC4191

In some cases different devices on a segment need a different
default router (for default). This is the fundamental
problem with RA's, they shotgun the entire segment.

Because RA is harder to filter.

DHCP in IPv4 was hard to filter before vendors implemented it, too.

Because the bifercated approach to giving a host router/mask information and address information
    creates a number of unnecessary new security concerns.

Security concerns would be useful to explore. Can you expand on this?

What would be useful would be having the option to give a default
router to a dhcpv6 client, and having vrrpv6 work without RA's.
Why can't we have those options in our toolbox in addition to
this continuously evolving RA+hacks?

- Kevin