Subject: Re: [v6ops] Review for draft-ietf-v6ops-host-addr-availability

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 9 Sep 2015 12:10:39 +0000

Hi Lorenzo,

Thanks for your response. Please see my reply inline with [Will].

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 9:20 AM
To: Liushucheng (Will)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] Review for draft-ietf-v6ops-host-addr-availability

Will,

thanks for the review. Comments inline.

On Fri, Aug 28, 2015 at 12:51 PM, Liushucheng (Will) <[email-masked]<mailto:[email-masked]>> wrote:
>   Assigning a limited number of addresses per host implies that
>   functions that require multiple addresses will either be unavailable
>   (e.g., if the network provides only one IPv6 address per host, or if
>   the host has reached the limit of the number of addresses available),
>   or that the functions will only be available after an explicit
>   request to the network is granted.  The necessity of explicit

Could you explicitly point out which "functions" or add a reference?

The functions defined in the preceding section.

Section 6:
>    o  Using Stateless Address Autoconfiguration [RFC4862].  SLAAC allows
>       hosts to create global IPv6 addresses on demand by simply forming
>       new addresses from the global prefix assigned to the link.

Traditional slaac only allows for a single stable address, since the address is generated by embedding the underlying mac address.

There are other ways to configure stable addresses as well, e.g., RFC7217. Also, this discussion is not limited to only stable addresses.
[Will] I see. Then it would be great to note this in your draft, and e.g., include a reference to RFC7217.

>  It is also possible for a client to
>       request additional addresses using a different DUID.

Would this really comply with the spirit of DHCPv6?

Good question. RFC 3315 section 9 is not clear on this. One reading of that section is that a host could run multiple "clients", each with a different DUID. Reworded to note that this is technically possible but likely not expected behaviour.
[Will] I'm a little unsure about this. For example, page 19 section 9 says:
     “The DUID is
   designed to be unique across all DHCP clients and servers, and stable
   for any specific client or server - that is, the DUID used by a
   client or server SHOULD NOT change over time if at all possible; for
      example, a device's DUID should not change as a result of a change in
      the device's network hardware.”

Correct me if I’m wrong, IMHO, here seems to assume that you get one DUID per "device"?

> Immune to layer 3 on-  |    No   |    Yes     |   Yes   |   Yes   |
>    | link resource          |         |            |         |         |
>    | exhaustion attack

What do you mean by "Immune to layer 3 on-link resource exhaustion attack"?

It means that a client cannot perform a state exhaustion attack on the network by, e.g., configuring too many IP addresses. That's covered in section 9.3.
[Will] I would suggest to make this clarified somehow.

Regards,
Will