Subject: [Dhcpv6bis] [dhcpv6bis] #147 (XML 3315): Document the process of acquiring of the client-forced "new" address and deprecation of the "old" address

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

#147: Document the process of acquiring of the client-forced "new" address and
deprecation of the "old" address

 This topic popped up during the discussion of
 http://trac.tools.ietf.org/group/dhcpv6bis/ticket/82 in Dallas, with Ted
 suggesting that if the host needs to obtain a new address, it should use a
 new IAID for that.

 We (Andrew and Tomek) had a discussion of what's the definition
 of identity association and whether it should change over time. There
 was no clear consensus here, so is being pushed off to this ticket,
 so #82 could be closed. Andrew will bring this question to the WG
 mailing list.

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

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

---

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

I guess I'm not sure of what exactly the issue is, and there is text in RFC 3315 section 10 which opens up some concerns with changing IA_ID (especially if no persistent storage is available). And perhaps really doesn't matter after client reboots if it returns to using original IA_NA.

But I think the general concept applies that IA_ID is associated with binding and that to get an assurred different address, changing IA_ID value is only way to go. (Releasing address may not work because of grace periods or server logic to remember last assigned address.)

I also don't know how common having a client get a totally "new" address is - why would client need to do this? (I can understand decline case, but we assume this is not that case).

Note also that releasing old address and changing IA_ID is not firm guarantee that released address would not be assigned to client even with different IA_ID (thus must not release first).

I also wonder if goal might be multiple addresses rather than a "different" address? Use of new IA_ID is more clear here.

I guess I'll await email to dhc wg ml. Sorry I missed today's call.

- Bernie (from iPad)

> On Jul 1, 2015, at 8:54 AM, dhcpv6bis issue tracker <[email-masked]> wrote:
> 
> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 1 Jul 2015 16:58:54 +0200

On Wed, 1 Jul 2015, Bernie Volz (volz) wrote:

> I guess I'm not sure of what exactly the issue is, and there is text in 
>RFC 3315 section 10 which opens up some concerns with changing IA_ID 
>(especially if no persistent storage is available). And perhaps really 
>doesn't matter after client reboots if it returns to using original 
>IA_NA.
>
> But I think the general concept applies that IA_ID is associated with 
>binding and that to get an assurred different address, changing IA_ID 
>value is only way to go. (Releasing address may not work because of grace 
>periods or server logic to remember last assigned address.)

On the call I tried to understand: "what is the purpose of the IA" ? What 
does it mean ? Why is it there ? I can not fully grok the fundamental 
behind it. Thus I asked Tomek, and he said the idea was that IAs might be 
belonging to different entities on the host, e.g. different processes, 
etc.

This is perfect as we move to addressing more than just a NIC, but 
from this interpretation it fundamentally follows that an entity can not 
force the address change while at the same time allowing the server to 
know that it is "the same entity".

>
> I also don't know how common having a client get a totally "new" 
>address is - why would client need to do this? (I can understand decline 
>case, but we assume this is not that case).

A privacy-aware client would like to periodically change its address.

Much like they do with SLAAC.

iOS changes the autoconfigured temporary address each time they reconnect 
to wireless.

>
> Note also that releasing old address and changing IA_ID is not firm 
> guarantee that released address would not be assigned to client even 
> with different IA_ID (thus must not release first).

Right, first need to acquire and then release the old address.

>
> I also wonder if goal might be multiple addresses rather than a 
>"different" address? Use of new IA_ID is more clear here.

Yes, having multiple "things" (processes/VMs/apps) on the same NIC using 
different addresses indeed makes perfect sense.

> I guess I'll await email to dhc wg ml. Sorry I missed today's call.

Actually given that I think the ticket#82 mainly involved the question of 
whether to legitimize the behavior of "all-zero" option content or 
discourage it (and it's now closed) - and I cloned #147 solely based on 
Ted's comment, and he's on the list, we might as well clarify it here ?

The way I see it now, I basically add 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.

The text would say:

"If the client wishes to obtain a distinctly new address (or prefix) and 
deprecate the existing one, it needs to create a new IAID, perform a 
transaction to acquire the address/prefix and then perform a transaction 
releasing the old address/prefix when it is deprecated." ?

If that captures what Ted had in mind that is captured in the minutes 
at http://www.ietf.org/proceedings/92/minutes/minutes-92-dhc:

"Ted suggested we document how clients get new addresses - by using
    a new IA_ID with an IA_NA or IA_TA."

then I could perhaps resolve that ticket in-place without the need for 
going to the WG list...

Ted,

what do you think about the above text ?

--a

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Jul 2015 15:25:09 +0000

FYI - The basic reason for the IA_ID was that we wanted to avoid the need to overload the client identify with something that indicated the interface or "group" to which the requested resources applied.

In DHCPv4 it a client wants (for whatever reason) multiple addresses, it MUST generate a client id (this has changed given that Ted wrote a document to make use of the IA_ID + DUID concept for the client id -- but guess what -- this changes the client id).

We wanted to keep the client-id the same for all requests regardless of the interface used. So we needed something to differentiate the instance.

Think of a case where a client has two interfaces (wired and wireless), one client id, and both interfaces are connected to the same server and have the same prefix (since they are bridged). In this case, the client can still get two addresses because it has two different IA_IDs.

- Bernie

-----Original Message-----
From: Andrew Yourtchenko (ayourtch) 
Sent: Wednesday, July 01, 2015 10:59 AM
To: Bernie Volz (volz)
Cc: dhcpv6bis issue tracker; [email-masked]
Subject: Re: [Dhcpv6bis] [dhcpv6bis] #147 (XML 3315): Document the process of acquiring of the client-forced "new" address and deprecation of the "old" address

On Wed, 1 Jul 2015, Bernie Volz (volz) wrote:

> I guess I'm not sure of what exactly the issue is, and there is text 
>in RFC 3315 section 10 which opens up some concerns with changing IA_ID 
>value is only way to go. (Releasing address may not work because of 
>grace periods or server logic to remember last assigned address.)

On the call I tried to understand: "what is the purpose of the IA" ? What does it mean ? Why is it there ? I can not fully grok the fundamental behind it. Thus I asked Tomek, and he said the idea was that IAs might be belonging to different entities on the host, e.g. different processes, etc.

This is perfect as we move to addressing more than just a NIC, but from this interpretation it fundamentally follows that an entity can not force the address change while at the same time allowing the server to know that it is "the same entity".

>address is - why would client need to do this? (I can understand 
>decline case, but we assume this is not that case).

iOS changes the autoconfigured temporary address each time they reconnect to wireless.

>"different" address? Use of new IA_ID is more clear here.

Yes, having multiple "things" (processes/VMs/apps) on the same NIC using different addresses indeed makes perfect sense.

The text would say:

Ted,

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 1 Jul 2015 17:39:34 +0200

Oh, okay - so the semantic for the IA_ID is "A part of client-id that is 
bound to change for whatever reason, separated into its own field to 
allow DUID remain the same", right ?

Then indeed, looks I overcomplicated it for myself, and just the wording I 
wrote in the previous mail would work to address Ted's comment without the need 
for further discussions ?

--a

---

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

Changes (by [email-masked]):

 * owner:   => [email-masked]

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

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 20 Jul 2015 09:10:50 -0000

Comment (by [email-masked]):

 Agreed during the authors meeting that we will do the following change:

 I basically add text

 The text would say:

 "If the client wishes to obtain a distinctly new address (or prefix) and
 deprecate the existing one, it needs to create a new IAID, perform a
 transaction to acquire
 the address/prefix and then perform a transaction releasing the old
 address/prefix when it is deprecated." ?

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