Re: How are you doing DHCPv6 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So back in 2012 there was some discussion on DHCPv6 and the challenge of using a DUID in a dual-stack environment where MAC-based assignments are already happening though an IPAM. Have a look at https://dhcpy6d.ifw-dresden.de, our MAC address aware DHCPv6 server. Uses neighbor cache to get the MACs. Might only work in smaller environments but does its job. Regards Henri - -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: +49 (3 51) 46 59 - 797 email: h.w...@ifw-dresden.de https://www.ifw-dresden.de Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Manfred Hennecke, Kaufmännische Direktorin i. V. Dipl.-Kffr. Friederike Jaeger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlUc8M4ACgkQnmb3Nh+6CUKSWwCaAqEcs4aywaaS8z4F5Ah6A0V/ aSIAn3WoD2dKEtlWrhdKdAS9UU9tMoPG =5OJu -END PGP SIGNATURE-
Re: How are you doing DHCPv6 ?
I've been trying to get an answer from Juniper on this for months. Most of the
responses have been something to the effect of I have no idea what you are
talking about.
I recently got an answer of Juniper has no plans to support that.
I am responsible for several small ISPs' networks, and if this was properly
supported, all of their customers would have native IPv6 long ago. It boggles
my mind that it took until 2013 for people to finally figure out that you need
to be able to identify a device that is requesting DHCP. It is even crazier
that hardware manufacturers don't seem to care.
thanks,
-Randy
- On Apr 1, 2015, at 8:06 PM, Ray Soucy r...@maine.edu wrote:
[ 3 year old thread ]
So back in 2012 there was some discussion on DHCPv6 and the challenge of
using a DUID in a dual-stack environment where MAC-based assignments are
already happening though an IPAM.
Update on this since then:
*RFC 6939 - Client Link-Layer Address Option in DHCPv6*
Pretty much exactly what I described in 2012 in terms of leveraging RFC
6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-)
I'd like to think my email back in 2012 influenced this, but I'm sure it
didn't. ;-)
*Support in ISC DHCP 4.3.1+*
https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html
Example to add logging for this in dhcpd.conf:
log (info, concat (Lease for , binary-to-ascii(16,16, :,
substring(suffix(option dhcp6.ia-na, 24),0,16)), client-linklayer-addr
,v6relay(1, (binary-to-ascii(16, 8, :, option
dhcp6.client-linklayer-addr);
To create static bindings based on it:
host hostname-1 {
host-identifier v6relopt 1 dhcp6.client-linklayer-addr
0:1:32:8b:36:ba:ed:ab;
fixed-address6 2001:db8:100::123;
};
[ These examples taken from Enno Rey, link follows ]
http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/
*Cisco Support?*
Apparently Cisco has started to support this in IOS-XE by default. I
haven't had a chance to verify this yet, but I did check IOS XR and IOS and
still don't see support for it.
Does anyone have details on what platforms and releases from Cisco support
RFC 6939 Option 79 so far? The only thing I can find online is reference
to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me.
On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy r...@maine.edu wrote:
The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree.
Currently, a DUID can be generated in 1 of 3 ways, 2 of which include
_any_ MAC address of the system at the time of generation. After
that, the DUID is stored in software.
The idea is that the DUID identifies the system and the IAID
identifies the interface, and that over time, the system will keep its
DUID even if the network adapter changes.
This is obviously different from how we use DHCP for legacy IP.
There are a few problems as a result:
1. Systems that are built using disk images can all have the same DUID
unless the admin takes care to remove any generated DUID on the image
(already see this on Windows 7 and even Linux).
2. Networks where the MAC addresses for systems are already known
can't simply build a DHCPv6 configuration based on those MACs.
If someone were to modify DHCPv6 to address these concerns, I think
the easiest way to do so would be to extend DHCPv6 relay messages to
include the MAC address of the system making the request (DHCPv6
servers on local sub-networks would be able to determine the MAC from
the packet). This would allow transitional DHCPv6 configurations to
be built on MAC addresses rather than DUID without client modification
(which is key).
Perhaps this is already possible through the use of RFC 6422 (which
shouldn't break anything).
I think more important, though, is a good DHCPv6 server implementation
with verbose logging capabilities, and the ability to specify a DUID,
DUID+IAID, or MAC for static assignments.
I know there are people from ISC on-list. It would be great to hear
someone who works on DHCPd chime in.
How about we start with modifying ISC DHCPd for IPv6 to have proper
logging and support for configuring IAID, then work on the MAC
awareness piece. ISC DHCPd makes use of RAW sockets, so it should
always have the MAC for a non-relayed request. Then we just need to
work with router vendors on adding MACs as a relay option.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
--
Ray Patrick Soucy
Network Engineer
University of Maine System
T: 207-561-3526
F: 207-561-3531
MaineREN, Maine's Research and Education Network
www.maineren.net
Re: How are you doing DHCPv6 ?
This reminds me that we have switches that will tag DHCPv6 packets with the equallent to option 82 however ISC-DHCP has no support for it. The switch will create a DHCP packet with two options, one being the user info and the other is encapsulating the original packet. ISC-DHCP will pick the encapsulated original packet and then ignore the user info from the outer packet, so it is useless. But if the most popular server is useless, how are people doing this? Regards Baldur
Re: How are you doing DHCPv6 ?
[ 3 year old thread ]
So back in 2012 there was some discussion on DHCPv6 and the challenge of
using a DUID in a dual-stack environment where MAC-based assignments are
already happening though an IPAM.
Update on this since then:
*RFC 6939 - Client Link-Layer Address Option in DHCPv6*
Pretty much exactly what I described in 2012 in terms of leveraging RFC
6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-)
I'd like to think my email back in 2012 influenced this, but I'm sure it
didn't. ;-)
*Support in ISC DHCP 4.3.1+*
https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html
Example to add logging for this in dhcpd.conf:
log (info, concat (Lease for , binary-to-ascii(16,16, :,
substring(suffix(option dhcp6.ia-na, 24),0,16)), client-linklayer-addr
,v6relay(1, (binary-to-ascii(16, 8, :, option
dhcp6.client-linklayer-addr);
To create static bindings based on it:
host hostname-1 {
host-identifier v6relopt 1 dhcp6.client-linklayer-addr
0:1:32:8b:36:ba:ed:ab;
fixed-address6 2001:db8:100::123;
};
[ These examples taken from Enno Rey, link follows ]
http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/
*Cisco Support?*
Apparently Cisco has started to support this in IOS-XE by default. I
haven't had a chance to verify this yet, but I did check IOS XR and IOS and
still don't see support for it.
Does anyone have details on what platforms and releases from Cisco support
RFC 6939 Option 79 so far? The only thing I can find online is reference
to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me.
On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy r...@maine.edu wrote:
The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree.
Currently, a DUID can be generated in 1 of 3 ways, 2 of which include
_any_ MAC address of the system at the time of generation. After
that, the DUID is stored in software.
The idea is that the DUID identifies the system and the IAID
identifies the interface, and that over time, the system will keep its
DUID even if the network adapter changes.
This is obviously different from how we use DHCP for legacy IP.
There are a few problems as a result:
1. Systems that are built using disk images can all have the same DUID
unless the admin takes care to remove any generated DUID on the image
(already see this on Windows 7 and even Linux).
2. Networks where the MAC addresses for systems are already known
can't simply build a DHCPv6 configuration based on those MACs.
If someone were to modify DHCPv6 to address these concerns, I think
the easiest way to do so would be to extend DHCPv6 relay messages to
include the MAC address of the system making the request (DHCPv6
servers on local sub-networks would be able to determine the MAC from
the packet). This would allow transitional DHCPv6 configurations to
be built on MAC addresses rather than DUID without client modification
(which is key).
Perhaps this is already possible through the use of RFC 6422 (which
shouldn't break anything).
I think more important, though, is a good DHCPv6 server implementation
with verbose logging capabilities, and the ability to specify a DUID,
DUID+IAID, or MAC for static assignments.
I know there are people from ISC on-list. It would be great to hear
someone who works on DHCPd chime in.
How about we start with modifying ISC DHCPd for IPv6 to have proper
logging and support for configuring IAID, then work on the MAC
awareness piece. ISC DHCPd makes use of RAW sockets, so it should
always have the MAC for a non-relayed request. Then we just need to
work with router vendors on adding MACs as a relay option.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
--
Ray Patrick Soucy
Network Engineer
University of Maine System
T: 207-561-3526
F: 207-561-3531
MaineREN, Maine's Research and Education Network
www.maineren.net
Re: How are you doing DHCPv6 ?
Hi Randy On Mon, 23 Jan 2012, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? There are several possible DUIDs exist: DUID-LLT, DUID-EN, DUID-LL - have a look at slide 36 and 37 at https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf or section 9. of RFC 3315: http://tools.ietf.org/html/rfc3315#section-9 You should use DUID type 3 which is tied to MAC address in case of Ethernet. So it is not random. You should warn your device vendors that they should use DUID-LL (or type 3) as a default - or should be able to preconfigure to use DUID-LL. In reality some vendors - due to some lazyness? - only implement DUID-LLT (or type 1) and sometimes does not store the first time value - therefore generated again and again - seemingly generating pseudo random DUID. However DUID-LLT has a structure: http://tools.ietf.org/html/rfc3315#section-9.1 Best Regards, Janos Mohacsi -Randy - Original Message - On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be. A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces. I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address-DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation. The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage. Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are. It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things. Regards, K. [1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof. [2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage. [2] No battle plan survives contact with the enemy - Helmuth von Moltke the Elder. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: How are you doing DHCPv6 ?
You shouldn't assume a MAC isn't constant. Our students spoof their MACs all the time (thinking it will save them from getting a DMCA notice). The RFC suggests that DUIDs are stored in non-volatile memory or that an algorithm be used that can consistently reproduce the DUID (and IAID) for a system in the absence of persistent storage. For fixed hardware devices, I suspect most would opt for the use of DUID-LL type, which essentially the MAC with a DUID preamble, and doesn't need to be stored in memory since it's based on a MAC that can not be changed. It would be simple to create a DUID sticker at that point, even retroactively. I think the idea that DUID is random and getting worked up that it's not written on the side of the device is a little more FUD than fact. There _are_ things we need to address to make DHCPv6 easier to roll out (mainly on the server side), but just making bogus nitpick attacks distracts from the real issues, IMHO. On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter rcar...@network1.net wrote: Controlled by software = not constant. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. -Randy - Original Message - Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
You shouldn't assume a MAC isn't constant should read is, double negative failure. On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy r...@maine.edu wrote: You shouldn't assume a MAC isn't constant. Our students spoof their MACs all the time (thinking it will save them from getting a DMCA notice). The RFC suggests that DUIDs are stored in non-volatile memory or that an algorithm be used that can consistently reproduce the DUID (and IAID) for a system in the absence of persistent storage. For fixed hardware devices, I suspect most would opt for the use of DUID-LL type, which essentially the MAC with a DUID preamble, and doesn't need to be stored in memory since it's based on a MAC that can not be changed. It would be simple to create a DUID sticker at that point, even retroactively. I think the idea that DUID is random and getting worked up that it's not written on the side of the device is a little more FUD than fact. There _are_ things we need to address to make DHCPv6 easier to roll out (mainly on the server side), but just making bogus nitpick attacks distracts from the real issues, IMHO. On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter rcar...@network1.net wrote: Controlled by software = not constant. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. -Randy - Original Message - Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
How are you doing DHCPv6 ?
Hello folks, I would like to chime in on this thread. I have great interest in how this plays out. The Jagornet DHCPv6 Server is capable of providing specific addresses to clients based upon DUID and IAID using a filtering mechanism supported in the configuration file. Of course, predicting what the DUID/IAID may be from various clients is still a challenge. However, if this information is available, the Jagornet DHCPv6 server can support this model. Also, specific binding reservations will soon be supported. Logging is rather extensive as well. The server is Certified IPv6 Phase II Ready. Furthermore, version 2.0 beta will be available soon, which will include support for DHCPv4! Please find the free, open-source version of the IPv6 Phase II Ready Jagornet DHCPv6 server here: http://code.google.com/p/jagornet-dhcpv6/ Best regards, Greg Rabil Jagornet Technologies, LLC.
Re: How are you doing DHCPv6 ?
I understand that MACs can be changed/spoofed. But that is the exception, not the rule. That isn't the biggest issue, though. The biggest issue is how to correlate the MAC and the DUID. That is the only way to properly authenticate and account for users that have both v4 and v6 (which is everyone) I don't care if their MAC changes, if that happens, they just need to reauthenticate. But, not having any way to know what their DUID is going to be, makes it impossible to also give them v6. -Randy - Original Message - You shouldn't assume a MAC isn't constant should read is, double negative failure. On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy r...@maine.edu wrote: You shouldn't assume a MAC isn't constant. Our students spoof their MACs all the time (thinking it will save them from getting a DMCA notice). The RFC suggests that DUIDs are stored in non-volatile memory or that an algorithm be used that can consistently reproduce the DUID (and IAID) for a system in the absence of persistent storage. For fixed hardware devices, I suspect most would opt for the use of DUID-LL type, which essentially the MAC with a DUID preamble, and doesn't need to be stored in memory since it's based on a MAC that can not be changed. It would be simple to create a DUID sticker at that point, even retroactively. I think the idea that DUID is random and getting worked up that it's not written on the side of the device is a little more FUD than fact. There _are_ things we need to address to make DHCPv6 easier to roll out (mainly on the server side), but just making bogus nitpick attacks distracts from the real issues, IMHO. On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter rcar...@network1.net wrote: Controlled by software = not constant. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. -Randy - Original Message - Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
As we're talking about the exception, not the rule I'll note that
the majority of systems generate their DUID based on the MAC address
of their adapter.
ISC DHCPd does in fact allow you to configure static assignments using
MAC and will match a DUID that was generated for that MAC.
Assuming the MAC of 01:23:45:67:89:ab, and a DUID of
00:03:00:01:01:23:45:67:89:ab
The ISC DHCPd configuration for a static host using a DUID:
8
host my-pc.example.com {
host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab;
fixed-address6 2001:db8:1:2::3;
}
8
For a MAC:
8
host my-pc.example.com {
host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab;
hardware ethernet 01:23:45:67:89:ab;
}
8
As with DHCPd for IPv4, you can make multiple entries to support both
the MAC and DUID method by using the option host-name directive for
additional entries:
8
host my-pc.example.com {
host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab;
fixed-address6 2001:db8:1:2::3;
}
host my-pc.example.com-1 {
option host-name my-pc.example.com;
hardware ethernet 01:23:45:67:89:ab;
fixed-address6 2001:db8:1:2::3;
}
8
Note that this is checking the MAC address used in DUID type 1 or type
3, not the actual MAC address of the system.
What we do right now (as a transition mechanism) in our IPAM is say
that if we see a DUID that is based on a known MAC, then it's probably
the same host, and add the association in the database.
Generating a DHCPv6 configuration file using the hardware ethernet
directive will get the majority of systems a v6 address in a dual
stack environment.
On a side note, DHCPv6 isn't the only place to address concerns.
Before DHCPv6 was an option, we implemented a system that polls
network routers and switches for ARP tables, IPv6 neighbor tables, and
MAC address tables, then throws the full association (IP, MAC, Device,
Port) into a MySQL database. Data is compressed into rows with first
seen and last seen timestamps to save on table sizes (along with
monthly rotation of tables). This provides us with the ability to see
what MAC had what IP (or IPv6) address and where it was connected.
Mainly for incident response. We also poll for IPv6 routers seen to
catch rogue RA, though that has mostly gone away since putting PACLs
in place to filter unauthorized RA.
This database allows us to make the association of IPv4 and IPv6, even
in a SLAAC environment; it also provides us with the history of that
association (and even logs link-local addresses).
When we disable a host, the database is checked so both IPv4 and IPv6
address can be disabled.
As far as DUID discovery, though. It would be nice if logging changes
previously mentioned were made to ISC DHCPd so we can see the DUIDs
attempting to get an address along with the MAC requesting it.
On Tue, Jan 24, 2012 at 11:18 AM, Randy Carpenter rcar...@network1.net wrote:
I understand that MACs can be changed/spoofed. But that is the exception, not
the rule.
That isn't the biggest issue, though. The biggest issue is how to correlate
the MAC and the DUID. That is the only way to properly authenticate and
account for users that have both v4 and v6 (which is everyone)
I don't care if their MAC changes, if that happens, they just need to
reauthenticate. But, not having any way to know what their DUID is going to
be, makes it impossible to also give them v6.
-Randy
- Original Message -
You shouldn't assume a MAC isn't constant should read is, double
negative failure.
On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy r...@maine.edu wrote:
You shouldn't assume a MAC isn't constant. Our students spoof
their
MACs all the time (thinking it will save them from getting a DMCA
notice).
The RFC suggests that DUIDs are stored in non-volatile memory or
that
an algorithm be used that can consistently reproduce the DUID (and
IAID) for a system in the absence of persistent storage.
For fixed hardware devices, I suspect most would opt for the use of
DUID-LL type, which essentially the MAC with a DUID preamble, and
doesn't need to be stored in memory since it's based on a MAC that
can
not be changed. It would be simple to create a DUID sticker at
that
point, even retroactively. I think the idea that DUID is random
and
getting worked up that it's not written on the side of the device
is a
little more FUD than fact.
There _are_ things we need to address to make DHCPv6 easier to roll
out (mainly on the server side), but just making bogus nitpick
attacks
distracts from the real issues, IMHO.
On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter
rcar...@network1.net wrote:
Controlled by software = not constant.
It is also not likely to be something that is knowable on a piece
of electronic gear that is not a PC, nor will it be something
that can be printed on the outside of the device, like most
Re: How are you doing DHCPv6 ?
This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. -Randy - Original Message - This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
In message CALFTrnMXzdoS=-B=wt1hvfgkvdrqzdz8konhopgu1joqxo9...@mail.gmail.com , Ray Soucy writes: This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). I can't see any request to add this feature to ISC DHCPv6 so I've opened 27564 request for duid+iaid as selection criteria If we don't know you need a feature we can't put it on the roadmap. For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote : I am wondering how people out there are using DHCPv6 to handle assigning pr efixes to end users. We have a requirement for it to be a redundant server that is centrally loc ated. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. How ever, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track o f users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why i t is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: How are you doing DHCPv6 ?
On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be. A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces. I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address-DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation. The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage. Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are. It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things. Regards, K. [1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof. [2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage. [2] No battle plan survives contact with the enemy - Helmuth von Moltke the Elder. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: How are you doing DHCPv6 ?
The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. Currently, a DUID can be generated in 1 of 3 ways, 2 of which include _any_ MAC address of the system at the time of generation. After that, the DUID is stored in software. The idea is that the DUID identifies the system and the IAID identifies the interface, and that over time, the system will keep its DUID even if the network adapter changes. This is obviously different from how we use DHCP for legacy IP. There are a few problems as a result: 1. Systems that are built using disk images can all have the same DUID unless the admin takes care to remove any generated DUID on the image (already see this on Windows 7 and even Linux). 2. Networks where the MAC addresses for systems are already known can’t simply build a DHCPv6 configuration based on those MACs. If someone were to modify DHCPv6 to address these concerns, I think the easiest way to do so would be to extend DHCPv6 relay messages to include the MAC address of the system making the request (DHCPv6 servers on local sub-networks would be able to determine the MAC from the packet). This would allow transitional DHCPv6 configurations to be built on MAC addresses rather than DUID without client modification (which is key). Perhaps this is already possible through the use of RFC 6422 (which shouldn’t break anything). I think more important, though, is a good DHCPv6 server implementation with verbose logging capabilities, and the ability to specify a DUID, DUID+IAID, or MAC for static assignments. I know there are people from ISC on-list. It would be great to hear someone who works on DHCPd chime in. How about we start with modifying ISC DHCPd for IPv6 to have proper logging and support for configuring IAID, then work on the MAC awareness piece. ISC DHCPd makes use of RAW sockets, so it should always have the MAC for a non-relayed request. Then we just need to work with router vendors on adding MACs as a relay option. On Mon, Jan 23, 2012 at 2:44 PM, Randy Carpenter rcar...@network1.net wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. -Randy - Original Message - This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist
Re: How are you doing DHCPv6 ?
One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? -Randy - Original Message - On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be. A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces. I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address-DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation. The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage. Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are. It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things. Regards, K. [1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof. [2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage. [2] No battle plan survives contact with the enemy - Helmuth von Moltke the Elder. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: How are you doing DHCPv6 ?
Thanks, Mark. The ISC website isn't very clear on how to make such requests unless you have a support contract. Also make note of my last response to the thread on logging and MAC awareness, as it may also be worth consideration. On Mon, Jan 23, 2012 at 5:05 PM, Mark Andrews ma...@isc.org wrote: In message CALFTrnMXzdoS=-B=wt1hvfgkvdrqzdz8konhopgu1joqxo9...@mail.gmail.com , Ray Soucy writes: This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). I can't see any request to add this feature to ISC DHCPv6 so I've opened 27564 request for duid+iaid as selection criteria If we don't know you need a feature we can't put it on the roadmap. For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote : I am wondering how people out there are using DHCPv6 to handle assigning pr efixes to end users. We have a requirement for it to be a redundant server that is centrally loc ated. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. How ever, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track o f users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why i t is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: How are you doing DHCPv6 ?
Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
Controlled by software = not constant. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. -Randy - Original Message - Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
On Mon, 2012-01-23 at 18:12 -0500, Randy Carpenter wrote: Controlled by software = not constant. OK - fair point. But these days many MACs can be controlled by software too. In the world of virtual computing they don't exist in hardware at all. The world hasn't ended. Examples abound of codes that are software controlled but long-lived. SSIDs and other access codes on commodity wifi routers, for example. Or licence numbers for some operating systems e.g., Windows. Written on the box, too. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. Well, that's not really true. There is nothing stopping OEMs shipping equipment with preconfigured DUIDs and printing those DUIDs on the side of the box or the bottom of the device or whatever. As to being knowable, well, neither is a MAC. Short of starting up a device and seeing what MAC it uses, there is no way to know ahead of time what MAC addresses a device has unless the manufacturer was kind enough to print them on the box. Don't get me wrong; I'm not trying to be an apologist for DUIDs. But I think we do need to see the problems clearly in order to solve them. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: How are you doing DHCPv6 ?
In message calftrnmr7uc4fxex0dacg0v-fcukvccumbg5etlexoj4hrp...@mail.gmail.com , Ray Soucy writes: Thanks, Mark. The ISC website isn't very clear on how to make such requests unless you have a support contract. For reference email to dhcp-sugg...@isc.org (or even dhcp-b...@isc.org) well get it logged. Also make note of my last response to the thread on logging and MAC awareness, as it may also be worth consideration. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: How are you doing DHCPv6 ?
Randy Carpenter rcar...@network1.net writes: DHCP is certainly not stateless, which is why there is a concept of leases, which are stored in a file. You can't have 2 servers answering for the same subnet without some sort of coordination, or you would have a potential for duplicate addresses being assigned. Duplicate assignments are not a problem as long as you ensure that the client is the same. I.e. if the prefix delegating DHCPv6 server serves a statically assigned prefix to an end user based on information *uniquely identifying that user*, then you can replicate that setup to as many completely independent DHCPv6 servers as you like. Different end users will still not receive duplicate assignments. But if you want the DHCPv6 server to dynamically allocate a new prefix to each client, then you are up for problems of course. Don't see why you would want to do that though. Redundant DHCPv6 will be only one of many problems in such a setup. Bjørn
Re: How are you doing DHCPv6 ?
On Sat, Jan 21, 2012 at 7:03 AM, Bjørn Mork bj...@mork.no wrote: Randy Carpenter rcar...@network1.net writes: Duplicate assignments are not a problem as long as you ensure that the client is the same. Duplicate assignments to different clients also won't be established if your standby server has access to an identical lease database at the moment your clustering software determines that the primary server has failed, kills the primary, and places the secondary in service. A sufficiently long lease duration should also be as good as a static lease, in that case. Because all the important details are in the database. You don't have to have any coordination in the DHCP software; you just in some cases, need to exclude the DHCPD daemon from simultaneously being active on multiple machines. -- -JH
Re: How are you doing DHCPv6 ?
Several people have mentioned clustering software. Does any one have any examples of such a thing that supports v4 and v6? We have always used the built in failover in ISC dhcpd, and it works nicely. I don't understand why they felt it would not be needed in v6. -Randy On Jan 21, 2012, at 12:31, Jimmy Hess mysi...@gmail.com wrote: On Sat, Jan 21, 2012 at 7:03 AM, Bjørn Mork bj...@mork.no wrote: Randy Carpenter rcar...@network1.net writes: Duplicate assignments are not a problem as long as you ensure that the client is the same. Duplicate assignments to different clients also won't be established if your standby server has access to an identical lease database at the moment your clustering software determines that the primary server has failed, kills the primary, and places the secondary in service. A sufficiently long lease duration should also be as good as a static lease, in that case. Because all the important details are in the database. You don't have to have any coordination in the DHCP software; you just in some cases, need to exclude the DHCPD daemon from simultaneously being active on multiple machines. -- -JH
Re: How are you doing DHCPv6 ?
On Sat, Jan 21, 2012 at 1:05 PM, Randy Carpenter rcar...@network1.netwrote: Several people have mentioned clustering software. Does any one have any examples of such a thing that supports v4 and v6? Linux-HA, RSF-1, Oracle Solaris Cluster, Veritas cluster, are a few examples of clustering software. ocf_heartbeat_anything + ocf_heartbeat_IPv6addr http://linux-ha.org/doc/man-pages/man-pages.html Obviously, building a DHCPD failover cluster involves some scripting and significant design considerations, but as far as clusters go, DNS and DHCPD failover clusters are very simple. And don't require special application support to achieve redundancy, unlike, say Firewalls, SQL, FTP, SMTP or HTTPD clusters, where a requirement may exist not to drop a single TCP connection, or fail a single query, in case of server failure. DHCPD doesn't even use TCP connections; and some amount of automatic retry by the client is a feature of the protocol. Database servers, HTTP, Firewalls, etc, are stateful services, because there is an in-flight status which is not recorded in a database, and must be preserved by the application itself for graceful failover. If the Firewall connection table is not synchronized online, the failover between clustered firewalls would cause a disruption in the form of lost TCP connections, and online users will experience an immediate temporary issue at the moment of failover. The same for HTTP... a TCP connection dropping is a permanent error. The in-flight transactions would result in the user seeing an error page. Those are the types of applications that actually require special support or coordination from the application itself. Graceful DHCPD failover to deal with server issues can be achieved by using one of the open source or commercial clustering packages, plus a little bit of scripting. -- -JH
Re: How are you doing DHCPv6 ?
Randy Carpenter rcar...@network1.net writes: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. OK, so then you've already made your choice. Another solution is having the DHCPv6 servers distributed while keeping the database centrally managed. This is the route the delegated prefix will travel: central MySQL master = local MySQL slave on each RADIUS server = RADIUS based per client provisioning = local DHCPv6 server running on each access router = DHCPv6 client on customer CPE This is about as redundant as it gets if you have multiple RADIUS servers in multiple sites. No need for any cooperation between the DHCPv6 servers to be fully redundant. The only assumption is that either will the client always connect to the same access router, or the prefix must move between the access routers the client uses. Whether this is a deaggregation problem for you or not depends on how those access routers can be grouped, if at all. But that problem is really unrelated to DHCPv6 Bjørn
Re: How are you doing DHCPv6 ?
On Tue, Jan 17, 2012 at 4:04 PM, Randy Carpenter rcar...@network1.netwrote: We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. [snip] When you say you require redundant DHCPD, what do you mean by that? The DHCP protocol is mostly stateless, aside from offers made, which are stored persistently in a database. Therefore, you can cluster the DHCPD daemon, without modifications to the ISC DHCPD software. There is no shortage of cluster management software that is up to the task of keeping a service active on an active node, and keeping the service inactive on a standby (or failed) node. Achieving redundancy against DHCPD failure is mostly a design and configuration question, not a matter of finding a DHCPD implementation that has redundancy. If by redundancy you mean active/active pair of servers, for load balancing rather than failover, that implies DHCP servers with non-overlapping pools to assign from, and is generally a much more complicated objective to achieve with DHCP whether v4 or v6. -- -JH
Re: How are you doing DHCPv6 ?
- Original Message - On Tue, Jan 17, 2012 at 4:04 PM, Randy Carpenter rcar...@network1.net wrote: We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. [snip] When you say you require redundant DHCPD, what do you mean by that? The DHCP protocol is mostly stateless, aside from offers made, which are stored persistently in a database. Therefore, you can cluster the DHCPD daemon, without modifications to the ISC DHCPD software. DHCP is certainly not stateless, which is why there is a concept of leases, which are stored in a file. You can't have 2 servers answering for the same subnet without some sort of coordination, or you would have a potential for duplicate addresses being assigned. There is no shortage of cluster management software that is up to the task of keeping a service active on an active node, and keeping the service inactive on a standby (or failed) node. Achieving redundancy against DHCPD failure is mostly a design and configuration question, not a matter of finding a DHCPD implementation that has redundancy. If by redundancy you mean active/active pair of servers, for load balancing rather than failover, that implies DHCP servers with non-overlapping pools to assign from, and is generally a much more complicated objective to achieve with DHCP whether v4 or v6. I mean for failover, not load balancing. The other issue we are encountering with IPv6 is that ISC DHCPD does not log very much at all for DHCPv6. Also, we have yet to find something reliable to identify a particular client. It looks the only thing that is sent is the link local address, which is randomized on windows machines. The MAC address does not appear to ever be sent. This makes it impossible to apply any policies based on client. -Randy
How are you doing DHCPv6 ?
I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1
Re: How are you doing DHCPv6 ?
Mikrotik Routeros - Original Message - From: Randy Carpenter rcar...@network1.net To: Nanog nanog@nanog.org Sent: Wednesday, January 18, 2012 12:04 AM Subject: How are you doing DHCPv6 ? I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 __ Information from ESET NOD32 Antivirus, version of virus signature database 6804 (20120117) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6804 (20120117) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
RE: How are you doing DHCPv6 ?
You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt Original Message From: Randy Carpenter rcar...@network1.net Sent: Tue, Jan 17, 2012 5:4 PM To: Nanog nanog@nanog.org CC: Subject: How are you doing DHCPv6 ? I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1
Re: How are you doing DHCPv6 ?
You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt That doesn't really help us if we want to deploy before that draft becomes a standard. Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers? -Randy Original Message From: Randy Carpenter rcar...@network1.net Sent: Tue, Jan 17, 2012 5:4 PM To: Nanog nanog@nanog.org CC: Subject: How are you doing DHCPv6 ? I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1
Re: How are you doing DHCPv6 ?
On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote: You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt That doesn't really help us if we want to deploy before that draft becomes a standard. Well, it more or less just presents options (workarounds for missing proper HA sync). Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers? Without specifying your requirements, that's hard to say. If you're looking for fully state-sync'ed DHCPv6 server HA, I'm not aware of any. Cisco unfortunately pushed that another year into the future for CNR, so we're resorting for now to the Split Prefixes model described in abovementioned draft, effectively halving our DHCPv6-PD pools and thus exacerbates the negative effects of RIPE's overly converservative policy (HD-Ratio 0.94) on IPv6 by effectively stealing one bit (half the address space) just for redundancy. :-( Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: How are you doing DHCPv6 ?
The good news is that doubling your IP address allocation requirements for v6 is far better than doubling v4... On Tue, Jan 17, 2012 at 4:37 PM, Daniel Roesen d...@cluenet.de wrote: On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote: You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt That doesn't really help us if we want to deploy before that draft becomes a standard. Well, it more or less just presents options (workarounds for missing proper HA sync). Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers? Without specifying your requirements, that's hard to say. If you're looking for fully state-sync'ed DHCPv6 server HA, I'm not aware of any. Cisco unfortunately pushed that another year into the future for CNR, so we're resorting for now to the Split Prefixes model described in abovementioned draft, effectively halving our DHCPv6-PD pools and thus exacerbates the negative effects of RIPE's overly converservative policy (HD-Ratio 0.94) on IPv6 by effectively stealing one bit (half the address space) just for redundancy. :-( Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: How are you doing DHCPv6 ?
The draft does help you, it is a BCP and does not specify a standard. It outlines some BCPs that are usable today. I believe I tested and verified that what I outlined works with the ISC DHCPv6 server. It also works with other DHCPv6 servers as well. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 1/17/12 6:19 PM, Randy Carpenter rcar...@network1.net wrote: You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt That doesn't really help us if we want to deploy before that draft becomes a standard. Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers? -Randy Original Message From: Randy Carpenter rcar...@network1.net Sent: Tue, Jan 17, 2012 5:4 PM To: Nanog nanog@nanog.org CC: Subject: How are you doing DHCPv6 ? I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1
Re: How are you doing DHCPv6 ?
On 1/17/12 6:37 PM, Daniel Roesen d...@cluenet.de wrote: On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote: You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt That doesn't really help us if we want to deploy before that draft becomes a standard. Well, it more or less just presents options (workarounds for missing proper HA sync). [jjmb] correct. FWIW the IETF dhcwg is currently working on DHCPv6 failover/redundancy. See here for the requirements: http://tools.ietf.org/html/draft-mrugalski-dhc-dhcpv6-failover-requirements -00 Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers? Without specifying your requirements, that's hard to say. If you're looking for fully state-sync'ed DHCPv6 server HA, I'm not aware of any. [jjmb] same here, I expect a specification would be required first. Cisco unfortunately pushed that another year into the future for CNR, so we're resorting for now to the Split Prefixes model described in abovementioned draft, effectively halving our DHCPv6-PD pools and thus exacerbates the negative effects of RIPE's overly converservative policy (HD-Ratio 0.94) on IPv6 by effectively stealing one bit (half the address space) just for redundancy. :-( [jjmb] we have to do what we have to do, the good news migration to a proper failover model should be straight forward. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: How are you doing DHCPv6 ?
- Original Message - On 1/17/12 6:37 PM, Daniel Roesen d...@cluenet.de wrote: On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote: You might want to give this a read: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt That doesn't really help us if we want to deploy before that draft becomes a standard. Well, it more or less just presents options (workarounds for missing proper HA sync). [jjmb] correct. FWIW the IETF dhcwg is currently working on DHCPv6 failover/redundancy. See here for the requirements: http://tools.ietf.org/html/draft-mrugalski-dhc-dhcpv6-failover-requirements -00 I already had the two documents up and got them mixed up when I was reading through them. I'll have to go over the link from John in detail, and see if it gives us some ways to work around the limitations in our situation. thanks, -Randy
Re: How are you doing DHCPv6 ?
On Wed, Jan 18, 2012 at 12:31:25AM +, Brzozowski, John wrote: Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers? Without specifying your requirements, that's hard to say. If you're looking for fully state-sync'ed DHCPv6 server HA, I'm not aware of any. [jjmb] same here, I expect a specification would be required first. Well, there's nothing preventing vendors to implement proprietary state synchronization schemes like they did for DHCPv4 too. I think that we need to wait for the standard is just a mere excuse. Revamping CI of the user interface is a much higher priority these days. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
