Subject: [Dhcpv6bis] [dhcpv6bis] #124 (XML 3315): Drop IA_TA

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 13 Oct 2014 16:37:04 -0000

#124: Drop IA_TA

 This may be a controversial proposal ... but should we consider dropping
 temporary addresses (IA_TA) from 3315bis?

 We could:
 1. Just not mention IA_TA/temporary addresses in the bis document.
 (Perhaps we would say their use is no longer recommended; see RFC 3315 if
 you want to use them).
 2. We could explicitly state this capability has been deprecated.
 3. We could reject this ticket and incorporate (as is presently the case).

 As the original reason for them was because of the EUI-64 identifier for
 stateless addresses would allow tracking a client, even if it moved to a
 completely different network.

 There could still be other reasons to use temporary-addresses (i.e., to
 make tracking the various requests an individual client issues more
 difficult - especially given the privacy concerns these days), but there
 are other ways to accomplish that (i.e., issue IA_NA with a new IAID and
 release the address when no longer needed).

 Anyway, this ticket is to initiate a discussion on this issue and it may
 end up being rejected.

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

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 16 Oct 2014 19:54:54 -0000

#124: Drop IA_TA

Comment (by [email-masked]):

 Let's discuss this at the team meeting at IETF-91. If we feel this idea
 could have some merit, we could provide a list of pros and cons to the DHC
 WG (at session and on mailing list) to debate.

 It would be interesting to learn of what implementations use these and
 whether perhaps because of the current level or privacy concerns, this
 would be a bad time to remove.

 Clients must be able to handle servers not honoring this (returning empty
 IA_TA). So, even if a client currently supports it, deprecating the
 support shouldn't cause major issues. Probably safest would be to require
 servers to understand IA_TA and return an empty IA_TA in Advertise/Reply
 messages.

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

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 28 Oct 2014 09:03:21 -0000

#124: Drop IA_TA

Changes (by [email-masked]):

 * milestone:   => C awaiting consensus

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

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