Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 2 Oct 2017 11:47:26 +0900

On Fri, Sep 29, 2017 at 7:10 PM, <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>         Title           : Unique IPv6 Prefix Per Host
>         Authors         : John Jason Brzozowski
>                           Gunter Van De Velde
>         Filename        : draft-ietf-v6ops-unique-ipv6-p
> refix-per-host-12.txt
>

LGTM. Thanks for continuing to iterate on feedback. I think this document
is very important, as it is the only  currently-deployable way to provide
users with multiple IP addresses (and thus follow RFC 7934) on public
networks where there is the possibility of devices attacking each other or
attacking the network.

A couple of minor suggestions for improvements.

1. Since most devices have privacy addresses on by default these days, I
would suggest the following tweaks:

   1. "Each host can consequently use SLAAC or any other method of choice
   to select its /128 unique address." should instead read "Each host can
   consequently use SLAAC or any other method of choice to select IPv6
   addresses in the prefix."
   2. "After the subscriber received the RA, and the associated flags, it
   will assign itself a 128 bit IPv6 address using SLAAC." should read "After
   the subscriber received the RA, and the associated flags, it will assign
   itself one or more 128-bit IPv6 addresses using SLAAC."

2. Thanks for adding text to section 5 addressing the concern about RAs
expiring. One thing I think is not covered is: current Android devices will
actually disconnect when their IPv6 address becomes deprecated. So you
might want to set the preferred lifetime to 3600s as well.

I would also suggest: given that 514 and 686 look like strange numbers,
just mention that these numbers result in an average RA interval of 600s.
:-)

Cheers,
Lorenzo

---

From: Tim Chown <[email-masked]>
Date: Mon, 2 Oct 2017 07:44:51 +0000

> On 2 Oct 2017, at 03:47, Lorenzo Colitti <[email-masked]> wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt
> 
> LGTM. Thanks for continuing to iterate on feedback. I think this document is very important, as it is the only  currently-deployable way to provide users with multiple IP addresses (and thus follow RFC 7934) on public networks where there is the possibility of devices attacking each other or attacking the network.
> 
> 1. Since most devices have privacy addresses on by default these days, I would suggest the following tweaks:
> 	• "Each host can consequently use SLAAC or any other method of choice to select its /128 unique address." should instead read "Each host can consequently use SLAAC or any other method of choice to select IPv6 addresses in the prefix."
> 	• "After the subscriber received the RA, and the associated flags, it will assign itself a 128 bit IPv6 address using SLAAC." should read "After the subscriber received the RA, and the associated flags, it will assign itself one or more 128-bit IPv6 addresses using SLAAC.”

I agree with these changes as they emphasise the multiple address per host property, when the document talks of addresses (plural) elsewhere. And s/received/receives.

There’s a third place to also make such a change”
* change "allow broadest support on connected devices to receive a valid IPv6 address” to "allow broadest support on connected devices to receive valid IPv6 addresses"

> 2. Thanks for adding text to section 5 addressing the concern about RAs expiring. One thing I think is not covered is: current Android devices will actually disconnect when their IPv6 address becomes deprecated. So you might want to set the preferred lifetime to 3600s as well.
> 
> I would also suggest: given that 514 and 686 look like strange numbers, just mention that these numbers result in an average RA interval of 600s. :-)

The maths would be cleaner with 6 RAs per hour in RFC7772 rather than 7 RAs :)

The only other two comments I’d have now we seem to have the document close to publication are

1. The document only mentions SLAAC RFC4862 [RFC4862]; should it mention RFC 7217, given that is now the recommended way to do SLAAC?

2. At the start of section 4, it says the UE when attaching will use RFC8106 to learn DNS addresses. Elsewhere in the doc stateless DHCPv6 is stated as an option (O flag = 1); should stateless DHCPv6 be mentioned here as well, or is this as intended?  Given the document speaks of IPv6-only deployment, and discusses why SLAAC is recommended over DHCPv6 IA_NA) it would be good to be clear on where/whether stateless DHCPv6 support is required.

Tim

> Cheers,
> Lorenzo
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops