Mailing List Archive: NANOG: users

IPv6 Deployment for the LAN

1 2 3 4 5 6 7

View All

Index | Next | Previous | View Threaded

rps at maine

Oct 17, 2009, 5:55 PM

Post #1 of 151 (1788 views)
Permalink

IPv6 Deployment for the LAN

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.

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

herrin-nanog at dirtside

Oct 17, 2009, 6:28 PM

Post #2 of 151 (1749 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy <rps [at] maine> wrote:
> 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

--
William D. Herrin ................ herrin [at] dirtside bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

rps at maine

Oct 17, 2009, 6:38 PM

Post #3 of 151 (1751 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

> 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.

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

nanog at daork

Oct 17, 2009, 8:22 PM

Post #4 of 151 (1747 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18/10/2009, at 2:28 PM, William Herrin wrote:

> On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy <rps [at] maine> wrote:
>> 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?

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?

--
Nathan Ward

kauer at biplane

Oct 17, 2009, 8:51 PM

Post #5 of 151 (1747 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Sat, 2009-10-17 at 20:55 -0400, Ray Soucy wrote:
> 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.

Some hosts - very dumb ones or very old ones, probably
embedded stacks - may do SLAAC even with a prefix other than 64 bits!
Once a stack is broken,, anything is possible, so I'm not sure you win
much here. Zig to avoid one dud, you'll have to zag to avoid thenext,
and before you know it your life is nothing but dodging. Take the high
ground instead.

Better to find and cure/replace/isolate broken hosts than break your
entire network just to accommodate them. If you start doing the "wrong
thing" to accommodate broken hosts, you will never find peace. Zig to
avoid one dud; you'll have to zag to avoid the next and before you know
it your life is nothing but dodging. Take the high ground instead.

Do the advertisements "right", advise sysadmins that hosts should not do
SLAAC, and (if you are really concerned about broken hosts) collect MAC
address information from your switches and do an automated test of
reachability on all SLAAC addresses. You can generate the addresses
yourself easily enough from the prefix and the MAC. None should be
reachable, and any that are - well, you now know where they are and can
take appropriate action.

And then block all SLAAC addresses at your routers or firewalls, that'll
larn 'em :-)

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer [at] biplane) +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

Attachments:

signature.asc (0.19 KB)

swmike at swm

Oct 17, 2009, 9:54 PM

Post #6 of 151 (1750 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Sat, 17 Oct 2009, Ray Soucy wrote:

> 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.

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.

--
Mikael Abrahamsson email: swmike [at] swm

cluestore at gmail

Oct 17, 2009, 10:15 PM

Post #7 of 151 (1748 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

>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??

On Sat, Oct 17, 2009 at 7:55 PM, Ray Soucy <rps [at] maine> wrote:

> 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.
>
> --
>
> Ray Soucy
> Communications Specialist
>
> +1 (207) 561-3526
>
> Communications and Network Services
>
> University of Maine System
> http://www.maine.edu/
>
>

andy at nosignal

Oct 18, 2009, 1:03 AM

Post #8 of 151 (1746 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18 Oct 2009, at 01:55, Ray Soucy wrote:
> 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. :-(

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

--
Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com
NetSumo Specialist ISP/networks consultancy, Whitelabel 24/7 NOC

nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Oct 18, 2009, 1:22 AM

Post #9 of 151 (1743 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Sun, 18 Oct 2009 09:03:12 +0100
Andy Davidson <andy [at] nosignal> wrote:

>
> On 18 Oct 2009, at 01:55, Ray Soucy wrote:
> > 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".

> - 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. :-(
>
> 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
>
>
>
>
> --
> Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com
> NetSumo Specialist ISP/networks consultancy, Whitelabel 24/7 NOC
>
>

nanog at daork

Oct 18, 2009, 1:23 AM

Post #10 of 151 (1743 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18/10/2009, at 9:03 PM, Andy Davidson wrote:

> 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 !

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

--
Nathan Ward

nanog at daork

Oct 18, 2009, 1:29 AM

Post #11 of 151 (1742 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18/10/2009, at 9:22 PM, Mark Smith wrote:

> 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.

--
Nathan Ward

cra at WPI

Oct 18, 2009, 1:52 AM

Post #12 of 151 (1745 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Sun, Oct 18, 2009 at 09:29:41PM +1300, Nathan Ward wrote:
> 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.

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.

nanog at daork

Oct 18, 2009, 2:02 AM

Post #13 of 151 (1744 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18/10/2009, at 9:52 PM, Chuck Anderson wrote:

> On Sun, Oct 18, 2009 at 09:29:41PM +1300, Nathan Ward wrote:
>> 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.
>
> 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.

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

--
Nathan Ward

andy at nosignal

Oct 18, 2009, 3:02 AM

Post #14 of 151 (1737 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18 Oct 2009, at 09:22, Mark Smith wrote:

> 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.

On 18 Oct 2009, at 09:29, Nathan Ward wrote:

> RA is needed to tell a host to use DHCPv6

This is not ideal.

Andy

nanog at daork

Oct 18, 2009, 3:05 AM

Post #15 of 151 (1735 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 18/10/2009, at 11:02 PM, Andy Davidson wrote:

> On 18 Oct 2009, at 09:29, 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.

--
Nathan Ward

trejrco at gmail

Oct 18, 2009, 4:55 AM

Post #16 of 151 (1729 views)
Permalink

RE: IPv6 Deployment for the LAN [In reply to]

"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
-----Original Message-----
From: Chuck Anderson [mailto:cra [at] WPI]
Sent: Sunday, October 18, 2009 4:52 AM
To: nanog [at] nanog
Subject: Re: IPv6 Deployment for the LAN
<snip>
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.

trejrco at gmail

Oct 18, 2009, 4:58 AM

Post #17 of 151 (1730 views)
Permalink

RE: IPv6 Deployment for the LAN [In reply to]

"> 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

-----Original Message-----
From: Andy Davidson [mailto:andy [at] nosignal]
Sent: Sunday, October 18, 2009 6:02 AM
To: NANOG list
Subject: Re: IPv6 Deployment for the LAN

On 18 Oct 2009, at 09:22, Mark Smith wrote:

> 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.

On 18 Oct 2009, at 09:29, Nathan Ward wrote:

> RA is needed to tell a host to use DHCPv6

This is not ideal.

Andy

owen at delong

Oct 18, 2009, 5:10 AM

Post #18 of 151 (1729 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote:

> On 18/10/2009, at 11:02 PM, Andy Davidson wrote:
>
>> On 18 Oct 2009, at 09:29, 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.
>
> --
> Nathan Ward

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

trejrco at gmail

Oct 18, 2009, 5:27 AM

Post #19 of 151 (1731 views)
Permalink

RE: IPv6 Deployment for the LAN [In reply to]

"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 :)
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
-----Original Message-----
From: Owen DeLong [mailto:owen [at] delong]
Sent: Sunday, October 18, 2009 8:11 AM
To: Nathan Ward
Cc: NANOG
Subject: Re: IPv6 Deployment for the LAN

On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote:

> On 18/10/2009, at 11:02 PM, Andy Davidson wrote:
>
>> On 18 Oct 2009, at 09:29, 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.
>
> --
> Nathan Ward

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

nanog at daork

Oct 18, 2009, 5:39 AM

Post #20 of 151 (1728 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 19/10/2009, at 1:10 AM, Owen DeLong wrote:

> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote:
>
>> On 18/10/2009, at 11:02 PM, Andy Davidson wrote:
>>
>>> On 18 Oct 2009, at 09:29, 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

> 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?

--
Nathan Ward

kloch at kl

Oct 18, 2009, 8:45 AM

Post #21 of 151 (1725 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

Nathan Ward wrote:
>
> On 19/10/2009, at 1:10 AM, Owen DeLong wrote:
>
>> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote:
>>
>>> On 18/10/2009, at 11:02 PM, Andy Davidson wrote:
>>>
>>>> On 18 Oct 2009, at 09:29, 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

rps at maine

Oct 18, 2009, 9:26 AM

Post #22 of 151 (1726 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

I generally agree with the design of RA and using DHPCv6 as a
supplement to it. The problems here seem to be more along the lines
of implementation in clients. I suspect it will take some time for
the dust to settle and vendors to get their act together.

I notice that Cisco has a "prefix no-autoconfig" statement in some
releases in addition to no-advertise. The code I'm running doesn't
seem to support this yet. I'll have to dig deeper to see what series
support it and how it interacts with hosts. If hosts actually do
respect it, it will likely lead to our migration to using /64s, though
a lot will depend on the time tables we can set to move to code that
will support this on our routers. I do remember seeing some notes
about some implementations of IPv6 simply ignoring that flag for the
prefix, though, so I'm still hesitant to endorse it until I've had a
chance to test a wide variety of hosts in this configuration.

Still, using a prefix other than a /64, but maintaining a migration
path to /64 in the future, seems to be the best way to get IPv6 rolled
out to the edge from a political standpoint. It's easier to make the
case to extend IPv6 if you can be fairly certain that it won't cause
hosts to suddenly start using IPv6 on their own. I have yet to run
into an IPv6 implementation that will use SLAAC with a prefix other
than a /64, thankfully.

>From what I've been told, Cisco is actively working on RA-gaurd for
their managed switching platforms, which will be nice to see.

Reading a bit of the discussions regarding IPv6 in the Apple world, it
seems that they're after supporting DNS server information in RA using
RFC 5006. I think RFC 5006 is a very bad idea personally. DHCPv6 was
designed to work in harmony with RA, and providing host configuration
is beyond the scope of RA. I hope that we don't start seeing
implementations of this as it will lead to an environment where some
clients support DHCPv6 and some do not.

The SLAAC vs. DHCPv6 war all seems a bit silly. They're both tools
that are designed to compliment one another, and both have their uses.

DHCPv6 does complicate things with the DUID rather than using the
physical address, but I can appreciate the problems they're trying to
overcome. It just makes this a little more complicated for those of
us who would like to maintain associations between a hosts IP and IPv6
information in a dual-stack environment.

On Sun, Oct 18, 2009 at 11:45 AM, Kevin Loch <kloch [at] kl> wrote:
> Nathan Ward wrote:
>>
>> On 19/10/2009, at 1:10 AM, Owen DeLong wrote:
>>
>>> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote:
>>>
>>>> On 18/10/2009, at 11:02 PM, Andy Davidson wrote:
>>>>
>>>>> On 18 Oct 2009, at 09:29, 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
>
>

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

trejrco at gmail

Oct 18, 2009, 10:29 AM

Post #23 of 151 (1715 views)
Permalink

RE: IPv6 Deployment for the LAN [In reply to]

> In some cases different devices on a segment need a different
> default router (for default). This is the fundamental

This capability is also defined, "more specific routes" - but no one
encouraged any vendors that I know of to support it - so they don't. Big
demand?

> problem with RA's, they shotgun the entire segment.

As opposed to a standard deployment, where the DHCP server provides the same
information to every host on that link ... ???

> 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.

These are separate problems.
Host configuration vs. first-hop redundancy, and we can solve them
independently.

> Why can't we have those options in our toolbox in addition to
> this continuously evolving RA+hacks?

You say hacks, others see it as relatively-speaking simple additions of more
functionality.
You can define any options you want for DHCPv6, write a draft and get
community support.
I don't see how that ("continuously evolving DHCPv6 hacks") is any better
than what is happening with RAs?

I, for one, am just fine with RAs being the first step - leading to either
SLAAC or (some mode of) DHCPv6 ...
/TJ

trejrco at gmail

Oct 18, 2009, 10:33 AM

Post #24 of 151 (1714 views)
Permalink

RE: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

> I notice that Cisco has a "prefix no-autoconfig" statement in some

Yes, advertise it as on-link but not suitable for autoconfig.
You would want to do this (along with the M & O bits) for a stateful-DHCPv6
segment ...

> >From what I've been told, Cisco is actively working on RA-gaurd for
> their managed switching platforms, which will be nice to see.

And not just Cisco, IIRC it is an open standard anyone can implement ... ?

> The SLAAC vs. DHCPv6 war all seems a bit silly. They're both tools
> that are designed to compliment one another, and both have their uses.

++1
(And if I could vote "yes" on that statement more than once on that I would
...)

/TJ

rps at maine

Oct 18, 2009, 10:38 AM

Post #25 of 151 (1714 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

> And not just Cisco, IIRC it is an open standard anyone can implement ... ?

Here is the work being done on RA-Gaurd:
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-03

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

1 2 3 4 5 6 7

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads