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

From: "Liushucheng (Will)" <[email-masked]>
Date: Fri, 28 Aug 2015 03:51:20 +0000

Hi all,

After taking a look at this draft, I feet it practical and agree to the point, with some comments below (most are clarifying ones).

Section 4:
>   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?

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.

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

Would this really comply with the spirit of DHCPv6?

> 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"?

Section 7:
>In
>   typical implementations, privacy addresses use up to 8 addresses (one
>   per day).  

Any reference?

NITS

Section 1:
s/adressing/addressing/

Section 6:
> The prefix can also be
>       hierarchically delegated to downstream clients, or, if it is a
>       /64, it be reshared with downstream clients via ND proxying
>       [RFC4389] or /64 sharing [RFC7278]

s/it be reshared/be reshared/

Section 9.1:
> 
>    Some network operators - often operators of networks that provide
>    services to third parties such as university campus networks - have
>    made the argument that the only feasible IPv6 deployment mechanism is
>    DHCPv6, due to the need to be able to track at all times IPv6
>    addresses are assigned to which hosts.

s/times IPv6 addresses are assigned to which hosts/times which IPv6 addresses are assigned to which hosts/

Section 9.2:
s/which is is/which is/

Regards,
Will

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 1 Sep 2015 10:20:02 +0900

Will,

thanks for the review. Comments inline.

On Fri, Aug 28, 2015 at 12:51 PM, Liushucheng (Will) <[email-masked]
> wrote:

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

The functions defined in the preceding section.

> 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.

> 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.

> 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.

> >   typical implementations, privacy addresses use up to 8 addresses (one

Added.