dhcpcd-discuss

Hi Jakub

On 24/10/2017 23:15, Jakub Jankowski wrote:
> I am trying to debug an issue I have with DHCPv6 IA_PD on my ISP's 
> network. I'm using dhcpcd-7.0.0-rc3 with the following configuration:
>
> hostname
> duid
> persistent
> option rapid_commit
> option domain_name_servers, domain_name, domain_search, host_name
> option classless_static_routes
> option ntp_servers
> option interface_mtu
> require dhcp_server_identifier
> slaac private
> nohook wpa_supplicant
> nohook resolv.conf, ntp.conf, yp.conf, hostname, lookup-hostname, 
> timezone, wpa_supplicant
> denyinterfaces eth0 eth0.2 eth0.55 eth0.666 br0 br55 wlan* tap* veth*
> noipv4
> noipv6
> noipv6rs
> noipv4ll
> interface eth0.777
>      ipv4
>      ipv6
>      ipv6rs
>      ia_na 1
>      ia_pd 2/::/48 br0/0/64
>
> Initial Solicit-Advertise-Request-Reply seems to work fine, and in the 
> Reply packet I am getting:
>
> DHCPv6
>      Message type: Reply (7)
>      Identity Association for Non-temporary Address
>          Option: Identity Association for Non-temporary Address (3)
>          Length: 66
>          IAID: 00000001
>          T1: 1200
>          T2: 1800
>          IA Address
>              Option: IA Address (5)
>              Length: 24
>              IPv6 address: 2a02:168:<redacted1>
>      (...)
>      Identity Association for Prefix Delegation
>          Option: Identity Association for Prefix Delegation (25)
>          IAID: 00000002
>          T1: 1200
>          T2: 1800
>          IA Prefix
>              Option: IA Prefix (26)
>              Length: 25
>              Preferred lifetime: 3600
>              Valid lifetime: 86400
>              Prefix length: 48
>              Prefix address: 2a02:168:<redacted2>
>          Status code
>              Option: Status code (13)
>              Length: 32
>              Status Code: Success (0)
>              Status Message: Assigned fixed in-pool prefix.
>
> Within the same reply I'm also receiving Server-unicast (12) option:
>
>      Server unicast
>          Option: Server unicast (12)
>          Length: 16
>          IPv6 address: 2001:1620:<redacted3>
>
> So far so good. After 20 minutes (as per T1) my dhcpcd sends Renew 
> packets, which don't get any reply from my ISP side.
> And that's what makes me wonder - source address in those Renews is my 
> link-local address:
>
> initial Reply:
>   12 20:48:17.353653 fe80::224:14ff:feef:72ff -> 
> fe80::baae:edff:fe76:98d6 DHCPv6 346 Reply XID: 0xfedcba IAA: 
> 2a02:168:<redacted1> CID: 012345...
>
> subsequent Renews:
>   13 21:08:17.360399 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
>   14 21:08:26.492686 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
>   15 21:08:43.910163 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
>   16 21:09:18.636170 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
>   17 21:10:26.345222 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
>
> All those Renews are for both IA_NA and IA_PD (with T1=T2=0).
>
> I'm quite surprised to see a link-local used as source here, when there 
> is a global-scope unicast address assigned to that interface already. 
> But I might be misinterpreting RFC3315 section 16:
>
>     When a client sends a DHCP message directly to a server using unicast
>     (after receiving the Server Unicast option from that server), the
>     source address in the header of the IP datagram MUST be an address
>     assigned to the interface for which the client is interested in
>     obtaining configuration and which is suitable for use by the server
>     in responding to the client.
>
> And although RFC3633 section 8 says
>
>     Delegated prefixes are not associated with a particular interface in
>     the same way as addresses are for address assignment, and the rules
>     described in section 16, "Client Source Address and Interface
>     Selection" of RFC 3315 do not apply.
>
> it also says
>
>     When a requesting router sends a DHCP message directly to a
>     delegating router using unicast (after receiving the Server Unicast
>     option from that delegating router), the source address SHOULD be an
>     address from the upstream interface and which is suitable for use by
>     the delegating router in responding to the requesting router.

I'll guess that you started dhcpcd on a specific interface as it's bound 
to  lladdr.
You can either start dhcpcd in master mode (ie don't specify an 
interface on the command line or pass it the -M flag or add master to 
dhcpcd.conf) or try the latest git head where I think I've fixed this here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=ef53a17e01fc25aea22717373afcfcd9e35c85b5

That should always let the kernel decide what address to send from, as 
long as it's on the interface.

Let me know if that fixes it for you!

Roy