Subject: [dhcwg] FW: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

From: Jiangsheng <[email-masked]>
Date: Tue, 05 Jul 2011 07:40:31 +0000

Hi, all,

A new draft draft-jiang-dhc-addr-registration-01 has been submitted to DHC WG. This document follows the WG consensus on the requirement of address registration (draft-jiang-6man-addr-registration-req). The requirement part from is document of draft-jiang-6man-addr-registration-req has been integrated into this new draft.

Any comments are welcome!

Best regards,

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 04, 2011 4:24 PM
> To: Jiangsheng
> Cc: [email-masked]; Jiangsheng
> Subject: New Version Notification for draft-jiang-dhc-addr-
> registration-01.txt
> 
> A new version of I-D, draft-jiang-dhc-addr-registration-01.txt has been
> successfully submitted by Sheng Jiang and posted to the IETF repository.
> 
> Filename:	 draft-jiang-dhc-addr-registration
> Revision:	 01
> Title:		 A Generic IPv6 Addresses Registration Solution Using
> DHCPv6
> Creation date:	 2011-07-01
> WG ID:		 Individual Submission
> Number of pages: 11
> 
> Abstract:
>    In the IPv6 address allocation scenarios, host self-generated
>    addresses are notionally conflicted with the network managed address
>    architecture. These addresses need to be registered in the
> networking
>    management plate for the purposes of central address administration.
>    This document introduces a generic address registration solution
>    using DHCPv6, and defines one new ND option and three new DHCPv6
>    options.
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 5 Jul 2011 22:16:43 -0500

Hi:

Without judging whether I think this is a good or bad idea, I will point
out that one (IMHO) major flaw is that there is no "lifetime" associated
with these registrations. Do they last for a day or forever?

Without this, there is no way to reclaim an address or know when it is
stopped being needed (because no re-registration occurs). Over time
without this, the DHCPv6 server would have to remember more and more
addresses and hence fill its database (both on disk and in memory) with
more and more addresses.

This does mean that the client would have to periodically re-register
the address.

And, then that begs the question as to whether this is worth it -- why
not just use DHCPv6 in the first place? Many servers allow the client to
hint at the address (and if not in use and assuming server policy allows
the hint to be used), that address is "leased" to the client.

Investing in updating hosts to implement this work could likely be
better spent in implementing DHCPv6?

Also, RFC 4862 addresses are ones that the DHCPv6 server can easily be
programmed to avoid - as they are EUI-64 based and therefore have the
universal/local bit set to indicate that these are universal addresses
(a DHCPv6 server really shouldn't be generating addresses with the
universal bit set -- except it is attempting to mimic stateless
assignments). That's also why RFC 4941 clearly states:

   3.  Take the leftmost 64-bits of the MD5 digest and set bit 6 (the
       leftmost bit is numbered 0) to zero.  This creates an interface
       identifier with the universal/local bit indicating local
       significance only.

And, RFC 4941 generated addresses could "conflict" with other RFC 4941
generated addresses (by a different client) and DAD can be used to
handle these cases -- a new address is then generated.

So, that really only leaves CGA addresses as a "problem space"? I don't
know/recall enough about whether these could or are already handled in
other ways, but they have to co-exist with RFC 4941 addresses too (for
example in cases where the techniques proposed in this draft are not
available).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jiangsheng
Sent: Tuesday, July 05, 2011 3:41 AM
To: [email-masked] WG
Subject: [dhcwg] FW: New Version Notification for
draft-jiang-dhc-addr-registration-01.txt

Hi, all,

A new draft draft-jiang-dhc-addr-registration-01 has been submitted to
DHC WG. This document follows the WG consensus on the requirement of
address registration (draft-jiang-6man-addr-registration-req). The
requirement part from is document of
draft-jiang-6man-addr-registration-req has been integrated into this new
draft.

Best regards,

Sheng

>    using DHCPv6, and defines one new ND option and three new DHCPv6
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Jul 2011 23:41:17 -0400

> the hint to be used), that address is "leased" to the client.

The point is for hosts to be able to generate their own addresses, e.g. for CGA.   So the DHCP server can't originate the address.   All your other points are valid, though.

---

From: Jiangsheng <[email-masked]>
Date: Wed, 06 Jul 2011 03:51:55 +0000

Hi, Bernie,

Thanks for your valuable comments. See my replies in lines.

> with these registrations. Do they last for a day or forever?

This is a good catch. But the reason is we don't know who should decide the lifetime. The hosts would always say as long as possible, like forever. This does not help. That's why we do not have lifetime in the request option. The server expires old address periodly could be a choice, but have other issues, like you mentioned below. The authors would like to widely ask opinion from the WG.
 
> the hint to be used), that address is "leased" to the client.

I don't want to discuss this question (whether host generated address should exist or only DHCP-assigned address) too much. This discuss is endless, we know. And the fact is there are many host generated addresses exist. This fact is the foundation of our requirement of address registration.
 
> example in cases where the techniques proposed in this draft are not

All you above points are right. But the registration is not only to avoid address duplication.

Regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Jul 2011 23:57:51 -0400

> This is a good catch. But the reason is we don't know who should decide the lifetime. The hosts would always say as long as possible, like forever. This does not help. That's why we do not have lif…

Would it work to have a way to tell the DHCP server "I want this address, and if I can't have it, I want to generate a new address" but then follow the regular DHCPv6 address maintenance strategy, where the server assigns the lifetime and manages renewal?   Since we already have the DHCP infrastructure in place, this seems like it would solve Bernie's problem nicely.   This could basically wind up just being an additional option in the IA_NA suboption of a regular Solicit/Confirm/Renew message.

---

From: Jiangsheng <[email-masked]>
Date: Wed, 06 Jul 2011 06:05:10 +0000

> > This is a good catch. But the reason is we don't know who should
> decide the lifetime. The hosts would always say as long as possible,
> like forever. This does not help. That's why we do not have lifetime in
> the request option. The server expires old address periodly could be a
> choice, but have other issues, like you mentioned below. The authors
> would like to widely ask opinion from the WG.
> 
> Would it work to have a way to tell the DHCP server "I want this
> address, and if I can't have it, I want to generate a new address" but
> then follow the regular DHCPv6 address maintenance strategy, where the
> server assigns the lifetime and manages renewal?   Since we already
> have the DHCP infrastructure in place, this seems like it would solve
> Bernie's problem nicely.   This could basically wind up just being an
> additional option in the IA_NA suboption of a regular
> Solicit/Confirm/Renew message.

This sounds a feasible solution for me. 

However, there is a concept issue. The lifetime will be only for the registration entity, not the address. This is different from the current lifetime in IA_NA. Also, we need extra suboption for the refusing scenario.

Sheng

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 6 Jul 2011 06:34:47 -0500

Sheng, I don't understand your comment. Ted's idea is that the client
does DHCPv6 - just that the client selects the addresses, not the
server. The client would need to enforce the lifetimes as it does for
normal leases - and renew as necessary. So, there is no difference in
the meaning of the lifetimes. The client is not free to use the address
"forever" (unless the server provides it an infinite lifetime).

- Bernie

-----Original Message-----
From: Jiangsheng [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 2:05 AM
To: Ted Lemon
Cc: Bernie Volz (volz); [email-masked]
Subject: RE: [dhcwg] New Version Notification for

However, there is a concept issue. The lifetime will be only for the
registration entity, not the address. This is different from the current
lifetime in IA_NA. Also, we need extra suboption for the refusing
scenario.

Sheng

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 6 Jul 2011 20:17:19 +0200

Hi,

I would like to understand what is exactly the goals of this proposal.
Please, see below my questions.

> Hi, Bernie,

[snip]

> All you above points are right. But the registration is not only to avoid address duplication.

RFC4862 says about DAD: "By default, all addresses should be tested
for uniqueness prior to their assignment to an interface for safety.
The test should individually be performed on all addresses obtained
manually, via stateless address autoconfiguration, or via DHCPv6.".
So, sorry but I don't see the value added with your proposal regarding
address duplication.
RFC3315 says: "The client SHOULD perform duplicate address detection
[17] on each of the addresses in any IAs it receives in the Reply
message before using that address for traffic. If any of the addresses
are found to be in use on the link, the client sends a Decline message
to the server as described in section 18.1.7."

So, regarding address duplication, what is the value added by your proposal?

Now, what are the other goals of your proposal? Deny potential use of
SLAAC/RFC4941/CGA in a network, to enforce DHCPv6 use, correct?

Thanks in advance for your reply.

Best regards.

JMC.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jul 2011 14:28:53 -0400

> SLAAC/RFC4941/CGA in a network, to enforce DHCPv6 use, correct?

No.   It's already possible to deny the use of these autoconfiguration mechanisms.   What this proposal adds is the ability to communicate to the network infrastructure the address that you have autoconfigured.   So it's not really useful except in cases where devices are in fact autoconfiguring.

---

From: Jiangsheng <[email-masked]>
Date: Thu, 07 Jul 2011 01:26:34 +0000

My point is the host-generated addresses have no lifetime by themselves. I am not sure they can be enforced a lifetime by DHCPv6 server. In my understanding, what the DHCPv6 server can do is to tell the host: "the address you registered in my database will expired in X time. You need re-register." The DHCPv6 server cannot expire the host-generated addresses. It is not right if the DHCPv6 server said: "your self-generated address is expired. You cannot use this address anymore unless your register."

The point is the level of enforcement. The registration should, in my understanding, be lower than the address existence. Whether the address is registered should NOT affect the existence of the address. In some network, the enforcement of registration even lower than the usage of the address. This sentence means unregistered addresses may also be used. In some networks, the network management MAY want to equal the registration with legal usage, to say "if your address does not registered, it should not be used in my network". However, this would depend on the management police.

In brief, my point can be describe like this: existence > usage >= registration. So, the registration requirement should not enforce the address lifetime. This is fundamentally different from DHCP-assigned address.

Sheng

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2011 7:35 PM
> To: Jiangsheng; Ted Lemon
> Cc: [email-masked]
> Subject: RE: [dhcwg] New Version Notification for draft-jiang-dhc-addr-
> registration-01.txt
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 6 Jul 2011 21:52:11 -0500

The bottom line is that the lifetime means that the DHCPv6 server will
"remove" the "lease" from the client and assume the "lease" could be
used by some other client. End of story. That's all these lifetimes ever
mean.

If the client is still using it, it should re-register the lease again
periodically (before the lifetime expires). If it doesn't, and continues
using it, then the DHCPv6 server might assign that lease to another
client (under the usual leasing conditions or if another client
registered the lease).

*IF* there is a benefit for the client to register in the first place,
then there *MUST* also be a benefit for the client to maintain the
registration to keep the lifetime "moving forward" in the DHCPv6 server
so the server knows that the lease is still in use by the client.

Sure, if the client doesn't or is unable to, we're back to where we were
before this registration protocol was proposed.

That's also why I still don't really see the benefit of this.

- Bernie

-----Original Message-----
From: Jiangsheng [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 9:27 PM
To: Bernie Volz (volz); Ted Lemon
Cc: [email-masked]
Subject: RE: [dhcwg] New Version Notification for

My point is the host-generated addresses have no lifetime by themselves.
I am not sure they can be enforced a lifetime by DHCPv6 server. In my
understanding, what the DHCPv6 server can do is to tell the host: "the
address you registered in my database will expired in X time. You need
re-register." The DHCPv6 server cannot expire the host-generated
addresses. It is not right if the DHCPv6 server said: "your
self-generated address is expired. You cannot use this address anymore
unless your register."

The point is the level of enforcement. The registration should, in my
understanding, be lower than the address existence. Whether the address
is registered should NOT affect the existence of the address. In some
network, the enforcement of registration even lower than the usage of
the address. This sentence means unregistered addresses may also be
used. In some networks, the network management MAY want to equal the
registration with legal usage, to say "if your address does not
registered, it should not be used in my network". However, this would
depend on the management police.

In brief, my point can be describe like this: existence > usage >=
registration. So, the registration requirement should not enforce the
address lifetime. This is fundamentally different from DHCP-assigned
address.

Sheng

> Subject: RE: [dhcwg] New Version Notification for
draft-jiang-dhc-addr-

---

From: Jiangsheng <[email-masked]>
Date: Thu, 07 Jul 2011 03:46:32 +0000

> used by some other client. End of story. That's all these lifetimes
> ever mean.

Of course, lifetime of registration record is different from the lifetime of address.

In Shim6 protocol, an IPv6 address does not really have connection any more (which means this address has expired and denied by network) can still be used as host id to link the different connections together. This address may be expired in the registration database. But it is still meaningful on the host.
 
> client (under the usual leasing conditions or if another client

No problem for this. We share the same understanding here. However, the host may use the address inside itself.
 
> so the server knows that the lease is still in use by the client.

Like mentioned above, address may have other usage rather than maintaining network connection. So, even the registration record is expired, host may keep the address for a while.

Of course, we can choose to only care about the network-meanful lifetime by ignoring address that only used on host itself. I am also fine for this. But we need to clarify this in the draft text.

Sheng
 
> > > like forever. This does not help. That's why we do not have
> lifetime
> > in
> > > the request option. The server expires old address periodly could
> be
> > a

---

From: Jiangsheng <[email-masked]>
Date: Fri, 08 Jul 2011 09:22:59 +0000

We am planning to update again responsing to recent discussion on the mail list by next Monday. Should we go with the IA_NA solution? Doing so means we equal registration record lifetime and address lifetime. An alternative approach is the Address Registration Solicitation bring a default lifetime for address record, asking the host to re-register period.

Ted, any preference?

Sheng

> Sent: Thursday, July 07, 2011 11:47 AM
> Subject: Re: [dhcwg] New Version Notification for draft-jiang-dhc-addr-
> registration-01.txt
> 
> In Shim6 protocol, an IPv6 address does not really have connection any
> more (which means this address has expired and denied by network) can
> still be used as host id to link the different connections together.
> This address may be expired in the registration database. But it is
> still meaningful on the host.
> 
> Like mentioned above, address may have other usage rather than
> maintaining network connection. So, even the registration record is
> expired, host may keep the address for a while.
> 
> Of course, we can choose to only care about the network-meanful
> lifetime by ignoring address that only used on host itself. I am also
> fine for this. But we need to clarify this in the draft text.
> 
> Sheng
> 
> > > > address, and if I can't have it, I want to generate a new
> address"
> > > but
> > > > then follow the regular DHCPv6 address maintenance strategy,
> where
> > > the
> > > > Bernie's problem nicely.   This could basically wind up just
> being
> > an

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Jul 2011 09:39:51 -0400

> We am planning to update again responsing to recent discussion on the mail list by next Monday. Should we go with the IA_NA solution? Doing so means we equal registration record lifetime and addres…

I really like the IA_NA solution.   I would encourage you to pursue it.

---

From: Jiangsheng <[email-masked]>
Date: Mon, 11 Jul 2011 08:59:15 +0000

> > We am planning to update again responsing to recent discussion on the
> mail list by next Monday. Should we go with the IA_NA solution? Doing
> so means we equal registration record lifetime and address lifetime. An
> alternative approach is the Address Registration Solicitation bring a
> default lifetime for address record, asking the host to re-register
> period.
> 
> Ted >I really like the IA_NA solution.   I would encourage you to pursue it.

We have submitted a new version, in which IA_NA is reused for registration procedure. :)

Sheng

> Sent: Monday, July 11, 2011 3:44 PM
> To: Jiangsheng
> registration-02.txt
> A new version of I-D, draft-jiang-dhc-addr-registration-02.txt has been
> Revision:	 02
> Creation date:	 2011-07-11
> Number of pages: 10
>    using DHCPv6, and defines one new ND option and one new DHCPv6
> option
>    in order to propagate the solicitations of registering self-
> generated
>    addresses. The registration procedure reuses the existing IA_NA in
>    the DHCPv6 protocol.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Jul 2011 09:48:18 -0400

> We have submitted a new version, in which IA_NA is reused for registration procedure. :)

Great, thanks!