DHCPv6 PD & Routing Questions

Mailman List Mirror (Read Only)
1

Hi,

Have a simple couple of questions here.

In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any
reference to the protocol having any role in managing the routing of
prefixes it delegates. Perhaps I missed it, but I somewhat expected the
omission of this responsibility would be the case.

My questions are:

1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
managing routes to prefixes it delegates, or does it consider this
outside of its function? (I suspect the latter)
2) What are the most common ways of managing the routing of delegated
prefixes in the ISPs routing domain? Has a standard method/best
practice emerged yet? Routing protocols? IPv6 RAs?

One obvious answer would be routing protocols. In my brief googling,
I've seen a forum post that seems to indicate that Comcast makes use of
RIPng on their CPE to propagate routing information for prefixes
delegated to it. Can someone confirm this? This would seem as good a
method as any to do this, albeit with obvious security concerns.

What's the best way to implement a DHCPV6 PD client on a Linux router?
Dibbler seems to do everything except route propagation (asks for PD,
puts PD address on local NIC if asked). Anything better out there?

TIA,
- Jim

2

Hi,

Have a simple couple of questions here.

In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any
reference to the protocol having any role in managing the routing of
prefixes it delegates. Perhaps I missed it, but I somewhat expected the
omission of this responsibility would be the case.

My questions are:

1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
managing routes to prefixes it delegates, or does it consider this
outside of its function? (I suspect the latter)

Yes and no…

DHCPv6 doesn’t include anything specifically per se, but it does require that
the local router sees the DHCPv6 PD answer in the process of passing it
along to the target, and there’s a pretty obvious expectation that said router
will have to arrange to do the needful in that respect.

2) What are the most common ways of managing the routing of delegated
prefixes in the ISPs routing domain? Has a standard method/best
practice emerged yet? Routing protocols? IPv6 RAs?

RAs really only apply to subnet local advertisement of routers and
the on-net prefixes in most implementations.

I don’t think any of the various methods of using routing protocols,
static pre-routed blocks from which PDs are delegated, etc. could
necessarily be called “standardized”, but there are probably a few
that are more popular than most of the others.

Unfortunately, PD is really still in its infancy in terms of development
and real running code for complete implementations throughout any
sort of site hierarchy.

Owen

3

Thanks for the answer Owen!

So it sounds like things are still in flux. But it least it answers my
main question of "have I missed something here"?

Could you elaborate on the "local router seeing the PD answer" a bit? I
presume by "local router" you mean router acting as DHCPv6 relay? Or do
you mean the router which made the original request?

Would it be fair to say that the RFCs only really talk about delegating
the prefixes, and leave what to do with the prefixes themselves up to
the implementer?

I'm asking these questions because I'm doing a little class for some
folks on IPv6 and this is one area where I couldn't find answers.

- Jim

4

Hi,

Have a simple couple of questions here.

In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any
reference to the protocol having any role in managing the routing of
prefixes it delegates. Perhaps I missed it, but I somewhat expected the
omission of this responsibility would be the case.

My questions are:

1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
managing routes to prefixes it delegates, or does it consider this
outside of its function? (I suspect the latter)

Yes and no…

DHCPv6 doesn’t include anything specifically per se, but it does require that
the local router sees the DHCPv6 PD answer in the process of passing it
along to the target, and there’s a pretty obvious expectation that said router
will have to arrange to do the needful in that respect.

2) What are the most common ways of managing the routing of delegated
prefixes in the ISPs routing domain? Has a standard method/best
practice emerged yet? Routing protocols? IPv6 RAs?

RAs really only apply to subnet local advertisement of routers and
the on-net prefixes in most implementations.

I don’t think any of the various methods of using routing protocols,
static pre-routed blocks from which PDs are delegated, etc. could
necessarily be called “standardized”, but there are probably a few
that are more popular than most of the others.

Unfortunately, PD is really still in its infancy in terms of development
and real running code for complete implementations throughout any
sort of site hierarchy.

Owen

Thanks for the answer Owen!

So it sounds like things are still in flux. But it least it answers my
main question of "have I missed something here"?

Could you elaborate on the "local router seeing the PD answer" a bit? I
presume by "local router" you mean router acting as DHCPv6 relay? Or do
you mean the router which made the original request?

I mean the router that will deliver the PD to the requesting DHCPv6 client.

If the DHCPv6 server is on-net, then this will be the requesting client.
Otherwise, it will be the last relay router.

Would it be fair to say that the RFCs only really talk about delegating
the prefixes, and leave what to do with the prefixes themselves up to
the implementer?

Yes… At least at this time. Some of the work in homenet might include
some suggestions for some implementations.

I'm asking these questions because I'm doing a little class for some
folks on IPv6 and this is one area where I couldn't find answers.

Depending on your audience, I’d suggest that unless this is an advanced
IPv6 class, it’s probably one of those topics left for extra-curicular research.

Owen

5

My questions are:

1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
managing routes to prefixes it delegates, or does it consider this
outside of its function? (I suspect the latter)

It's considered outside of function. It makes a lot of sense, from the
*protocol's* viewpoint, not to go constraining itself in any way.

*Implementations*, on the other hand, appear to have kinda dropped the ball,
insofar as none of the OSS DHCPv6 servers that can do PD appear to have put
any thought into what to do with the prefixes delegated.

2) What are the most common ways of managing the routing of delegated
prefixes in the ISPs routing domain? Has a standard method/best
practice emerged yet? Routing protocols? IPv6 RAs?

I hacked some code into ISCP DHCPD to give called scripts sufficient knowledge
to add routes to the local machine's routing table:

    Brane Dump: Multi-level prefix delegation is not a myth! I've seen it!

(Holy crap, I published that post almost exactly a year ago today...)

More recently, I'm doing some work with a production containerised
environment, and I decided to use RAs to propagate /64 routes amongst the
container hosts and immediate upstream router (the upstream router has the
whole /48 routed to it, and the router then gets the RAs to know which
machine to send the /64 to). It seems to work rather well. If I had any
more complicated a setup, I'd definitely have broken out the OSPF or
something.

One obvious answer would be routing protocols. In my brief googling,
I've seen a forum post that seems to indicate that Comcast makes use of
RIPng on their CPE to propagate routing information for prefixes
delegated to it. Can someone confirm this? This would seem as good a
method as any to do this, albeit with obvious security concerns.

I can't confirm Comcast's use of anything in particular, but I'd certainly
consider it a possibility. In an ISP environment, I think I'd prefer for my
routing to *not* be under the control of anything that the customer can get
their fingers into, but I'm sure there's suitable filters in place to stop a
customer trying to announce all of 2000::/3...

What's the best way to implement a DHCPV6 PD client on a Linux router?
Dibbler seems to do everything except route propagation (asks for PD,
puts PD address on local NIC if asked). Anything better out there?

Well, I'm quite partial to the solution I hacked up for ISC DHCPD, but it's
hard to argue that I'm an unbiased observer. <grin>

- Matt

6

There is no actual requirement that the relay function runs on a router.
There might be more than one router that needs to know how to route the
prefix. You might be using VRRP and you would need a synchronization
protocol so the backup router also learns the prefix.

I hold that as long nobody cared to write down the obvious implementation
in a RFC, you are in error to assume said implementation. Unfortunately
there are a few CPEs that do exactly that. Fortunately most work correctly.

Also it might be obvious but not all router vendors actually implemented
DHCPv6-PD snooping on the DHCPv6 relay function. Ours did not (yet - they
probably will sometime before unix time wrapover). They can claim no RFC
requires this and be right.

I came around that limitation by implementing predictable assignments. Each
requesting router/CPE will be assigned a fixed WAN address that is tied to
the prefix also assigned. I then inject the routes using Exabgp.

Example exabgp config:

group g1 {
  static {
route 2a00:7660:202::/48 next-hop 2a00:7660:0:2::2;
route 2a00:7660:203::/48 next-hop 2a00:7660:0:2::3;
route 2a00:7660:204::/48 next-hop 2a00:7660:0:2::4;
route 2a00:7660:205::/48 next-hop 2a00:7660:0:2::5;
route 2a00:7660:206::/48 next-hop 2a00:7660:0:2::6;
route 2a00:7660:207::/48 next-hop 2a00:7660:0:2::7;
route 2a00:7660:208::/48 next-hop 2a00:7660:0:2::8;
... and so on

Our DHCPv6 server is then programmed to assign 2a00:7660:0:2::2 to the same
CPE that will get 2a00:7660:202::/48. We also use static assignments based
on the DHCPv6 interface ID option, but this is not a requirement for using
the method.

Injecting the routes using BGP is not strictly necessary. You could use
static routes as well. Our routers have a limitation on how many static
routes are allowed, the routes fill up the config and it is error prone to
keep multiple routers in sync. For this reason I implemented route
injection using Exabgp instead and it works great.

We are not using a trigger on the DHCPv6 server. Instead the routes are
computed and injected well before the client connects to the network for
the first time. The method would also work well with a dynamically trigger
based approach.

Regards,

Baldur

7

We've build a small tool which watches the dhcpd6 lease file for
changes and injects the PD routes using exabgp (iBGP session with
corresponding IA_NA address as next-hop for the IA_PD prefix).

Best Regards,
Frederik Kriewitz

8

y'all might want to look over the work of the ietf homenet working
group for some insight into plans for dhcp-pd, and routing
interactions, in the home and small business, at least.

https://tools.ietf.org/wg/homenet/

some dhcpv6 specific info is spread around using the new hncp protocol.

blatant plug - https://github.com/sbyx/odhcp6c is now the best open
source dhcpv6 (and pd) client "out there" right now IMHO.
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

9

Thanks for all the replies.

The gist I get is that no real SOP/BCP has emerged yet for doing this,
and everyone is home-brewing their own methods.

One of the other reasons I ask is because I was experimenting with
Comcast Business IPv6. I was sent a cable modem that could do
dual-stack and did PD. But it seemed really broken. It would only
assign a /64, and never routed anything it assigned back to the head end
as far as I could see through the customer interface. I was told that
the firmware was broken.

- Jim

10

Quite a few years back I did the following experiment:

I had a Cisco 7200 router running some kind of not-too-old-code, which had a /48 routed to it. I then created a DHCPv6 PD pool of /56:es. I had 2 D-Link home gateways (DIR-655 I think) with some beta code I received from D-Link. I then hooked them up like this:

C7200-DIR1-DIR2-Computer

The C7200 would delegate a /56 to DIR1, who would then subdelegate a /64 out of that one to DIR2 who would assign that to its LAN interface so Computer could use SLAAC itself an address out of it. This worked fine.

I also tested C7200-WIN7PC-Computer (WIN7PC running Windows7) and turned on ICS (Internet connection sharing), and WIN7PC would get a /56, allocate a /64 to its "LAN" interface, and Computer worked just fine. I never tried hooking up another router behind it. I am not 100% sure it was running Windows7, it might even have been running Windows Vista.

So I'd say there is equipment out there that works, as expected, but as seen in this thread, plenty of equipment that doesn't.

11

hey,

So I'd say there is equipment out there that works, as expected, but as
seen in this thread, plenty of equipment that doesn't.

Latest OpenWrt releases include GitHub - sbyx/odhcpd: OpenWrt embedded DHCP(v6)/RA server as DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. subdelegate /64s from the /56 PD prefix you received from SP.

It's not the most configurable thing at this point but it does the job.

12

I would say how to handle it on the ISP network and how to do it in the
home/SOHO is two different problems and set of requirements. The enterprise
network might be a third case but is probably more like the ISP network.

Regards,

Baldur

13

If your SP is giving you a /56, you should complain and ask for a proper /48.

Especially if you’re doing any real hierarchical PD.

Owen

14

Or you just don't do heirarchial routing / PD inside the site. It isn't needed.
65000 intra site routes isn't that hard handle nor is 65000 PD's for the border
routers.

15

Yes, but to get to 65000 intrasite routes, you’ve got to already have that /48 I was
suggesting you ask for.

Owen

16

In message <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com>, Owen DeLong write
s:

>
>
>>
>>>
>>> hey,
>>>
>>>> So I'd say there is equipment out there that works, as expected, but
as
>>>> seen in this thread, plenty of equipment that doesn't.
>>>
>>> Latest OpenWrt releases include GitHub - sbyx/odhcpd: OpenWrt embedded DHCP(v6)/RA server as
>> DHCPv4/6 server. This enables hierarchical PD on these platforms, ie.
>> subdelegate /64s from the /56 PD prefix you received from SP.
>>>
>>> It's not the most configurable thing at this point but it does the
job.
>>
>> If your SP is giving you a /56, you should complain and ask for a
proper
>> /48.
>>
>> Especially if you’re doing any real hierarchical PD.
>>
>> Owen
>
> Or you just don't do heirarchial routing / PD inside the site. It
isn't needed.
> 65000 intra site routes isn't that hard handle nor is 65000 PD's for
the border
> routers.

Yes, but to get to 65000 intrasite routes, you’ve got to already have
that /48 I was
suggesting you ask for.

Owen

And a /56 gives you 256 subnets. When you remove unnecessary
heirachical delegation / routing that still supports a reasonable
sized home network.

A /48 would be better but getting the allocation working is the
first step. It's easy enough to make a /48 not work if you insist
on heirachical delegation.

Mark

17

If you have a *workable* solution for the case where you're handed a /56
and are running a second CeroWRT or OpenWRT to improve coverage at the
other end of the house that doesn't include hierarchical routing,
we'd love to hear it. Note that "workable" includes "Joe Sixpack must
have a reasonable chance of it working with minimum user configuration".

Aternatively, if you have a algorithm for hierarchical deployment that
doesn't burn through bits as fast, we'd love to hear it..

18

Aternatively, if you have a algorithm for hierarchical deployment that
doesn't burn through bits as fast, we'd love to hear it..

That will teach me to reply to stuff before reading *all* my e-mail (actually,
probably not).

Hot off the press today (now we just need to wait for code to ship):

19

If you have a *workable* solution for the case where you're handed a /56

and are running a second CeroWRT or OpenWRT to improve coverage at the other
end of the house that >doesn't include hierarchical routing, we'd love to
hear it. Note that "workable" includes "Joe Sixpack must have a reasonable
chance of it working with minimum user configuration".

Why wouldn't you just attach the second device via a LAN (versus the WAN)
port, and disabling it's DHCP/SLAAC? Or use a proper L2-only wireless
device like a range extender or an AP? If Joe Sixpack can't handle that, he
probably is going to fail at getting OpenWRT to work, or configuring static
IPv6 routes, or modifying windows firewall to allow his other subnets
access.

Chuck

20

In article <xs4all.85AC9398-125E-4078-86DA-63962DF76662@delong.com> you write:

Unfortunately, PD is really still in its infancy in terms of development
and real running code for complete implementations throughout any
sort of site hierarchy.

Well, it works for us. Connect a second router (Fritz!box) behind
the primary one and it works. We can't see how many customers
actually do that but potentially it could be hunderds of thousands,
so in practice it's still thousands or tens of thousands.

I'm always amused by people saying IPv6 is difficult or impossible
for various reasons and that real implementations of X and Y
do not exist while we've been doing it for years. Probably because
we didn't really know what we were getting into and simply started.
The only way progress is ever made, it seems :slight_smile:

Mike.