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

From: [email-masked]
Date: Thu, 28 Sep 2017 04:42:43 -0700

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-prefix-per-host-11.txt
	Pages           : 9
	Date            : 2017-09-28

Abstract:
   This document outlines an approach utilising existing IPv6 protocols
   to allow hosts to be assigned a unique IPv6 prefix (instead of a
   unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
   IPv6 prefix over a unique service provider IPv6 address include
   improved host isolation and enhanced subscriber management on shared
   network segments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-11
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 28 Sep 2017 12:19:10 +0000

This latest version has few idnits and readability improvements.

G/

On 28/09/2017, 13:42, "v6ops on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

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

---

From: David Farmer <[email-masked]>
Date: Thu, 28 Sep 2017 09:08:59 -0500

I like most of the changes, however I find the following bullet somewhat
confusing;

o  Maximum IPv6 Router Advertisement Interval = 300s (or when battery
   consumption is a concern then a MinRtrAdvInterval of 514 seconds
   (1/7 of an hour) is better according RFC7772 [RFC7772]).

It starts out talking about the *Maximum* Router Advertisement Interval,
then with little explanation shifts to talking about the *Minimum* Router
Advertisement Interval, I fear this will easily confuse any casual
readers.  Furthermore, the IPv6 router implementations I'm familiar with,
don't allow you to directly set the Minimum Router Advertisement Interval,
it is automatically computed as 75% of the Maximum Router Advertisement
Interval, as recommended in RFC4861. Therefore, in such implementations the
Maximum Router Advertisement Interval would need to be set at 685 seconds.

Also, as Lorenzo pointed out, there is no discussion of IPv6 Router
LifeTime, which is also discussed in RFC7772.

I suggest the following;

o  Maximum IPv6 Router Advertisement Interval = 300s (or when battery
    consumption is a concern 685s, see Note below)

o  IPv6 Router LifeTime = 3600s (see Note below)

...

Note: When servicing large numbers of battery powered devices, RFC7772
recommends a maximum of 7 RAs per hour and a 45-90 minute IPv6 Router
Lifetime. To achieve a maximum of 7 RAs per hour a MinRtrAdvInterval of 514
seconds (1/7 of an hour) is needed, many router implementation determine
MinRtrAdvInterval = 0.75 * MaxRtrAdvInterval, as recommended in RFC4861
section 6.2.1. Therefore, a Maximum IPv6 Router Advertisement Interval of
685s is recommended. As for the recommended IPv6 Router Lifetime, since
this technique requires that the RAs are sent using the link-layer unicast
address of the subscriber, the concerns over multicast delivery discussed
in RFC7772 are already mitigated, therefore the above suggestion of 3600s
(an hour) is deemed sufficient for this use case.

Thanks.

On Thu, Sep 28, 2017 at 7:19 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> On 28/09/2017, 13:42, "v6ops on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Sep 2017 10:00:32 -0700

> On Sep 28, 2017, at 7:08 AM, David Farmer <[email-masked]> wrote:
> 
> I like most of the changes, however I find the following bullet somewhat confusing;
> 
> It starts out talking about the *Maximum* Router Advertisement Interval, then with little explanation shifts to talking about the *Minimum* Router Advertisement Interval, I fear this will easily confuse any casual readers.  Furthermore, the IPv6 router implementations I'm familiar with, don't allow you to directly set the Minimum Router Advertisement Interval, it is automatically computed as 75% of the Maximum Router Advertisement Interval, as recommended in RFC4861. Therefore, in such implementations the Maximum Router Advertisement Interval would need to be set at 685 seconds.
> 
> Also, as Lorenzo pointed out, there is no discussion of IPv6 Router LifeTime, which is also discussed in RFC7772.

The bit about the inter-router-advertisement interval was at my suggestion. Lorenzo had complained that the draft didn't do anything to meet RFC 7772. That was changed somewhere between -07 and -10. However, it resulted in only specifying MaxRtrAdvInterval. If we want to have no more than seven RAs per hour (per RFC 7772), it is MinRtrAdvInterval that is important. 514=3600/7, hence the specification of MinRtrAdvInterval.

May I suggest you suggest text? What would you like it to say?

---

From: David Farmer <[email-masked]>
Date: Thu, 28 Sep 2017 16:40:38 -0500

On Thu, Sep 28, 2017 at 12:00 PM, Fred Baker <[email-masked]>
wrote:

> The bit about the inter-router-advertisement interval was at my
> suggestion. Lorenzo had complained that the draft didn't do anything to
> meet RFC 7772. That was changed somewhere between -07 and -10. However, it
> resulted in only specifying MaxRtrAdvInterval. If we want to have no more
> than seven RAs per hour (per RFC 7772), it is MinRtrAdvInterval that is
> important. 514=3600/7, hence the specification of MinRtrAdvInterval.
>

I did suggest some text, but I didn't correctly remembered what RFC4861
says, so how about this;

o  Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = 300s
(or when battery
    consumption is a concern 686s, see Note below)

...

Note: When servicing large numbers of battery powered devices, RFC7772
suggests a maximum of 7 RAs per hour and a 45-90 minute IPv6 Router
Lifetime. To achieve a maximum of 7 RAs per hour, the Minimum IPv6 Router
Advertisement Interval (MinRtrAdvInterval) is the important parameter, and
MUST be greater than or equal to 514 seconds (1/7 of an hour). Further as
discussed in RFC4861 section 6.2.1, MinRtrAdvInterval <= 0.75 *
MaxRtrAdvInterval, therefore MaxRtrAdvInterval MUST additionally be greater
than or equal to 686 seconds. As for the recommended IPv6 Router Lifetime,
since this technique requires that RAs are sent using the link-layer
unicast address of the subscriber, the concerns over multicast delivery
discussed in RFC7772 are already mitigated, therefore the above suggestion
of 3600 seconds (an hour) seems sufficient for this use case.

This keeps the table compact and easily understandable, providing the
details in a paragraph following the table.

Thanks.