IPv6 RA's and DHCPv6

Started by Dieselboy, May 18, 2016, 04:24:02 AM

Previous topic - Next topic

Dieselboy

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?

wintermute000

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

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.

SimonV

Yeah, you need to set the other-config flag or something along that line for it to request DNS settings


Reggle

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.

icecream-guy

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
:professorcat:

My Moral Fibers have been cut.

srg

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.

som om sinnet hade svartnat för evigt.

Dieselboy

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.


SimonV

#7
You can disable SLAAC on Windows machines from the CLI:

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

Also try this, just for laughs :)

icecream-guy

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.

:professorcat:

My Moral Fibers have been cut.

srg

#9
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

som om sinnet hade svartnat för evigt.

Dieselboy

#10
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, 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.

srg

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?
som om sinnet hade svartnat för evigt.

Dieselboy

#12
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.

wintermute000

are you sure you can't send prefix info from the dhcpv6 server?
and you don't see any icmpv6 nd/ns?

icecream-guy


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.
:professorcat:

My Moral Fibers have been cut.