We are in the process of setting up IPv6 on customer workstations. We unfortunately ran into an issue with DHCPv6.
Our problem is that we can't use ipv6 neighbor discovery route-advertisements between our routers and the DHCP servers (security issue) . Our windows guy states that he needs the m and o flags enabled (which are passed through IPv6 ND RA's) for his DHCP server to run auto discovery and propagate addresses and gateways to the workstations.
Do you have any suggestions, or know best practices for accomplishing this without sending route-advertisements?
We reviewed the SEND alternative, but generating crypto keys between that many interfaces is going to require a big time expense.
Running 6500's 12.2(33)SXJ7
Quote from: ristau5741 on February 03, 2016, 09:09:20 AM
We are in the process of setting up IPv6 on customer workstations. We unfortunately ran into an issue with DHCPv6.
Our problem is that we can't use ipv6 neighbor discovery route-advertisements between our routers and the DHCP servers (security issue) . Our windows guy states that he needs the m and o flags enabled (which are passed through IPv6 ND RA's) for his DHCP server to run auto discovery and propagate addresses and gateways to the workstations.
Do you have any suggestions, or know best practices for accomplishing this without sending route-advertisements?
We reviewed the SEND alternative, but generating crypto keys between that many interfaces is going to require a big time expense.
Running 6500's 12.2(33)SXJ7
interesting read
https://tools.ietf.org/html/rfc6104
Not knowing anything about Windows dhcpv6 server, it sounds like he has misunderstood a thing or two and are referring to how RA is used to hint clients of existing dhcpv6 servers via the m and o flag. I see no logical explanation why the server would require this.
So you can't configure a DHCPv6 relay agent like the following example config from an Arista box?:
interface Vlan10
ipv6 dhcp relay destination 2100:10::250
ipv6 address 2100:10::1/64
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
The managed config and other config flag tell the host to not use stateless autoconfig, but to use stateful config instead - at least that's my understanding.
Quote from: AspiringNetworker on February 03, 2016, 11:01:59 AM
So you can't configure a DHCPv6 relay agent like the following example config from an Arista box?:
interface Vlan10
ipv6 dhcp relay destination 2100:10::250
ipv6 address 2100:10::1/64
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
The managed config and other config flag tell the host to not use stateless autoconfig, but to use stateful config instead - at least that's my understanding.
You do, but that is towards the
clients. This server admin seems to think you need to run RA with those flags towards the
server from what I'm reading. Hence I think the guy have misunderstood something.
And for the sake of it; the flags are always
hints, they do not force the clients to do anything. The same way as you can enable a DHCPv6 client on a host without any flags being seen in the RAs at all. Also it's not mutually exclusive, sending RAs with the o-flag and also an onlink prefix with the a-flag set will cause the client to run both SLAAC and DHCPv6 if they have a DHCPv6 client. Then it's up to the OS to decide which one of the aquired IPs to use (IPv6 is built around having multiple IPs, or even subnets, per interface)
Hmmm... had to re-read a second time.
So just configure what I provided and say, "Okay, done." ?
This is the same requirement we have on the federal side for the DoD Unified Communications Approved Products List:
QuoteIP6-000490 [Required: R; Conditional: LS] If the product provides routing functions, then the
product shall default to using the "managed address configuration" flag and the "other stateful
flag" set to TRUE in their router advertisements when stateful autoconfiguration is implemented
Your switch will "hint" the clients to use stateful autoconfig, and forward the DHCPv6 request on to the DHCPv6 server.
Still that has nothing to do with the server side.
Quote from: srg on February 03, 2016, 12:18:43 PM
Still that has nothing to do with the server side.
I agree with you - but I don't think that's exactly what's being asked for here, unless I'm miss-reading... which after a third time... maybe I am...
Ristau - is he saying he needs the flags sent to the workstation, or to the server?
Either you or me are misunderstanding this :)
Quote from: AspiringNetworker on February 03, 2016, 01:09:28 PM
Quote from: srg on February 03, 2016, 12:18:43 PM
Still that has nothing to do with the server side.
I agree with you - but I don't think that's exactly what's being asked for here, unless I'm miss-reading... which after a third time... maybe I am...
Ristau - is he saying he needs the flags sent to the workstation, or to the server?
from what I understand the server need to see the flags to know what to send to the workstations, ( not necessarily the workstation but the router forwarding the request, who in turn forwards to the workstations)
I can see if the other way, that the server sends the flags to the workstation to let it know how to address, either via auto configuration or via a DHCP address.
This is all third hand anyway, just posting for a buddy of mine, to help him out... so I'm nut sure exactly what is going on.... other than the few minutes searching on flags and reading the referenced RFC, and a few blogs on the subject.
Quote from: ristau5741 on February 03, 2016, 02:49:23 PM
Quote from: AspiringNetworker on February 03, 2016, 01:09:28 PM
Quote from: srg on February 03, 2016, 12:18:43 PM
Still that has nothing to do with the server side.
I agree with you - but I don't think that's exactly what's being asked for here, unless I'm miss-reading... which after a third time... maybe I am...
Ristau - is he saying he needs the flags sent to the workstation, or to the server?
from what I understand the server need to see the flags to know what to send to the workstations, ( not necessarily the workstation but the router forwarding the request, who in turn forwards to the workstations)
I can see if the other way, that the server sends the flags to the workstation to let it know how to address, either via auto configuration or via a DHCP address.
This is all third hand anyway, just posting for a buddy of mine, to help him out... so I'm nut sure exactly what is going on.... other than the few minutes searching on flags and reading the referenced RFC, and a few blogs on the subject.
He has totally misunderstood the concepts of RA, SLAAC and DHCPv6. He's not completely insane for not wanting RAs on the server subnet, but just configure the DHCPv6 server with a static IPv6 and gateway. The RA flags will only be significant to the workstations.
Yeah I find this a little hard to believe. His server should be statically configured.... this MUST be for the workstations...
http://www.tcpipguide.com/free/t_ICMPv6RouterAdvertisementandRouterSolicitationMess.htm (http://www.tcpipguide.com/free/t_ICMPv6RouterAdvertisementandRouterSolicitationMess.htm)
Maybe I'm reading too far into it and the admin thinks those flags have to be sent.. uh.. by the hosts..? (Which don't send RAs to my knowledge) In order for the DHCPv6 server to .. uh... discover and then send them an offer? Lol makes no sense.
Quote from: AspiringNetworker on February 03, 2016, 06:14:14 PM
Yeah I find this a little hard to believe. His server should be statically configured.... this MUST be for the workstations...
http://www.tcpipguide.com/free/t_ICMPv6RouterAdvertisementandRouterSolicitationMess.htm (http://www.tcpipguide.com/free/t_ICMPv6RouterAdvertisementandRouterSolicitationMess.htm)
Maybe I'm reading too far into it and the admin thinks those flags have to be sent.. uh.. by the hosts..? (Which don't send RAs to my knowledge) In order for the DHCPv6 server to .. uh... discover and then send them an offer? Lol makes no sense.
near as I can tell, today.
The host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag 0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server as in this case) along with an ip, default gateway and other goodies.
according to this goodie here
http://community.arubanetworks.com/t5/Controller-Based-WLANs/Explain-the-M-and-O-bit-in-IPv6-DHCP-server-configuration-What/ta-p/177442
The Router must include set M and O Bits in the RA it is sending out
so I suppose there is some way to set this in the router.
Yes - with the config I provided earlier. I assume there's something similar on the Cisco side, but again - those RAs should be going to the workstations - not the server.
Quote from: ristau5741 on February 04, 2016, 11:14:42 AMThe host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag 0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server as in this case) along with an ip, default gateway and other goodies.
Not quite. It's more like this, chronologically;
1, IPv6 enabled host sits on its subnet. Not knowing there are any routers on the subnet it sends out an RS (Router Solicitation).
2. A router on the subnet will respond with an RA (Router Advertisement. These also comes unsolicited at configured times). The RA will include the prefix(or prefixes) on the link, along with some additional flags; of special interest are the M and O flags. With both set to 0, or unset, the host will automatically generate its IPv6 via the function called SLAAC. DHCPv6 is not necessarily (see 4 below) used here.
Here you have a fully functioning IPv6 host.
But this can also happen:
3. If the M and O flags are 1/set, this will hint to the host that there are a DHCPv6 server available for address assignment (M-flag) or other option assignment (O). (SLAAC are still performed, the host will end up with multiple IPv6s)
Depending on your OS, this can also happen:
4, The hosts OS is manually configured with DHCPv6, and will send a DHCPv6 SOLICIT regardless of the O/M-flags in the RA. The flags are only
hints, they do not really enable or disable any behavior.
All this is for client/workstation assignment. The DHCPv6 server itself needs nothing of this and can be configured with a static IPv6 IP and GW as a IPv4 host. So the whole RA with this and that flag to the
server is not needed.
In IOS the flags are configured under the interface:
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
Quote from: srg on February 04, 2016, 01:08:13 PM
Quote from: ristau5741 on February 04, 2016, 11:14:42 AMThe host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag 0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server as in this case) along with an ip, default gateway and other goodies.
Not quite. It's more like this, chronologically;
1, IPv6 enabled host sits on its subnet. Not knowing there are any routers on the subnet it sends out an RS (Router Solicitation).
2. A router on the subnet will respond with an RA (Router Advertisement. These also comes unsolicited at configured times). The RA will include the prefix(or prefixes) on the link, along with some additional flags; of special interest are the M and O flags. With both set to 0, or unset, the host will automatically generate its IPv6 via the function called SLAAC. DHCPv6 is not necessarily (see 4 below) used here.
Here you have a fully functioning IPv6 host.
I need to get back into this, or the IPv6 forum will revoke my certification.
been a while.
Quote from: ristau5741 on February 04, 2016, 02:18:35 PM
Quote from: srg on February 04, 2016, 01:08:13 PM
Quote from: ristau5741 on February 04, 2016, 11:14:42 AMThe host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag 0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server as in this case) along with an ip, default gateway and other goodies.
Not quite. It's more like this, chronologically;
1, IPv6 enabled host sits on its subnet. Not knowing there are any routers on the subnet it sends out an RS (Router Solicitation).
2. A router on the subnet will respond with an RA (Router Advertisement. These also comes unsolicited at configured times). The RA will include the prefix(or prefixes) on the link, along with some additional flags; of special interest are the M and O flags. With both set to 0, or unset, the host will automatically generate its IPv6 via the function called SLAAC. DHCPv6 is not necessarily (see 4 below) used here.
Here you have a fully functioning IPv6 host.
I need to get back into this, or the IPv6 forum will revoke my certification.
been a while.
C:-)
Quote from: srg on February 04, 2016, 01:08:13 PM
Quote from: ristau5741 on February 04, 2016, 11:14:42 AMThe host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag 0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server as in this case) along with an ip, default gateway and other goodies.
Not quite. It's more like this, chronologically;
1, IPv6 enabled host sits on its subnet. Not knowing there are any routers on the subnet it sends out an RS (Router Solicitation).
2. A router on the subnet will respond with an RA (Router Advertisement. These also comes unsolicited at configured times). The RA will include the prefix(or prefixes) on the link, along with some additional flags; of special interest are the M and O flags. With both set to 0, or unset, the host will automatically generate its IPv6 via the function called SLAAC. DHCPv6 is not necessarily (see 4 below) used here.
Here you have a fully functioning IPv6 host.
But this can also happen:
3. If the M and O flags are 1/set, this will hint to the host that there are a DHCPv6 server available for address assignment (M-flag) or other option assignment (O). (SLAAC are still performed, the host will end up with multiple IPv6s)
Depending on your OS, this can also happen:
4, The hosts OS is manually configured with DHCPv6, and will send a DHCPv6 SOLICIT regardless of the O/M-flags in the RA. The flags are only hints, they do not really enable or disable any behavior.
All this is for client/workstation assignment. The DHCPv6 server itself needs nothing of this and can be configured with a static IPv6 IP and GW as a IPv4 host. So the whole RA with this and that flag to the server is not needed.
In IOS the flags are configured under the interface:
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
Have found that although as you say the M and O flags are just hints, you can enforce a DHCPv6-only environment by stopping the router advertising a prefix in its RA. The command "ipv6 nd prefix X:X:X:X::X/<0-128> no-advertise" will stop any SLAAC clients being able to autoconfigure an address, so only clients supporting DHCPv6 will get connectivity.
Quote from: aceandy79 on April 06, 2017, 03:47:31 AM
Quote from: srg on February 04, 2016, 01:08:13 PM
Quote from: ristau5741 on February 04, 2016, 11:14:42 AMThe host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag 0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server as in this case) along with an ip, default gateway and other goodies.
Not quite. It's more like this, chronologically;
1, IPv6 enabled host sits on its subnet. Not knowing there are any routers on the subnet it sends out an RS (Router Solicitation).
2. A router on the subnet will respond with an RA (Router Advertisement. These also comes unsolicited at configured times). The RA will include the prefix(or prefixes) on the link, along with some additional flags; of special interest are the M and O flags. With both set to 0, or unset, the host will automatically generate its IPv6 via the function called SLAAC. DHCPv6 is not necessarily (see 4 below) used here.
Here you have a fully functioning IPv6 host.
But this can also happen:
3. If the M and O flags are 1/set, this will hint to the host that there are a DHCPv6 server available for address assignment (M-flag) or other option assignment (O). (SLAAC are still performed, the host will end up with multiple IPv6s)
Depending on your OS, this can also happen:
4, The hosts OS is manually configured with DHCPv6, and will send a DHCPv6 SOLICIT regardless of the O/M-flags in the RA. The flags are only hints, they do not really enable or disable any behavior.
All this is for client/workstation assignment. The DHCPv6 server itself needs nothing of this and can be configured with a static IPv6 IP and GW as a IPv4 host. So the whole RA with this and that flag to the server is not needed.
In IOS the flags are configured under the interface:
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
Have found that although as you say the M and O flags are just hints, you can enforce a DHCPv6-only environment by stopping the router advertising a prefix in its RA. The command "ipv6 nd prefix X:X:X:X::X/<0-128> no-advertise" will stop any SLAAC clients being able to autoconfigure an address, so only clients supporting DHCPv6 will get connectivity.
Yep, what that also does is provide no on link prefix information to the clients, so they cannot find eachother via ND, all their communication will go through the router. Sometimes this is the intended design.
There's also the option to send the prefix on link info without the A flag, that should prevent clients from using the prefix for SLAAC autoconfig but still allowing on link info. But then there's also of course the possibility of clients not honoring this and doing autoconfig regardless, since the info is there.
Sent from my E6653 using Tapatalk
Thanks for the extra info srg. Have tried that setup instead (advertising a prefix but with 'no auto-config' set). Windows and Linux both seem to honour it and are still going to DHCPv6 server for address.
Just a question though, even if there were no prefix being advertised, wouldn't local clients communicate with each other using link-local addresses anyway? And would be able to do that directly without the help of the router?