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

From: [email-masked]
Date: Mon, 18 Sep 2017 11:17:57 -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-10.txt
	Pages           : 9
	Date            : 2017-09-18

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-10
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10

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

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: Mon, 18 Sep 2017 18:27:15 +0000

@all, this version should now have all agreed changes as discussed vividly during in last few weeks at v6ops.

G/

On 18/09/2017, 20:17, "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: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Sep 2017 18:47:14 +0000

Hi Gunter,

I think the document could benefit from adding the following text:

  "After advertising the prefix, the router can regard the prefix as either on-link or
    not on-link. If on-link, the router performs address resolution for IPv6 destinations
    that match the prefix and follows [RFC4443] procedures for returning Destination
    Unreachable messages if address resolution fails. This protects the host from
    receiving unwanted packets for IPv6 addresses that the host is not currently using,
    but requires the router to maintain state. If not on-link, the router unconditionally
    delivers all packets for IPv6 destinations that match the prefix to the host, where
    the host will silently drop any packets that do not match one of its configured
    addresses. This allows the router to remain stateless, but can deliver unwanted
    packets to the host even if the host is using techniques such as IPv6 privacy
    addressing [RFC4941][RFC7721] in an attempt to avoid the same."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
> Sent: Monday, September 18, 2017 11:27 AM
> To: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt
> 
>

---

From: David Farmer <[email-masked]>
Date: Mon, 18 Sep 2017 14:28:21 -0500

LGTM!

On Mon, Sep 18, 2017 at 1:27 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> On 18/09/2017, 20:17, "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
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Sep 2017 13:31:17 +1200

Works for me, thanks.

Regards
   Brian

On 19/09/2017 06:27, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> .

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Sep 2017 10:48:04 +0900

We still need to address the issue of the RA lifetimes in the presence of
mobile devices that drop multicast packets.

If the RA interval is set to 600s (recommended by 7772), and devices drop
2/3 multicast packets, then 29% of the time, after 30 minutes the device's
IPv6 addresses will be deprecated and the device will start preferring IPv4
over IPv6.

---

From: Tony Li <[email-masked]>
Date: Mon, 18 Sep 2017 19:22:03 -0700

Seems to me that if something is experiencing 66% packet loss for 30 minutes that it should prefer disconnection. That’s wholly unusable…

Tony

> On Sep 18, 2017, at 6:48 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> We still need to address the issue of the RA lifetimes in the presence of mobile devices that drop multicast packets.
> 
> If the RA interval is set to 600s (recommended by 7772), and devices drop 2/3 multicast packets, then 29% of the time, after 30 minutes the device's IPv6 addresses will be deprecated and the device will start preferring IPv4 over IPv6.
> 
> On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 18/09/2017, 20:17, "v6ops on behalf of [email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/>
> 
>     https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 <https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10>
>     https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10>
> 
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 <https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-10>
> 
> 
>     until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
>     ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 18 Sep 2017 19:26:13 -0700

And yet, the reality is that lots of mobile devices listen to only one out
of X wifi multicast/broadcast packets when the screen is off.

I would suggest trying it on your phone and see what it does.

On Mon, Sep 18, 2017 at 7:22 PM, Tony Li <[email-masked]> wrote:

>
> Seems to me that if something is experiencing 66% packet loss for 30
> minutes that it should prefer disconnection. That’s wholly unusable…
>
> Tony
>
>
> On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]> wrote:
>
>>
>> @all, this version should now have all agreed changes as discussed
>> vividly during in last few weeks at v6ops.
>>
>> G/
>>
>>
>>

---

From: David Farmer <[email-masked]>
Date: Mon, 18 Sep 2017 22:05:36 -0500

However, in this case the RAs are not Multicast, at least at the
link-layer. So, RA reception should be much less of a problem. That's not
to say the recommended RA lifetimes shouldn't be adjusted appropriately
though.

On Mon, Sep 18, 2017 at 9:26 PM, Lorenzo Colitti <[email-masked]> wrote:

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 19 Sep 2017 06:52:00 +0000

Yep, thanks Gunter.

Tim

> On 19 Sep 2017, at 02:31, Brian E Carpenter <[email-masked]> wrote:
> 
> Works for me, thanks.
> 
> Regards
>   Brian
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Sep 2017 16:05:29 +0900

True. Should the draft note that sending RAs unicast helps ensure that they
are received on devices that drop multicast, or is that problem too
specific to current implementations? (Though I don't see this changing any
time soon...)

On Tue, Sep 19, 2017 at 12:05 PM, David Farmer <[email-masked]> wrote:

>> And yet, the reality is that lots of mobile devices listen to only one
>> out of X wifi multicast/broadcast packets when the screen is off.
>>
>>> We still need to address the issue of the RA lifetimes in the presence
>>> of mobile devices that drop multicast packets.
>>>
>>> If the RA interval is set to 600s (recommended by 7772), and devices
>>> drop 2/3 multicast packets, then 29% of the time, after 30 minutes the
>>> device's IPv6 addresses will be deprecated and the device will start
>>> preferring IPv4 over IPv6.
>>>
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>       Phone: 612-626-0815

---

From: Tim Chown <[email-masked]>
Date: Tue, 19 Sep 2017 09:38:07 +0000

So RFC7772 suggests that 600s is a reasonable frequency for RAs (it says 7 RAs per hour in Section 4).

But draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn’t include the other advice in that Section for default lifetimes (5-10 times the RA period).  

Given RFC7772 is a BCP, any specific settings given in draft-ietf-v6ops-unique-ipv6-prefix-per-host should follow that guidance, shouldn’t it?  As it stands, only the RA frequency part of RFC7772 is included, not the lifetime guidance.  It seems that draft-ietf-v6ops-unique-ipv6-prefix-per-host chooses not to follow the guidance because “to reduce undesired resource consumption, such as in the case of WiFi hotspots, is to remove subscriber context as quickly as possible when a device or subscriber becomes non-active.”  I’d certainly prefer to see the tradeoff favouring the user another device.

Tim 

> On 19 Sep 2017, at 02:48, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Sep 2017 11:56:47 +0200

Tim,

> So RFC7772 suggests that 600s is a reasonable frequency for RAs (it says 7 RAs per hour in Section 4).

It's difficult to see that 7772 is directly applicable. Given that this unique-prefix uses L2 unicast not multicast.
It would be interesting to see the same measurement being done on unique-prefix.

Barring actual science behind these recommendations I'd prefer that unique-prefix didn't recommend timers overriding 4861 at all.

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Sep 2017 20:45:34 +0900

On Sep 19, 2017 18:56, "Ole Troan" <[email-masked]> wrote:

It's difficult to see that 7772 is directly applicable. Given that this
unique-prefix uses L2 unicast not multicast.
It would be interesting to see the same measurement being done on
unique-prefix.

Why do you say 7772 is not applicable? The power numbers in that RFC
reflect only the power consumption of the CPU, not of the radio, so they
should be equally correct for unicast and multicast.

On 802.11, unicast is more expensive because the received unicast RA needs
to be ACKed.