On the test windows 7 machine I found that if the VLAN SVI on that network is sending RA's, then the Win7 machine doesn't contact the DHCP server...
-- The result is no DNS information and autoconfigured IP.
The Windows DHCP server can't configure the default gateway. So with RA's suppressed:
-- the result with DHCPv6 is no default gateway but nice IP and DNS info.
I thought both were supposed to work alongside each other (that's what I've found according to online posts).
Anyone deployed this? If so what way do you have it working? Simply RA or with DHCP as well?
there should be a RA flag that 'suggests' contacting a DHCP server for other options such as DNS. Yes its a suggestion, according to the RFC.
https://tools.ietf.org/html/rfc6106#section-4 (https://tools.ietf.org/html/rfc6106#section-4)
http://blog.ipspace.net/2012/11/ipv6-router-advertisements-deep-dive.html (http://blog.ipspace.net/2012/11/ipv6-router-advertisements-deep-dive.html)
I'm pretty sure there is a newer RFC that allows RA to also send DNS info (what moron in their IETF ivory tower thought it was a good idea to not do this in the first place.... but I digress), but I'm not clear on the compliance of host OSes (or what IOS lets you do this for that matter). Sorry don't have much production IPv6 XP.
Yeah, you need to set the other-config flag or something along that line for it to request DNS settings
I can confirm a recent Checkpoint Gaia OS will send out RAs with DNS, confirmed by packet capture. However, I don't know any OS capable of picking this up.
RA has to have the M bit set, which includes to O bit by default, the M bit allows the client to use DHCPv6, and the O bit refers other server information such as being DNS related, and the DHCPv6 server should send the IP and the DNS settings
Sending RDNSS in RA is defined in https://tools.ietf.org/html/rfc6106
OS support for this is picking up and they also discuss RA RDNSS and DHCPv6 DNS coexistence in that rfc.
Thanks all, I needed the managed config flag as you all say. It was confusing as sometimes DHCP would be used and sometimes SLAAC would be used and I wasn't sure why it was inconsistent.
The next confusing thing is that a Windows machine with a static IP address, still takes a DHCPv6 address as well. I'm not sure how to turn this off yet but reading a online blog it said in there that someone deployed IPv6 for multiple sites in a day and one of the steps was to disable the dhcpv6 client in the Windows server. I'll look into it.
In addition, a Windows machine which is dynamic IP ends up with IPv6 address from DHCP and 2 x SLAAC addresses (one from each upstream gateway).
RFC (https://tools.ietf.org/html/rfc4294#section-4.5) says SLAAC must be supported.
Quote
4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
This specification MUST be supported for nodes that are hosts.
Static address can be supported as well.
Nodes that are routers MUST be able to generate link local addresses
as described in RFC 2462 [RFC-2462].
So am I to take the above that SLAAC cannot be inhibited in any way, and that my end devices are expected to end up with 3x IPv6 addresses (with 2 upstream routers and DHCPv6)?
I can also take the above to mean that the end devices must "support" it and that's it.
You can disable SLAAC on Windows machines from the CLI:
netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
Also try this (https://nmap.org/nsedoc/scripts/ipv6-ra-flood.html), just for laughs :)
Quote from: Dieselboy on May 19, 2016, 04:52:10 AM
Thanks all, I needed the managed config flag as you all say. It was confusing as sometimes DHCP would be used and sometimes SLAAC would be used and I wasn't sure why it was inconsistent.
The next confusing thing is that a Windows machine with a static IP address, still takes a DHCPv6 address as well. I'm not sure how to turn this off yet but reading a online blog it said in there that someone deployed IPv6 for multiple sites in a day and one of the steps was to disable the dhcpv6 client in the Windows server. I'll look into it.
In addition, a Windows machine which is dynamic IP ends up with IPv6 address from DHCP and 2 x SLAAC addresses (one from each upstream gateway).
RFC (https://tools.ietf.org/html/rfc4294#section-4.5) says SLAAC must be supported.
Quote
4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
This specification MUST be supported for nodes that are hosts.
Static address can be supported as well.
Nodes that are routers MUST be able to generate link local addresses
as described in RFC 2462 [RFC-2462].
So am I to take the above that SLAAC cannot be inhibited in any way, and that my end devices are expected to end up with 3x IPv6 addresses (with 2 upstream routers and DHCPv6)?
I can also take the above to mean that the end devices must "support" it and that's it.
Link Local addresses are not SLAAC addresses, completely different animal. I don't think IPv6 would work very well without Link Local addresses.
Quote from: Dieselboy on May 19, 2016, 04:52:10 AMSo am I to take the above that SLAAC cannot be inhibited in any way, and that my end devices are expected to end up with 3x IPv6 addresses (with 2 upstream routers and DHCPv6)?
No SLAAC can be avoided, you will of course always end up with one link-local address per interface.
In the RA message the prefix contains a couple of flags, wheras the A flag indicates if the host is allowed to use the prefix for SLAAC, and this can be cleared.
Additionally you don't even have to signal a prefix in the RA, it can be used to only signal a present router, but that's probably a more obscure way seen in maybe vlan-per-customer subscriber scenarios, since this inherently also disables the on-link determination. This can also be done on a per-prefix basis with the L flag.
IPv6 neighbor discovery gives you a lot of choices and possible scenarios in this with all the flag variations.
https://tools.ietf.org/html/rfc4861#section-4.6.2
Quote from: ristau5741 on May 19, 2016, 08:04:46 AM
Link Local addresses are not SLAAC addresses, completely different animal. I don't think IPv6 would work very well without Link Local addresses.
Oops my bad - didn't read it properly. Thanks.
Quote from: SimonV on May 19, 2016, 05:59:05 AM
You can disable SLAAC on Windows machines from the CLI:
netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
Also try this (https://nmap.org/nsedoc/scripts/ipv6-ra-flood.html), just for laughs :)
:problem?: :problem?:
Quote from: srg on May 19, 2016, 03:54:22 PM
No SLAAC can be avoided, you will of course always end up with one link-local address per interface.
In the RA message the prefix contains a couple of flags, wheras the A flag indicates if the host is allowed to use the prefix for SLAAC, and this can be cleared.
Additionally you don't even have to signal a prefix in the RA, it can be used to only signal a present router, but that's probably a more obscure way seen in maybe vlan-per-customer subscriber scenarios, since this inherently also disables the on-link determination. This can also be done on a per-prefix basis with the L flag.
IPv6 neighbor discovery gives you a lot of choices and possible scenarios in this with all the flag variations.
https://tools.ietf.org/html/rfc4861#section-4.6.2
Link-local is understood. Apparently the flags managed config and other config are just suggestions to the client that it can use them. It doesn't say to the client it must use them.
I have tested ipv6 nd prefix xxxxx/64 no-advertise - Wireshark then shows the RA messages then come without that prefix part. That part contained the prefix flags and so they're missing too. So shouldn't this break / prevent SLAAC entirely?
EDIT - yes it does. After going into the network adapter and disabling ipv6 and then re-enabling, now I only get a DHCPv6 IP address (including DNS) and the RA gives me default gateway.
Quote from: Dieselboy on May 19, 2016, 10:43:58 PMLink-local is understood. Apparently the flags managed config and other config are just suggestions to the client that it can use them. It doesn't say to the client it must use them.
Yes that is true, this might be academic problem though.. have you come across a client that does not follow the suggestions? No-advertise I guess would be the only way to be sure though...
Quote from: Dieselboy
I have tested ipv6 nd prefix xxxxx/64 no-advertise - Wireshark then shows the RA messages then come without that prefix part. That part contained the prefix flags and so they're missing too. So shouldn't this break / prevent SLAAC entirely?
EDIT - yes it does. After going into the network adapter and disabling ipv6 and then re-enabling, now I only get a DHCPv6 IP address (including DNS) and the RA gives me default gateway.
...since you don't have the RA informing you of on-link prefixes, how does client-to-client traffic work in this scenario if you're on a shared L2 domain? Does the client use DHCPv6 prefix info for on-link determination?
DNS for the global IP address. This got me thinking so I ran a wireshark capture to see what happens. If I ping another client on the same L2 segment, because there's no arp or local prefix learning the following happens:
1. new client joins LAN
2. SLAAC prevented since RA does not include a prefix
3. RA provides client with HSRP virtual default gateway
4. DHCPv6 goes ahead, client obtains dns, dhcpv6 IP, search domain and updates dynamic DNS with the IP info
5. client now has working IPv6 access
client 1 needs to connect to client 2::
1. client 1 attempts to connect to client 2's FQDN
2. client 1 nslookup for client 2 name, returns ipv6 and ipv4 addresses
3. client 1 connects to client 2's global IP on the same L2 LAN
4. client 1 sends a packet to client 2 formed like:
ipv6 source address is client 1 DHCPv6 IP
IPv6 destination is client 2 DHCPv6 IP
source mac is correct
destination mac is HSRP mac of default gateway.
So in this case, L2 communication is actually L3 and uses the default gateway to route the traffic because client 1 cannot learn the mac of client 2.
So to allow mac to mac L2 communication I'm going to need to advertise the prefix, but then set the A flag to stop SLAAC.
I guess I assumed that the client would learn it's prefix from it's IP address from DHCPv6 like you mentioned but this isn't the case.
are you sure you can't send prefix info from the dhcpv6 server?
and you don't see any icmpv6 nd/ns?
Quote from: Dieselboy on May 19, 2016, 10:43:58 PM
EDIT - yes it does. After going into the network adapter and disabling ipv6 and then re-enabling, now I only get a DHCPv6 IP address (including DNS) and the RA gives me default gateway.
You must have missed that question on the exam.
Quote from: Dieselboy on May 20, 2016, 03:15:39 AMSo to allow mac to mac L2 communication I'm going to need to advertise the prefix, but then set the A flag to stop SLAAC.
That's what I was thinking, but I haven't had the time to test it myself. I'm deploying this in a residential subscriber/BNG scenario where every subscriber is in it's own VLAN, so they are forced through the router anyhow.
Quote from: ristau5741 on May 20, 2016, 07:59:16 AM
Quote from: Dieselboy on May 19, 2016, 10:43:58 PM
EDIT - yes it does. After going into the network adapter and disabling ipv6 and then re-enabling, now I only get a DHCPv6 IP address (including DNS) and the RA gives me default gateway.
You must have missed that question on the exam.
Exam was more than half a decade ago. I can't remember what I did last weekend! :blank:
Quote from: srg on May 20, 2016, 10:57:20 AM
Quote from: Dieselboy on May 20, 2016, 03:15:39 AMSo to allow mac to mac L2 communication I'm going to need to advertise the prefix, but then set the A flag to stop SLAAC.
That's what I was thinking, but I haven't had the time to test it myself. I'm deploying this in a residential subscriber/BNG scenario where every subscriber is in it's own VLAN, so they are forced through the router anyhow.
that's why I'm thinking as well srg.
Though dialing it back to first principles - prefixes in IPv6 are assumed to be /64 right? So why can't a host work out its local subnet if it has an address? Or is that a "convention"?
Quote from: wintermute000 on May 20, 2016, 10:26:08 PM
that's why I'm thinking as well srg.
Though dialing it back to first principles - prefixes in IPv6 are assumed to be /64 right? So why can't a host work out its local subnet if it has an address? Or is that a "convention"?
I was thinking this as well but I guess the client assumes it doesn't know what subnet it's on.
Quote from: Dieselboy on May 21, 2016, 12:43:55 AM
Quote from: wintermute000 on May 20, 2016, 10:26:08 PM
that's why I'm thinking as well srg.
Though dialing it back to first principles - prefixes in IPv6 are assumed to be /64 right? So why can't a host work out its local subnet if it has an address? Or is that a "convention"?
I was thinking this as well but I guess the client assumes it doesn't know what subnet it's on.
Yes that's basically what's happening. In theory with SLAAC the client could work out the on-link subnet but this would break NBMA if the router doesn't do ND proxying. In DHCPv6 this is not possible, the IA_NA doesn't even contain a prefix so the IP is considered a single /128.
So the gist of it is that the client should not draw any own conclusions about on-link prefixes but must always be explicitly told about them (there could be on-link prefixes where the client doesn't have an IP etc). There is an RFC that updates the Neighbor Discovery RFC and clearifies this; https://tools.ietf.org/html/rfc5942 (really a good read on this topic!)
So can I recap what we've established in both theory and practice (i.e. Dieselboy's live experience)
1.) DHCPv6 does NOT send the prefix, just the IP. This (i.e. not sending the 'mask') is also not the same thing as prefix delegation (wickedly clear terminology LOL).
2.) RA is required to send the prefix even if disabling SLAAC/using stateful DHCPv6 address delegation
3.) You can send this prefix via RA whilst at the same time disabling SLAAC (-A) and enabling the other options flag (M bit) to suggest (but in practice works every time) use a DHCPv6 server for stateful addressing
4.) If you do not disable SLAAC but send the DHCPv6 server via the M-bit, you will get both addresses (and both will be 'valid')
5.) If you do not send the prefix via RA, the host thinks it has a /128 and will not even attempt ICMPv6 ND/NS and will instead send any and all packets to the MAC address of the default gateway
I did not know the last part, so thanks again Dieselboy for documenting your experience and srg for the clarification
I read this thread and felt satisfied that, not once, were any firewalls blamed. The rest of it went right over my head.
My ASA has been very good in this whole thing :)
The aim of this post was to get a better understanding of how one would go ahead and configure IPv6 in a working environment.
For reference, here is my SVI config I've settled on, based on this discussion thread. I've put comments next to the commands below.
interface Vlan10
description USER-ACCESS SVI
no shutdown
no ip redirects
ip address 192.168.10.2/24
ipv6 address 2001:xxxx:xxxx:70a::2/64 # Set IPv6 Address
ipv6 nd managed-config-flag # Set the M flag to tell clients they can use DHCPv6 (this is a suggestion to clients, not an enforcement)
ipv6 nd prefix 2001:xxxx:xxxx:70a::/64 1800 1800 no-autoconfig # Advertise the IPv6 prefix in ICMPv6 RA messages which clients pick up. The "no-autoconfig" clears the A flag and advises clients not to use SLAAC against this prefix.
hsrp version 2
hsrp 247
preempt delay minimum 60 reload 60
priority 100 forwarding-threshold lower 1 upper 100
timers 1 4
ip 192.168.10.1
hsrp 247 ipv6
preempt delay minimum 60 reload 60
priority 100 forwarding-threshold lower 1 upper 100
timers 1 4
ip autoconfig # Use link-local as virtual HSRP address
ip 2001:xxxx:xxxx:70a::1 # Not really used by end devices - I've added it here so it's a logical representation / conversion of IPv4 to IPv6
ip dhcp relay address 192.168.7.234
ip dhcp relay address 192.168.7.233
ipv6 dhcp relay address 2001:xxxx:xxxx:707::ea:0 # DHCPv6 Relay to Windows 2012 DHCPv6 Server to provide clients with IPv6 address, DNS search domain, DNS addresses
ipv6 dhcp relay address 2001:xxxx:xxxx:707::e9:0 # DHCPv6 Relay to Windows 2012 DHCPv6 Server to provide clients with IPv6 address, DNS search domain, DNS addresses
With the above, we get the following output from "ipconfig /all"
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : internaldomain.com
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : 7C-05-07-1D-70-2F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:xxxx:xxxx:70a::93(Preferred)
Lease Obtained. . . . . . . . . . : Tuesday, 24 May 2016 8:00:32 AM
Lease Expires . . . . . . . . . . : Tuesday, 31 May 2016 8:00:34 AM
Link-local IPv6 Address . . . . . : fe80::1477:d1e:f27b:6b9b%5(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.10.104(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Sunday, 22 May 2016 5:49:39 PM
Lease Expires . . . . . . . . . . : Wednesday, 25 May 2016 8:00:31 AM
Default Gateway . . . . . . . . . : fe80::5:73ff:fea0:f7%5
192.168.10.1
DHCP Server . . . . . . . . . . . : 192.168.7.234
DHCPv6 IAID . . . . . . . . . . . : 175899911
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-9D-25-6B-7C-05-07-1D-70-2F
DNS Servers . . . . . . . . . . . : 2001:xxxx:xxxx:707::e9:0
2001:xxxx:xxxx:707::ea:0
192.168.7.233
192.168.7.234
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
internaldomain.com
Great reference! However, I think that:
Quote from: Dieselboy on May 23, 2016, 09:55:57 PM
ipv6 nd prefix 2001:xxxx:xxxx:70a::/64 1800 1800 no-autoconfig # Advertise the IPv6 prefix in ICMPv6 RA messages which clients pick up. The "no-autoconfig" sets the A flag and advises clients not to use SLAAC against this prefix.
actually clears the A flag, not sets it.
That's what I said ;)
Only joking. I've edited my post to say "clears the A flag". Thanks for pointing out the error. :rock:
[I ran wireshark to check before posting this]