Subject: [Dhcpv6bis] [dhcpv6bis] #130 (XML 3315): Unicast test (i.e., first paragraph of 18.2.3 in RFC 3315)

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 23 Dec 2014 20:32:27 -0000

#130: Unicast test (i.e., first paragraph of 18.2.3 in RFC 3315)

 During WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09, Ted commented:

 What if the server has no record that it sent a unicast option, but is
 configured to support unicast? (See  Section 18.2.3 of RFC 3315)

      When the server receives a Renew message via unicast from a client
      to which the server has not sent a unicast option, the server
      discards the Renew message and responds with a Reply message

 As this is text copied from RFC 3315, we decided to make it a Bis issue.

 My own feeling is that a server doesn't need to track whether it sent the
 unicast option; it could just check whether it allows unicast "now"
 (perhaps by checking its configuration to see if it has a server-unicast
 option it would send to the client if requested and (perhaps) confirm that
 the unicast address matches).

-- 
----------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task            |     Status:  new
 Priority:  P1 blocker      |  Milestone:
Component:  XML 3315        |   Keywords:
 Due Date:  31/03/2015      |
----------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/130>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 23 Dec 2014 20:32:54 -0000

Changes (by [email-masked]):

 * due_date:  31/03/2015 =>

-- 
----------------------------+------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/130#comment:1>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Dec 2014 22:08:26 -0500

> the unicast address matches).

Yup.   I think this makes a lot more sense.

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 24 Dec 2014 04:00:07 -0000

Comment (by [email-masked]):

 Ted indicated "Yup.   I think this makes a lot more sense." to my
 suggestion: "it could just check whether it allows unicast "now" (perhaps
 by checking its configuration to see if it has a server-unicast option it
 would send to the client if requested and (perhaps) confirm that the
 unicast address matches)."

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/130#comment:2>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>