Subject: [Dhcpv6bis] [dhcpv6bis] #166 (XML 3315): Default IIDs

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 19 Jul 2016 16:05:44 -0000

#166: Default IIDs

 dra -ie -6man-default-iids-13 proposes to replace:

 Any address assigned by a server that is based on an EUI64 identifier
 MUST include an interface identifier with the "u" (universal/local) and
 "g" (individual/group) bits of the interface identifier set appropriately,
 as indicated in section 2.5.1 of RFC 2373 [5].

 with:

 By default, DHCPv6 server implementations SHOULD NOT generate predictable
 IPv6 addresses (such as IPv6 addresses where the IIDs are consecutive
 small numbers). [ID.gontdhcpv6stableprivacyaddresses ] specifies one
 possible algorithm that could be employed to comply with this requirement.
 Another possible algorithm would be to select a pseudorandom value chosen
 from a discrete uniform distribution, while avoiding the reserved IPv6
 Interface
 Identifiers [RFC5453] [IANARESERVEDIID].

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

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 19 Jul 2016 16:06:16 -0000

#166: Default IIDs

Description changed by [email-masked]:

Old description:

> "g" (individual/group) bits of the interface identifier set
> appropriately, as indicated in section 2.5.1 of RFC 2373 [5].
>
> with:
>
> possible algorithm that could be employed to comply with this
> requirement. Another possible algorithm would be to select a
> pseudorandom value chosen from a discrete uniform distribution, while
> avoiding the reserved IPv6 Interface

New description:

 draft-ietf-6man-default-iids-13 proposes to replace:

 with:

--

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

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 21 Jul 2016 08:29:00 -0000

#166: Default IIDs

Comment (by [email-masked]):

 At the IETF-96 (Berlin) DHC WG meeting, the Etherpad notes have:

 Suresh: I don't like the replacement text.
 Brian: the draft being referenced in the replacement text. It uses the
 parameters based on something that has to be stable. The concern I have is
 that the server would have to keep it. The concern was that this draft
 brought comments about overspecifying what DHCP implementors do. I would
 prefer "these are the characteristics your allocation should follow (full
 stop)".
 Suresh: start with the current text and add references to RFC7136? The
 RFC5453 is two generations old.

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 21 Jul 2016 08:32:16 -0000

#166: Default IIDs

 Bernie sent note to draft-ietf-6man-default-iids coauthors and others
 about this and proposed an initial rewrite but it it only an initial
 proposal. See https://mailarchive.ietf.org/arch/msg/dhcwg
 /FGamu_4RweR4ichkmDkqNJ-gqMU.

     By default, DHCPv6 server implementations SHOULD NOT generate
     predictable IPv6 addresses ([RFC7721]). DHCPv6 servers SHOULD
     NOT assign addresses that use a reserved IPv6 Interface Identifier
     ([RFC5453], [RFC7136], and [IANARESERVEDIID]).

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