DHPCv6 stateful configuration: % No valid source address for destination

[Steph1963]

Hi

I would like to know why I receive the No valid Source address for destination when I am configuring a stateful DHCPv6 server and client as follow:

Server Configuration

ipv6 dhcp pool IPV6_DHCPPOOL

     address prefix 2001:DB8:1000::/64 lifetime infinite infinite

     link-address 2001:DB8:1000::1/64

     dns-server 2001:DB8:1000::1

     domain-name cisco.com

!

interface Ethernet0/0

     ipv6 address 2001:DB8:1000::1/64

     ipv6 enable

     ipv6 nd ra suppress

     ipv6 dhcp server IPV6_DHCPPOOL

Client Configuration

interface FastEthernet0/0

     ipv6 address dhcp

     ipv6 enable

R2#ping  2001:DB8:1000::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:1000::1, timeout is 2 seconds:

% No valid source address for destination

The only way I was able to have a successful ping is by adding the following static route on the client side:

R2(config)#ipv6 route  2001:DB8:1000::/64 fa0/0

I just do not understand why this stateful configuration does not send the subnet mask

Thanks

Stephane

[Seb Rupik · Accepted solution]

Hi Stephane,

You need to remove the line supressing Router Advertisements  otherwise the RA's carrying the prefix adverts will not make it out of  the interface:

!

interface eth0/0

  no ipv6 nd ra suppress

!

cheers,

Seb.

[James Leinweber]

Also, in DHCPv6 the client behavior is controlled by the "managed" and "other" flag bits in the router advertisement.   If you have no RA's, you are doing what I call "stealth v6" - only clients with statically configured addresses and statically configure routes will work.   I am using this on a DMZ subnet where some of the hosts aren't ready for v6 yet, for example.

* RA's are the the only way to find upstream gateways; there is no gateway option in DHCPv6.    The gateway is implicitly the link-local address of the sending router.

* RA's are the only way to do SLAAC, assuming they carry prefixes flagged for autoconfiguration

* RA's are the only way to find out which prefixes are on-link with you

* RA's are the only way to turn on DHCPv6

Normal v6 network Really Need RA's.

-- Jim Leinweber, WI State Lab of Hygiene

[Steph1963]

Hi James,

Very interesing, this is very helpful in trying to understand DHCPv6 server. If I have understand you correcly, configuring DHCPv6 server with no RA and no static route on the client is useless for IPv6 connectivity. In this situation, the only way to get IPv6 connectivity would be to have a static link local or global addresses and static route that has nothing to do with the DVHPv6 server.

Thanks for your help

Stephane

[James Leinweber]

Your understanding is correct.  There are 3 popular IPv6 scenarios:

(1) client has static global unicast address (2::/3) and static route, and ignores RA's if present.  Typically it will also use an autoconfigured link-local address (fe80::/64), often with an EUI-64 mapped host part constructed from a 48-bit ethernet address.  Client still does ND duplicate address detection (neighbor solicitation multicast) for both its link-local and global unicast addresses.

(2) router multicasts RA's, with DHCPv6 flags turned off; client autoconfigures SLAAC global and link-local addresses.  Client infers router address from RA sender, but probably has no v6 DNS configuration (the RDNS option is not yet widely supported).  Client is probably dual-stack and got a v4 DNS config from v4 DHCP.

(3) router multicasts RA's with DHCPv6 flags on; client gets upstream router from RA sender, DNS and other config from DHCP server, and may be gettting v6 global address from DHCPv6 server.  Based on the RA flags, v6 DHCP requests are multicast to the ff02::1:2 "all relay agents" group.  The clients link-local address is usually still autoconfigured.  The client might be v6-only, or if dual stack is probably also doing v4 DHCP.  Hopefully any v4 and v6 DNS information refer to the same underlying domains and dual-stack resolving servers; otherwise the client behavior may be excitingly erratic and undetermined.

Note that historically DHCPv6 was unpopular, because at the office many clients didn't implement it (windows prior to vista, OS-x prior to 10.6 or so, most printers, most mobile devices, ...), and at home consumer grade routers tended to have buggy server implementations, most especially if the upstream ISP were to use prefix delegation and hand out /60's instead of /64's.  This situation is improving, and in 2014 DHCPv6 may become more common and more reliable.

-- Jim Leinweber, WI State Lab of Hygiene

.