Subject: Re: [Dhcpv6bis] [dhcpv6bis] #82 (XML 3315): Bakeoff: IAADDR with 0 address

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 11:51:14 -0000

#82: Bakeoff: IAADDR with 0 address

Comment (by [email-masked]):

 After reviewing the meeting minutes at
 http://www.ietf.org/proceedings/92/minutes/minutes-92-dhc and listening to
 the recording (7280.0 sec or 2:01:20.0 is where the discussion of this
 ticket start), there needs to be two actions done:

    1) discourage the use of the unspecified values by the client for the
 address or prefix values unless the client supplies the prefix length hint
 for the prefix it requests or if the client supplies (at least one/ or
 always both?) hint(s) for the preferred/valid lifetimes.

    2) describe the process of client-initiated rollover from an address it
 wishes to deprecate by means of using a new IA_ID.

 To address the first part, I will add the text:

 For the prefix - after
 https://github.com/dhcwg/rfc3315bis/blob/master/rfc3315bis.txt#L3855

 i.e. after this paragraph:

 For the Renew or Rebind, if the IA_PD contains no IA Prefix option or
 it contains an IA Prefix option with the IPv6 prefix field set to 0,
 the delegating router SHOULD assign prefixes to the IA_PD according
 to the delegating router's explicit configuration information. In
 this case, if the IA_PD contains an IA Prefix option with the IPv6
 prefix field set to 0, the delegating router MAY use the value in the
 "prefix-length" field of the IA Prefix option as a hint for the
 length of the prefixes to be assigned. The delegating router MAY
 also respect lifetime hints provided by the requesting router in the
 IA Prefix option.

 '''The requesting router SHOULD NOT send IA Prefix option with the zero-
 value IPv6 prefix field unless it is supplying a hint in the "prefix-
 length" field.'''

 For the address - after
 https://github.com/dhcwg/rfc3315bis/blob/master/rfc3315bis.txt#L5329

 i.e. after this paragraph:

 In a message sent by a client to a server, values in the preferred
 and valid lifetime fields indicate the client's preference for those
 parameters.  The client may send 0 if it has no preference for the
 preferred and valid lifetimes.  If a client wishes to express its
 lifetimes preferences and does not have the knowledge to populate the
 IPv6 address field, it can use unspecified address (::).  It is up to
 a server to honor or ignore these preferences.

 '''The client SHOULD NOT send the IA Address option with unspecified
 address (::) unless it is supplying these preferences for the
 lifetimes.'''

 To address the second part, i.e. discussion of address rollover, I thought
 of adding the following text after
 https://github.com/dhcwg/rfc3315bis/blob/master/rfc3315bis.txt#L5347

 i.e. after this paragraph in section "IA Address Option":

 More than one IA Address Option can appear in an IA_NA option or an
 IA_TA option.

 '''If the client wishes to obtain new address(es) and transition from old
 one(s), it would  create a new IAID to obtain the new address(es), and
 hint the shorter lifetime for the existing IA_NA or IA_TA.'''

-- 
----------------------------+-----------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  new
 Priority:  P3 major        |   Milestone:  C awaiting consensus
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+-----------------------------------

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 11:57:03 -0000

Also: looks like we'll need to coordinate with Bernie as the
 http://trac.tools.ietf.org/group/dhcpv6bis/ticket/114#comment:6 seems to
 capture the issue in more specifics.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Jul 2015 11:59:21 +0000

This should mention ok if lifetime hints are being provided.

- Bernie (from iPad)

> On Jul 1, 2015, at 7:51 AM, dhcpv6bis issue tracker <[email-masked]> wrote:
>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 12:54:45 -0000

After discussion with Tomek on the dhcpv6bis coauthor call, we decided to
 split the issue (2) into a separate ticket (I created
 http://trac.tools.ietf.org/group/dhcpv6bis/ticket/147), and resolve this
 one, taking Bernie's email comment into account:

 Date: Wed, 1 Jul 2015 13:59:21 +0200
 From: "Bernie Volz (volz)" <[email-masked]>
 To: dhcpv6bis issue tracker <[email-masked]>
 Cc: "Andrew Yourtchenko (ayourtch)" <[email-masked]>,
 "[email-masked]" <[email-masked]>
 Subject: Re: [dhcpv6bis] #82 (XML 3315): Bakeoff: IAADDR with 0 address

 - Bernie (from iPad)

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 13:09:20 -0000

Resolved via:

 https://github.com/dhcwg/rfc3315bis/commit/7f5d688f69f42b0e0eb72e96bc8e4a63d8aaf099

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 13:09:37 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
----------------------------+-----------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  closed
 Priority:  P3 major        |   Milestone:  C awaiting consensus
Component:  XML 3315        |  Resolution:  fixed
 Keywords:                  |    Due Date:
----------------------------+-----------------------------------

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