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
On Nov 20, 2015, at 13:35 , Jim Burwell <jimb@jsbc.cc> wrote:
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
On 2015-11-20 15:36, Owen DeLong wrote:
On Nov 20, 2015, at 13:35 , Jim Burwell <jimb@jsbc.cc> wrote:
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
On 2015-11-20 15:36, Owen DeLong wrote:
On Nov 20, 2015, at 13:35 , Jim Burwell <jimb@jsbc.cc> wrote:
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? 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
On 2015-11-20 15:36, Owen DeLong wrote:
On Nov 20, 2015, at 13:35 , Jim Burwell <jimb@jsbc.cc> wrote:
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
On 21 November 2015 at 02:27, Owen DeLong <owen@delong.com> wrote:
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.
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
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 :) Mike.
On Nov 24, 2015, at 11:27 , Miquel van Smoorenburg <mikevs@xs4all.net> wrote:
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 :)
Mike.
What size prefix are you delegating to those end users? Owen
On 24/11/15 22:47, Owen DeLong wrote:
On Nov 24, 2015, at 11:27 , Miquel van Smoorenburg <mikevs@xs4all.net> wrote: 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.
What size prefix are you delegating to those end users?
A /48. Mike.
On Nov 24, 2015, at 13:51 , Miquel van Smoorenburg <mikevs@xs4all.net> wrote:
On 24/11/15 22:47, Owen DeLong wrote:
On Nov 24, 2015, at 11:27 , Miquel van Smoorenburg <mikevs@xs4all.net> wrote: 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.
What size prefix are you delegating to those end users?
A /48.
Mike.
Exactly… This discussion wasn’t about can or can’t IPv6. The topic of hierarchy came up when someone mentioned getting a /56 from their provider and I pointed out that anyone receiving a /56 should contact their provider and request a proper /48. Owen
On Fri, Nov 20, 2015 at 01:35:55PM -0800, Jim Burwell wrote:
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: http://www.hezmatt.org/~mpalmer/blog/2014/11/20/multi-level-prefix-delegatio... (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
On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell <jimb@jsbc.cc> wrote:
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.
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
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 On Sat, Nov 21, 2015 at 11:13 AM, Frederik Kriewitz <frederik@kriewitz.eu> wrote:
On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell <jimb@jsbc.cc> wrote:
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.
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
On 2015-11-21 05:08, Dave Taht wrote:
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
On Sat, Nov 21, 2015 at 11:13 AM, Frederik Kriewitz <frederik@kriewitz.eu> wrote:
On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell <jimb@jsbc.cc> wrote:
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. 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 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
On Sat, 21 Nov 2015, Jim Burwell wrote:
The gist I get is that no real SOP/BCP has emerged yet for doing this, and everyone is home-brewing their own methods.
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
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 https://github.com/sbyx/odhcpd 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. -- tarko
On Nov 23, 2015, at 00:53 , Tarko Tikan <tarko@lanparty.ee> wrote:
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 https://github.com/sbyx/odhcpd 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
In message <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>, Owen DeLong writes:
On Nov 23, 2015, at 00:53 , Tarko Tikan <tarko@lanparty.ee> wrote:
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 https://github.com/sbyx/odhcpd 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Nov 23, 2015, at 12:27 , Mark Andrews <marka@isc.org> wrote:
In message <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>, Owen DeLong writes:
On Nov 23, 2015, at 00:53 , Tarko Tikan <tarko@lanparty.ee> wrote:
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 https://github.com/sbyx/odhcpd 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
In message <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com>, Owen DeLong write s:
On Nov 23, 2015, at 12:27 , Mark Andrews <marka@isc.org> wrote:
In message <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>, Owen DeLong writes:
On Nov 23, 2015, at 00:53 , Tarko Tikan <tarko@lanparty.ee> wrote:
hey,
So I'd say there is equipment out there that works, as expected, but
seen in this thread, plenty of equipment that doesn't.
Latest OpenWrt releases include https://github.com/sbyx/odhcpd 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
as 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, 24 Nov 2015 09:39:54 +1100, Mark Andrews said:
And a /56 gives you 256 subnets. When you remove unnecessary heirachical delegation / routing that still supports a reasonable sized home network.
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..
On Tue, 24 Nov 2015 11:47:06 -0500, Valdis.Kletnieks@vt.edu said:
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): Subject: RFC 7695 on Distributed Prefix Assignment Algorithm From: rfc-editor@rfc-editor.org Date: Tue, 24 Nov 2015 08:17:58 -0800 (PST) (11:17 EST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: homenet@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7695 Title: Distributed Prefix Assignment Algorithm Author: P. Pfister, B. Paterson, J. Arkko Status: Standards Track Stream: IETF Date: November 2015 Mailbox: pierre.pfister@darou.fr, paterson.b@gmail.com, jari.arkko@piuha.net Pages: 20 Characters: 46244 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-homenet-prefix-assignment-08.txt URL: https://www.rfc-editor.org/info/rfc7695 DOI: http://dx.doi.org/10.17487/RFC7695 This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated. This document is a product of the Home Networking Working Group of the IETF. This is now a Proposed Standard.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Valdis.Kletnieks@vt.edu Sent: Tuesday, November 24, 2015 11:47 AM To: Mark Andrews <marka@isc.org> Cc: nanog@nanog.org Subject: Re: DHCPv6 PD & Routing Questions
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
In message <42270.1448383626@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu writes:
--==_Exmh_1448383626_2779P Content-Type: text/plain; charset=us-ascii
On Tue, 24 Nov 2015 09:39:54 +1100, Mark Andrews said:
And a /56 gives you 256 subnets. When you remove unnecessary heirachical delegation / routing that still supports a reasonable sized home network.
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".
Give PD is designed to allow you to have multiple delegation requests from one router to the dhcp server (router) and manage them independently. Just request prefixes as you need them. If the dhcp server (router) doesn't have any available it just make a up stream request. Ultimately this will get to the border router and be fullfilled there flowing back through all the itermediate servers and depending upon how they are configured setting up routes. Alternatively the original requesting route injects a route for the delegated prefix into the IRP. This isn't rocket science. Just use your @#!Q$# brains when you build CPE routers. This isn't new. DHCP servers have got answers from upsteam DHCP servers for various IPv4 DHCP options (e.g. DNS servers). PD isn't conceptually different other than it is done on demand rather than in advance. Mark
Aternatively, if you have a algorithm for hierarchical deployment that doesn't burn through bits as fast, we'd love to hear it..
--==_Exmh_1448383626_2779P Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Exmh version 2.5 07/13/2001
iQIVAwUBVlSUigdmEQWDXROgAQLFHg/9EMTa5V0bocoBLFkA/JEZpkngRmU3wp3t xtTyCCi9f5HT2TkCfPB3ai4C+QTINgPP0aVKjw10toQ2uEaBFPe900z0DL2YDUYS ehN5ZHJzr2VdZoxbm1L5PMoib2UaLio8/WsGQgk2Jz6TCFoPe7hvGoV2qYnDmN0/ wOK8cxVZqa1DXlMssXW3cJmIH0m4r5u2onV1sdj34uveVi8kp7PcRyLeVdZ0Wcr7 Fji58QTJ4Iy/AqioWIpkQOB6coA3/UcHDT1clWIf9UP+vMv0Bc2OxUrTG0v6BDCl Si3Vg22yvyTkirjQWTlxMGhWoYO7Sz1QXQTan0ZT8QZEtOfbFNBg2GXux4iNTvXq g5ADYJD5WMb7y7Wk1hMjTCpoKwBUa04xh0RelfKF+gzhRAyRaEstC3O8hCOcbxEM yP1K4Cf/2+iNQVeeY5x2DoJwa5wlVfV81LtcKAVxBAUayLwFScepb0RbLIKB7Rlw aKqT2btXbR9cMyuNh0EmhaVVijNhwIHYwZw1PB6XVSivA8xaLpQf5T4H3Tyf9FGJ LGgF3/em92qaqu9UzwiBiFHLNM1KT+tdyhvg2gkvvGQxxPA/26cVkOhW5rP4f4LS 9Ov1gVeMQz6NMNC+2RkT4TUbyYj1HqH3zVIkiAsHVFfQ1wCmw9dx1B33x3pfGLhY 3eCaVb6CKY8= =pcXt -----END PGP SIGNATURE-----
--==_Exmh_1448383626_2779P-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 25 November 2015 at 00:36, Mark Andrews <marka@isc.org> wrote:
Give PD is designed to allow you to have multiple delegation requests from one router to the dhcp server (router) and manage them independently. Just request prefixes as you need them. If the dhcp server (router) doesn't have any available it just make a up stream request. Ultimately this will get to the border router and be fullfilled there flowing back through all the itermediate servers and depending upon how they are configured setting up routes. Alternatively the original requesting route injects a route for the delegated prefix into the IRP.
This isn't rocket science. Just use your @#!Q$# brains when you build CPE routers.
This isn't new. DHCP servers have got answers from upsteam DHCP servers for various IPv4 DHCP options (e.g. DNS servers). PD isn't conceptually different other than it is done on demand rather than in advance.
Mark
Too many details were left out. Without a RFC to guide implementations, you can have no expectations that a mix of CPE routers on your home network will behave in any particular way. DHCPv6-PD allows multiple PD requests. But did anyone actually implement that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*). DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48. If a CPE device gets a size hint of /48 from a downstream CPE router, it will be forced to ignore that hint and give out - what? A /49 because that is the closest to a /48 that is possible, if you only got a /48 yourself? A /56 because that is half the available bits for prefixes? A /60 because who needs more? A /52 because why would you connect more than 16 directly connected downstream routers? Nothing because it asked for a /48 and you couldn't give it that, so the request should be ignored (the last option works really poorly because the DHCPv6 spec has no way to signal "please ask again for less space"). If we go back to the point I marked with (*) above, then think about when should you take a size hint seriously enough to go and request more space from the upstream server? Usually you wouldn't. You would just ignore his size hint and give him less space than asked for. Really it is a mess. We have too many options and therefore you will not see a good working system from multiple vendors in this space as is. I am aware of the homenet working group, which seems to have taken a different approach to solve the issues. Regards, Baldur
In message <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com> , Baldur Norddahl writes:
On 25 November 2015 at 00:36, Mark Andrews <marka@isc.org> wrote:
Give PD is designed to allow you to have multiple delegation requests from one router to the dhcp server (router) and manage them independently. Just request prefixes as you need them. If the dhcp server (router) doesn't have any available it just make a up stream request. Ultimately this will get to the border router and be fullfilled there flowing back through all the itermediate servers and depending upon how they are configured setting up routes. Alternatively the original requesting route injects a route for the delegated prefix into the IRP.
This isn't rocket science. Just use your @#!Q$# brains when you build CPE routers.
This isn't new. DHCP servers have got answers from upsteam DHCP servers for various IPv4 DHCP options (e.g. DNS servers). PD isn't conceptually different other than it is done on demand rather than in advance.
Mark
Too many details were left out. Without a RFC to guide implementations, you can have no expectations that a mix of CPE routers on your home network will behave in any particular way.
Does any RFC state copy "DNS servers from upstream DHCP response"? (the answer is NO by the way). Not everything should require a RFC.
DHCPv6-PD allows multiple PD requests. But did anyone actually implement that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*).
Then none of the CPE vendors are worth their salt as product suppliers.
DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48.
It's a hint for the amount of space you need. What else would you put in there other than that value. If you get more than you need then there is no problem. If you get less than you need then you have a problem. I've got a CPE with 3 internal interfaces. I would expect it would ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if the /62 or /63 could not be met. It's not that hard to request what you need. If you even think about the issue for a couple of seconds which you did to compose this reply you would realise that asking for a /48 by default is stupid and doesn't meet the definition of the hint which is the amount of space you need.
If a CPE device gets a size hint of /48 from a downstream CPE router, it will be forced to ignore that hint and give out - what? A /49 because that is the closest to a /48 that is possible, if you only got a /48 yourself? A /56 because that is half the available bits for prefixes? A /60 because who needs more? A /52 because why would you connect more than 16 directly connected downstream routers? Nothing because it asked for a /48 and you couldn't give it that, so the request should be ignored (the last option works really poorly because the DHCPv6 spec has no way to signal "please ask again for less space").
Which demonstrates that with a little bit of thought *you* could work though the issue of making the hint be a /48.
If we go back to the point I marked with (*) above, then think about when should you take a size hint seriously enough to go and request more space from the upstream server? Usually you wouldn't. You would just ignore his size hint and give him less space than asked for.
No. You go and make a request from the upsteam. The worst they can do is deny it.
Really it is a mess. We have too many options and therefore you will not see a good working system from multiple vendors in this space as is.
I am aware of the homenet working group, which seems to have taken a different approach to solve the issues.
Regards,
Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 25 November 2015 at 02:32, Mark Andrews <marka@isc.org> wrote:
It's a hint for the amount of space you need. What else would you put in there other than that value. If you get more than you need then there is no problem. If you get less than you need then you have a problem.
I've got a CPE with 3 internal interfaces. I would expect it would ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if the /62 or /63 could not be met. It's not that hard to request what you need.
You might think that would be obvious, but exactly zero (0) commercial available CPEs has implemented it like that. THAT means that if you expect the community to do it like this, you do in fact need to write it in a RFC.
If you even think about the issue for a couple of seconds which you did to compose this reply you would realise that asking for a /48 by default is stupid and doesn't meet the definition of the hint which is the amount of space you need.
Where did you find a "definition of the hint"? The RFC only has two short sections about the size hint: "In a message sent by a requesting router to a delegating router, the values in the fields can be used to indicate the requesting router's preference for those values. The requesting router may send a value of zero to indicate no preference. A requesting router may set the IPv6 prefix field to zero and a given value in the prefix-length field to indicate a preference for the size of the prefix to be delegated." and "If the requesting router includes an IA_PD Prefix option in the IA_PD option in its Solicit message, the delegating router MAY choose to use the information in that option to select the prefix(es) or prefix size to be delegated to the requesting router." It might be stupid, but the majority of the implementers read the RFC without your insight. It is poorly worded, because there is no guidance. You can not expect everyone to figure it out by themselves, especially not if you want them to come to the same conclusion. In this case people did come to a conclusion, it was just not the one you wanted. That conclusion was something like this: Hmm what is my preference for prefix size? I read NANOG and the cool guys says a /48 is better than /56, so I think my preference should be /48. I will put in /48 in this field. The only other option anyone really considered was putting in zero.
If we go back to the point I marked with (*) above, then think about when
should you take a size hint seriously enough to go and request more space from the upstream server? Usually you wouldn't. You would just ignore his size hint and give him less space than asked for.
No. You go and make a request from the upsteam. The worst they can do is deny it.
That is overly complex and with nothing in a RFC, few to none would implement it. We do not like to spend time and money on features nobody else implements. a) receive a request (as a server), see that we have too little space to fulfill the size hint b) go to the upstream server (as a client) and ask for more space c) if we still have too little space, ignore the size hint and do some other unspecified other action d) step a-c are asynchronous (have to wait unspecified time from upstream server, before we can make our own reply). This could be a problem because a DHCP server would usually not be programmed in this way. Fact is just that the DHCPv6 client and the DHCPv6 server are usually two pieces of a CPE that do not work together. Might even be two pieces of software from different projects. Then it becomes very complex to get that kind of coordination between client and server. I am not saying that it is impossible to implement a sane system using the framework provided by DHCPv6-PD. But too much was left out. Companies are not going to fill in the blanks. It will not be done until there is consensus this is the right way to implement hierarchical CPEs in the home. Regards, Baldur
In message <CAPkb-7D8pS99DqzNpD1L1_+MunQ2iyfBq_H00YS551OJWFY69A@mail.gmail.com>, Baldur Norddahl writes:
On 25 November 2015 at 02:32, Mark Andrews <marka@isc.org> wrote:
It's a hint for the amount of space you need. What else would you put in there other than that value. If you get more than you need then there is no problem. If you get less than you need then you have a problem.
I've got a CPE with 3 internal interfaces. I would expect it would ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if the /62 or /63 could not be met. It's not that hard to request what you need.
You might think that would be obvious, but exactly zero (0) commercial available CPEs has implemented it like that.
THAT means that if you expect the community to do it like this, you do in fact need to write it in a RFC.
Or you could write it as you think it is needed.
If you even think about the issue for a couple of seconds which you did to compose this reply you would realise that asking for a /48 by default is stupid and doesn't meet the definition of the hint which is the amount of space you need.
Where did you find a "definition of the hint"?
The RFC only has two short sections about the size hint:
"In a message sent by a requesting router to a delegating router, the values in the fields can be used to indicate the requesting router's preference for those values. The requesting router may send a value of zero to indicate no preference. A requesting router may set the IPv6 prefix field to zero and a given value in the prefix-length field to indicate a preference for the size of the prefix to be delegated."
and
"If the requesting router includes an IA_PD Prefix option in the IA_PD option in its Solicit message, the delegating router MAY choose to use the information in that option to select the prefix(es) or prefix size to be delegated to the requesting router."
It might be stupid, but the majority of the implementers read the RFC without your insight. It is poorly worded, because there is no guidance. You can not expect everyone to figure it out by themselves, especially not if you want them to come to the same conclusion. In this case people did come to a conclusion, it was just not the one you wanted.
That conclusion was something like this: Hmm what is my preference for prefix size? I read NANOG and the cool guys says a /48 is better than /56, so I think my preference should be /48. I will put in /48 in this field. The only other option anyone really considered was putting in zero.
The cool guys tell the ISP's to hand out /48s. They don't say request a /48. There is a difference.
If we go back to the point I marked with (*) above, then think about when
should you take a size hint seriously enough to go and request more space from the upstream server? Usually you wouldn't. You would just ignore his size hint and give him less space than asked for.
No. You go and make a request from the upsteam. The worst they can do is deny it.
That is overly complex and with nothing in a RFC, few to none would implement it. We do not like to spend time and money on features nobody else implements.
Well write a RFC and implement it. Thats what I do when I find a I find something is missing or a problem and should be common to multiple implementations. Its not hard to do. If you leave to someone else it doesn't get addressed. Negative caching is a example of this. (RFC 2308) The DLV record is a example of this. (RFC 5074) The default local zones is a example of this. (RFC 6303) The EDNS EXPIRE option is a example of this. (RFC 7314) The EDNS COOKIE option is a example of this. (in last call) draft-ietf-dnsop-rfc6598-rfc6303-02 is yet another example (in last call) draft-andrews-dns-no-response-issue-12 (dnsop call for adoption at the moment) + others Most of my developement work is with nameservers but I occasionally fiddle on the DHCP side.
a) receive a request (as a server), see that we have too little space to fulfill the size hint b) go to the upstream server (as a client) and ask for more space c) if we still have too little space, ignore the size hint and do some other unspecified other action d) step a-c are asynchronous (have to wait unspecified time from upstream server, before we can make our own reply). This could be a problem because a DHCP server would usually not be programmed in this way.
Fact is just that the DHCPv6 client and the DHCPv6 server are usually two pieces of a CPE that do not work together. Might even be two pieces of software from different projects. Then it becomes very complex to get that kind of coordination between client and server.
They are usually seperate for in some classes of devices and integrated in others. If you are designing a DHCP server for a ISP you want it to be seperate. If you designing a DHCP client for a PC it or tablet it is seperate. If you are designing for a router you do a integated server/client (which by the what is what lots of CPE routers have).
I am not saying that it is impossible to implement a sane system using the framework provided by DHCPv6-PD. But too much was left out. Companies are not going to fill in the blanks. It will not be done until there is consensus this is the right way to implement hierarchical CPEs in the home.
DHCPv6-PD described the client/server iteraction necessary to get a prefix delegated. There are lots of reasons to requests a delegation. You are a border router. You are a interior router. You are running VM's and need addresses for them. You want multiple addresses and DHCP IA only gives you one. I'm sure someone else will figure out some other use for DHCPv6-PD soon enough. Homenet is looking at plugging together routers in ad-hoc networks without administators.
Regards,
Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 25 November 2015 at 06:23, Mark Andrews <marka@isc.org> wrote:
You might think that would be obvious, but exactly zero (0) commercial available CPEs has implemented it like that.
THAT means that if you expect the community to do it like this, you do in fact need to write it in a RFC.
Or you could write it as you think it is needed.
The homenet working group just published a RFC with a different solution. The size hint is garbage today because every client will put garbage in it and most servers will ignore it (including isc-dhcp IIRC). And likely it will stay that way forever. The homenet solution is different, but it reduces the need for a size hint. Regards, Baldur
On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
DHCPv6-PD allows multiple PD requests. But did anyone actually implement that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*).
DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48.
Or, worse, the ISP's DHCPv6 server honors the new request and issues the larger prefix, but refuses to route it. Ran into that myself when I replaced my home CPE router, and changed the prefix hint to ask for a /60 block (expanded from /64) at the same time. That made for a frustrating few days without IPv6 service, waiting for my original delegation to expire. (Tech support, of course, had no clue and blamed my router.) In retrospect I should have perhaps had my original CPE generate a DHCP release message for that prefix before disconnecting it. But I won't be the last person to fail to generate that. -Brian
In message <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>, Brian Knight writes:
On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
DHCPv6-PD allows multiple PD requests. But did anyone actually implement that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*).
DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48.
Or, worse, the ISP's DHCPv6 server honors the new request and issues the larger prefix, but refuses to route it. Ran into that myself when I replaced my home CPE router, and changed the prefix hint to ask for a /60 block (expanded from /64) at the same time. That made for a frustrating few days without IPv6 service, waiting for my original delegation to expire. (Tech support, of course, had no clue and blamed my router.)
In retrospect I should have perhaps had my original CPE generate a DHCP release message for that prefix before disconnecting it. But I won't be the last person to fail to generate that.
-Brian
Well the requesting router could announce the route. ISC's client has hooks that allow this to be done. That is, after all, how routing is designed to work. The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes. The DHCP relay could also have injected routes but that is a second class solution. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Well the requesting router could announce the route. ISC's client has hooks that allow this to be done. That is, after all, how routing is designed to work. The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes.
The DHCP relay could also have injected routes but that is a second class solution.
A CPE announcing the route is fine as long as the ISP controls the CPE. If the CPE is controled by the customer, then the ISP's problems are similar. They need to find a way to filter the CPE's announcement so that it can announce only the prefixes delegated to it. András
In message <20151126053449.GA22347@eik.bme.hu>, =?utf-8?B?SsOBS8OTIEFuZHLDoXM=?= writes:
Well the requesting router could announce the route. ISC's client has hooks that allow this to be done. That is, after all, how routing is designed to work. The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes.
The DHCP relay could also have injected routes but that is a second class solution.
A CPE announcing the route is fine as long as the ISP controls the CPE.
If the CPE is controled by the customer, then the ISP's problems are similar. They need to find a way to filter the CPE's announcement so that it can announce only the prefixes delegated to it.
András
Which is why I mentioned the DHCP relay. Somewhere back towards the beginnings of this thread there was a reference to a blog post that complained that they couldn't workout how to send a git pull request to us. I've forwarded that to our dhcp team. For future reference dhcp-bugs@isc.org or dhcp-suggest@isc.org would have been fine places to send the request. So to the bug reporting form on isc.org which lets you select if it is bug, suggestion or a security issue. There also the general contact form which would get to the dhcp team after being forwarded a couple of times. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews <marka@isc.org> writes:
The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes.
Not too sure about that. At least, that's not what we do. We run the DHCPv6 and DHCP servers on our BNGs (or BRAS or whatever the current buzzword for "access router" is). So the "servers" have full control of both DHCP/DHCPv6 and routing. The DHCP backend database may need to be centralised, but tunneling the DHCP protocol all they way through your network just to achieve that seems unnecessarily risky and error-prone. Moving the DHCP frontends as close as possible to the clients is a very simple way to make DHCP scalable and robust. If you feel you should have a DHCP server in more than one site for robustness, then you might as well do a fully distributed design. Going half-way, centralising everything and then dividing it on multiple datasenters is just ten times the trouble.. If you only do pool-based arbitrary address allocations, then you might not need a centralised database at all. Distribute your prefixes to the BNGs and let them manage the pools independently of each other.
The DHCP relay could also have injected routes but that is a second class solution.
DHCP relays *are* second class solutions :) Unfortunately they cannot always be avoided in the semi-L2-environments like ISP access networks often are. Bjørn
The DHCP relay could also have injected routes but that is a second class solution.
DHCP relays *are* second class solutions :) Unfortunately they cannot always be avoided in the semi-L2-environments like ISP access networks often are.
Each to his own, I guess. Some of us are using DHCP relay agents with no problems, and don't necessarily agree on the "second class solution" characterization. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Nov 25, 2015, at 15:59 , Mark Andrews <marka@isc.org> wrote:
In message <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>, Brian Knight writes:
On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
DHCPv6-PD allows multiple PD requests. But did anyone actually implement that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*).
DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48.
Or, worse, the ISP's DHCPv6 server honors the new request and issues the larger prefix, but refuses to route it. Ran into that myself when I replaced my home CPE router, and changed the prefix hint to ask for a /60 block (expanded from /64) at the same time. That made for a frustrating few days without IPv6 service, waiting for my original delegation to expire. (Tech support, of course, had no clue and blamed my router.)
In retrospect I should have perhaps had my original CPE generate a DHCP release message for that prefix before disconnecting it. But I won't be the last person to fail to generate that.
-Brian
Well the requesting router could announce the route. ISC's client has hooks that allow this to be done. That is, after all, how routing is designed to work. The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes.
Are you really suggesting that a residential ISP accept routes advertised from their customer’s CPE? Really? That’s about the most ridiculous thing I’ve heard on NANOG in a long time and that’s saying something.
The DHCP relay could also have injected routes but that is a second class solution.
Maybe, but in an ISP/Customer PD environment, it’s certainly preferable to what you consider a “first class” solution. Owen
In message <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>, Owen DeLong writes:
On Nov 25, 2015, at 15:59 , Mark Andrews <marka@isc.org> wrote:
In message <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>, Brian Knight writes:
On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
DHCPv6-PD allows multiple PD requests. But did anyone actually
implement
that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*).
DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48.
Or, worse, the ISP's DHCPv6 server honors the new request and issues the larger prefix, but refuses to route it. Ran into that myself when I replaced my home CPE router, and changed the prefix hint to ask for a /60 block (expanded from /64) at the same time. That made for a frustrating few days without IPv6 service, waiting for my original delegation to expire. (Tech support, of course, had no clue and blamed my router.)
In retrospect I should have perhaps had my original CPE generate a DHCP release message for that prefix before disconnecting it. But I won't be the last person to fail to generate that.
-Brian
Well the requesting router could announce the route. ISC's client has hooks that allow this to be done. That is, after all, how routing is designed to work. The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes.
Are you really suggesting that a residential ISP accept routes advertised from their customer’s CPE? Really?
PD is used internally as well as externally, and with a little bit of crypto to prove the assigned address belongs to them there really isn't a reason a CPE device couldn't announce a address to a ISP. It would also allow BCP38 filters to be built rather than using RFP which is only a approximate solution.
That’s about the most ridiculous thing I’ve heard on NANOG in a long time and that’s saying something.
The DHCP relay could also have injected routes but that is a second class solution.
Maybe, but in an ISP/Customer PD environment, it’s certainly preferable to what you consider a “first class” solution.
Actually it is still a second class solution. Have the CPE generate the routes and use information from the relay as a acceptance filter. That way the device that was delegated the prefix decides what it announced.
Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 6 December 2015 at 06:18, Mark Andrews <marka@isc.org> wrote:
Are you really suggesting that a residential ISP accept routes advertised from their customer’s CPE? Really?
PD is used internally as well as externally, and with a little bit of crypto to prove the assigned address belongs to them there really isn't a reason a CPE device couldn't announce a address to a ISP. It would also allow BCP38 filters to be built rather than using RFP which is only a approximate solution.
Do you envision that the CPE runs OSPFv3 or something else? Would that scale? I am not an OSPF expert, but thousands of CPEs in an OSPF domain does not sound like a sane thing. What is the advantage? The prefix has been assigned to the CPE. If the CPE does not advertise the prefix it just goes to the null route. What is the use case where you want a prefix assigned to a CPE but _not_ routed to the same CPE? I do agree that there is something missing here, but I prefer a solution that does not require the CPE to be changed. Regards, Baldur
On Dec 6, 2015, at 08:45 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 6 December 2015 at 06:18, Mark Andrews <marka@isc.org> wrote:
Are you really suggesting that a residential ISP accept routes advertised from their customer’s CPE? Really?
PD is used internally as well as externally, and with a little bit of crypto to prove the assigned address belongs to them there really isn't a reason a CPE device couldn't announce a address to a ISP. It would also allow BCP38 filters to be built rather than using RFP which is only a approximate solution.
Do you envision that the CPE runs OSPFv3 or something else? Would that scale? I am not an OSPF expert, but thousands of CPEs in an OSPF domain does not sound like a sane thing.
As an alternative worth considering, it could do this with BGP instead of OSPF. There’s nothing mythical or magical about BGP. A CPE autoconfiguring itself to advertise the prefix(es) it has received from upstream DHCPv6 server(s) to it’s neighbors is not rocket science. In fact, this would mean that the CPE could also accept a default route via the same BGP session and it could even be used to enable automatic failover for mulihomed dynamically addressed sites. Sure, this requires modifying the CPE, but not in a particularly huge way and it provides a much cleaner and more scaleable solution for the ISP side of the equation than OSPF. Most current implementations use RIPv2, but we all know just how icky that is.
What is the advantage? The prefix has been assigned to the CPE. If the CPE does not advertise the prefix it just goes to the null route. What is the use case where you want a prefix assigned to a CPE but _not_ routed to the same CPE?
_not_ routed is not the only consideration here. routed via alternative paths may be worthy of consideration. Owen
On Sun, Dec 06, 2015 at 02:20:36PM -0800, Owen DeLong wrote:
As an alternative worth considering, it could do this with BGP instead of OSPF.
There’s nothing mythical or magical about BGP. A CPE autoconfiguring itself to advertise the prefix(es) it has received from upstream DHCPv6 server(s) to it’s neighbors is not rocket science. In fact, this would mean that the CPE could also accept a default route via the same BGP session and it could even be used to enable automatic failover for mulihomed dynamically addressed sites.
Sure, this requires modifying the CPE, but not in a particularly huge way and it provides a much cleaner and more scaleable solution for the ISP side of the equation than OSPF.
Most current implementations use RIPv2, but we all know just how icky that is.
How do you secure that? Or do you just assume no one will announce someone else's prefix? (I can think of ways to secure it, of course, but none of the approaches for having the DHCP server configure some sort of prefix access control seem to me to be any better or easier than having the DCHP server configure a static route). This isn't a problem I face, but if it were, I think I'd solve it by having the DHCP server inject the route via BGP with an appropriate next-hop. -- Brett
On Dec 6, 2015, at 15:03 , Brett Frankenberger <rbf+nanog@panix.com> wrote:
On Sun, Dec 06, 2015 at 02:20:36PM -0800, Owen DeLong wrote:
As an alternative worth considering, it could do this with BGP instead of OSPF.
There’s nothing mythical or magical about BGP. A CPE autoconfiguring itself to advertise the prefix(es) it has received from upstream DHCPv6 server(s) to it’s neighbors is not rocket science. In fact, this would mean that the CPE could also accept a default route via the same BGP session and it could even be used to enable automatic failover for mulihomed dynamically addressed sites.
Sure, this requires modifying the CPE, but not in a particularly huge way and it provides a much cleaner and more scaleable solution for the ISP side of the equation than OSPF.
Most current implementations use RIPv2, but we all know just how icky that is.
How do you secure that? Or do you just assume no one will announce someone else's prefix? (I can think of ways to secure it, of course, but none of the approaches for having the DHCP server configure some sort of prefix access control seem to me to be any better or easier than having the DCHP server configure a static route).
This isn't a problem I face, but if it were, I think I'd solve it by having the DHCP server inject the route via BGP with an appropriate next-hop.
A perfectly valid alternative… However, lots of people seem determined to use a routing protocol from the CPE. Given that constraint, I was looking at the options available and trying to pick the most reasonable among them. Note: Your concern is equally applicable to RIPv2 and OSPF as it is to BGP. Owen
On 22 November 2015 at 00:27, Jim Burwell <jimb@jsbc.cc> wrote:
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.
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
participants (17)
-
Baldur Norddahl -
Bjørn Mork -
Brett Frankenberger -
Brian Knight -
Chuck Church -
Dave Taht -
Frederik Kriewitz -
Jim Burwell -
JÁKÓ András -
Mark Andrews -
Matt Palmer -
Mikael Abrahamsson -
Miquel van Smoorenburg -
Owen DeLong -
sthaug＠nethelp.no -
Tarko Tikan -
Valdis.Kletnieks＠vt.edu