DHCPv6: Confirm/Reply handshake not done correctly by Agent
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R3.0 |
Fix Committed
|
High
|
Hari Prasad Killi | |||
R3.1 |
Fix Committed
|
High
|
Hari Prasad Killi | |||
R3.2 |
Fix Committed
|
High
|
Hari Prasad Killi | |||
Trunk |
Fix Committed
|
High
|
Hari Prasad Killi |
Bug Description
DHCPv6 Confirm/Reply message exchange is not done correctly by vRouter. The Reply message sent by vRouter does not include the status_code_option with the appropriate status; as such the VM does not accept the IP address returned to it.
The standard message exchange for getting a v6 address via stateful DHCPv6 is: Solicit, Advertise, Request and Reply. If a client does this then its able to successfully get a v6 address from agent.
However, there is also the possibility of the client sending a Confirm message if it already has an old lease or straight after being instantiated for the first time (if it hasn't yet seen an RA from the vRouter). At the moment, vRouter sends a Reply message in response to the Confirm without the status_code_option (option 13). As such, the client does not accept the new IP that the vRouter returned.
There are 2 examples:
1. VM was instantiated and it sent a Confirm for the IP '::' (this is the special unspecified IP address). As you can see below, Reply message was sent without status_code_option but client couldn't assign the IP returned.
Bound to *:546
Listening on Socket/eth0
Sending on Socket/eth0
PRC: Confirming active lease (INIT-REBOOT).
XMT: Forming Confirm, 0 ms elapsed.
XMT: X-- IA_NA "eX'("
XMT: | X-- Confirm Address ::
XMT: V IA_NA appended.
XMT: Confirm on eth0, interval 980ms.
RCV: Reply message on eth0 from cafe:aaaa:1111::2.
RCV: X-- IA_NA "eX'("
RCV: | X-- starts 1487112195
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: | | X-- IAADDR cafe:aaaa:1111::f
RCV: | | | X-- Preferred lifetime 4294967295.
RCV: | | | X-- Max lifetime 4294967295.
RCV: X-- Server ID: 00:03:00:
PRC: Bound to lease 00:03:00:
RTNETLINK answers: Cannot assign requested address
Same thing when done using an external DHCP server behaves differently. The DHCP server in its Reply sends a static code of NotOnLink forcing the client to fall back to Solicit/
Bound to *:546
Listening on Socket/eth0
Sending on Socket/eth0
PRC: Confirming active lease (INIT-REBOOT).
XMT: Forming Confirm, 0 ms elapsed.
XMT: X-- IA_NA 71:4e:bc:7b
XMT: | X-- Confirm Address ::
XMT: V IA_NA appended.
XMT: Confirm on eth0, interval 920ms.
RCV: Reply message on eth0 from fe80::4a:
RCV: X-- Server ID: 00:01:00:
message status code NotOnLink: "Some of the addresses are not on link."
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT: X-- IA_NA 71:4e:bc:7b
XMT: | X-- Request renew in +3600
XMT: | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 1070ms.
RCV: Advertise message on eth0 from fe80::4a:
RCV: X-- IA_NA 71:4e:bc:7b
RCV: | X-- starts 1487107453
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: | | X-- IAADDR 2001:db8:0:2::13e8
RCV: | | | X-- Preferred lifetime 27000.
RCV: | | | X-- Max lifetime 43200.
RCV: X-- Server ID: 00:01:00:
RCV: Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC: X-- Initial candidate 00:01:00:
XMT: Forming Request, 0 ms elapsed.
XMT: X-- IA_NA 71:4e:bc:7b
XMT: | X-- Requested renew +3600
XMT: | X-- Requested rebind +5400
XMT: | | X-- IAADDR 2001:db8:0:2::13e8
XMT: | | | X-- Preferred lifetime +7200
XMT: | | | X-- Max lifetime +7500
XMT: V IA_NA appended.
XMT: Request on eth0, interval 1080ms.
RCV: Reply message on eth0 from fe80::4a:
RCV: X-- IA_NA 71:4e:bc:7b
RCV: | X-- starts 1487107454
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: | | X-- IAADDR 2001:db8:0:2::13e8
RCV: | | | X-- Preferred lifetime 7200.
RCV: | | | X-- Max lifetime 43200.
RCV: X-- Server ID: 00:01:00:
PRC: Bound to lease 00:01:00:
net.ipv6.
2. The second case is when the VM with a v6 IP on an interface, is moved to a different VN (but old dhcp lease is still valid), and then does a Confirm (could be after a reboot). vRouter returns the new IP in the Reply message, but because the status code is missing, its up to the client to keep the old IP or keep both the IPs (neither of which is desirable).
Below is with vRouter:
root@scapy-
Internet Systems Consortium DHCP Client 4.1-ESV-R4
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https:/
Bound to *:546
Listening on Socket/eth0
Sending on Socket/eth0
PRC: Confirming active lease (INIT-REBOOT).
XMT: Forming Confirm, 0 ms elapsed.
XMT: X-- IA_NA "eX'("
XMT: | X-- Confirm Address ::
XMT: | X-- Confirm Address cafe:aaaa:2222::f
XMT: V IA_NA appended.
XMT: Confirm on eth0, interval 1090ms.
RCV: Reply message on eth0 from cafe:aaaa:1111::2.
RCV: X-- IA_NA "eX'("
RCV: | X-- starts 1487112414
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: | | X-- IAADDR cafe:aaaa:1111::f
RCV: | | | X-- Preferred lifetime 4294967295.
RCV: | | | X-- Max lifetime 4294967295.
RCV: X-- Server ID: 00:03:00:
PRC: Bound to lease 00:03:00:
RTNETLINK answers: Cannot assign requested address
net.ipv6.
net.ipv6.
root@scapy-
eth0 Link encap:Ethernet HWaddr 02:8c:d9:d5:b5:4d
inet addr:1.1.1.15 Bcast:1.1.1.255 Mask:255.255.255.0
inet6 addr: cafe:aaaa:
inet6 addr: fe80::8c:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3271 errors:0 dropped:0 overruns:0 frame:0
TX packets:2790 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:277767 (277.7 KB) TX bytes:169386 (169.3 KB)
Review in progress for https:/ /review. opencontrail. org/28886
Submitter: Hari Prasad Killi (<email address hidden>)