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

From: [email-masked]
Date: Sun, 12 Mar 2017 21:09:31 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations 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-02.txt
	Pages           : 8
	Date            : 2017-03-12

Abstract:
   In some IPv6 environments the need has arisen for hosts to be able to
   utilise a unique IPv6 prefix even though the link or media may be
   shared.  Typically hosts (subscribers) on a shared network, either
   wired or wireless, such as Ethernet, WiFi, etc., will acquire unique
   IPv6 addresses from a common IPv6 prefix that is allocated or
   assigned for use on a specific link.

   In most deployments today IPv6 address assignment from a single IPv6
   prefix on a shared network is done by either using IPv6 stateless
   address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
   this is still viable and operates as designed there are some large
   scale environments where this concept introduces significant
   performance challenges and implications, specifically related to IPv6
   router and neighbor discovery.

   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 a unique
   IPv6 prefix compared to a unique IPv6 address from the service
   provider are going from improved subscriber isolation to enhanced
   subscriber management.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-02

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

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: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 13 Mar 2017 13:14:24 +0000

Given that each UE gets a unique /64 prefix, it should be reasonable to not mandate UE to do DAD by default (and rather be left optional, depending on the deployment needs). 

DAD would fail only if /64 prefix assigned to the UE wasn’t unique, in which case, any/every address formulated by the UE would continue to fail.  But if the assumption is that each prefix is unique, then there is no point in exposing the entire shared network with the DAD messages from every UE for every address. We gain _nothing_.

IMO, if the assumption is invalid, then this should really call for DPD (Duplicate Prefix Detection), not DAD. ☺ Topic for another draft, I suppose.

-- 
Cheers,
Rajiv  

Section 4…
//
The architected result of designing the RA as documented above is
   that each UE/subscriber gets its own unique /64 IPv6 prefix ..
//
….Now that the UE/subscriber received the RA and the associated flags,
   it will assign itself a 128 bit IPv6 address using SLAAC.  Since the
   address is composed by the UE/subscriber device itself it will need
   to verify that the address is unique on the shared network.
//

-----Original Message-----
From: v6ops <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, March 13, 2017 at 12:09 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [v6ops] I-D Action:	draft-ietf-v6ops-unique-ipv6-prefix-per-host-02.txt

    
    Abstract:

    

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 Mar 2017 14:28:23 +0100 (CET)

> IMO, if the assumption is invalid, then this should really call for DPD (Duplicate Prefix Detection), not DAD. ☺ Topic for another draft, I suppose.

We, the authors of

https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-01

believe we're trying to address this use-case. This is done in 6MAN. If 
you're interested, please show support there.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 13 Mar 2017 14:38:54 +0100

Terminology: you are using the term "user equipment (UE)" in the document.

That is a 3GPP term.  WiFi hotspots dont say "UE" but rather "Clients" 
or "STAs".

Using "UE" makes think that the cellular network should give a Unique 
IPv6 Prefix per Host.  And that is wrong.  There should be more, even 
though each could be unique in terms of scope.

Also, you are using the term "subscriber".  That again is a 
Home-specific, or cellular-specific term.  It is not a WiFi term.

And there again it is wrong to assign a Unique IPv6 Prefix per Host. 
There should be more.

Finally, you are saying:
>    that each UE/subscriber gets its own unique /64 IPv6 prefix

This is wrong.  That prefix should not be limited to being only a /64. 
It could be a /63 or a /65.

Only if you are sure that this BCP is going to be used on Ethernet can 
you limit its scope to /64.

Alex

Le 13/03/2017 à 05:09, [email-masked] a écrit :
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Mon, 13 Mar 2017 14:05:36 +0000

I believe that consistent terminology for identifying a device that is connected. In our case we choose UE (User Equipment).
It does not feel incorrect to me, particular knowing that in many situation this is used in community Wifi (or even LAN) use-case scenario’s, and there we actually do speak about UEs.
(in case of tiny home Wifi installations it is wifi clients indeed, but in that case the security and operational requirements are totally different also)

The size /64 was selected because that is what most UEs seem to expect and behave correctly with, from address assignment perspective. Deviating from this does not seem something that is promoted often and opens a can of worms regarding the perfect size of prefix length. It seems that for Community LAN/Wifi networks selecting /64 is a very reasonable choice.

G/

On 13/03/2017, 14:38, "v6ops on behalf of Alexandre Petrescu" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 13 Mar 2017 17:19:49 +0100

Hi,

Please let me clarify.

Le 13/03/2017 à 15:05, Van De Velde, Gunter (Nokia - BE) a écrit :
> I believe that consistent terminology for identifying a device that
> is connected. In our case we choose UE (User Equipment). It does not
> feel incorrect to me, particular knowing that in many situation this
> is used in community Wifi (or even LAN) use-case scenario’s, and
> there we actually do speak about UEs. (in case of tiny home Wifi
> installations it is wifi clients indeed, but in that case the
> security and operational requirements are totally different also)

In case of home networks: do you consider assigning a single /64 to a home?

> The size /64 was selected because that is what most UEs seem to
> expect and behave correctly with, from address assignment
> perspective.

An end device yes, acts perfectly when it receives a /64.

But typical Smartphones, tablets, Personal Computers have multiple
interfaces.  They are not end devices.  They need to receive a /60 on
one side and deliver /64s on the other side.

SmartPhone plus SmartWatch can not work if all the Smartphone gets is a
single /64.

> Deviating from this does not seem something that is promoted often
> and opens a can of worms regarding the perfect size of prefix length.
> It seems that for Community LAN/Wifi networks selecting /64 is a very
> reasonable choice.

If a Hotspot Router receives a /64 then it will have a hard time
offering another /64 to the WiFi Clients that connect to it.

Yours,

Alex

>
> G/
>
>
>
> On 13/03/2017, 14:38, "v6ops on behalf of Alexandre Petrescu"
> <[email-masked] on behalf of [email-masked]>
> wrote:
>
> That is a 3GPP term.  WiFi hotspots dont say "UE" but rather
> "Clients" or "STAs".
>
> Using "UE" makes think that the cellular network should give a
> Unique IPv6 Prefix per Host.  And that is wrong.  There should be
> more, even though each could be unique in terms of scope.
>
> This is wrong.  That prefix should not be limited to being only a
> /64. It could be a /63 or a /65.
>
> Only if you are sure that this BCP is going to be used on Ethernet
> can you limit its scope to /64.
>
> Alex
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the IPv6 Operations 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-02.txt Pages : 8 Date
>> : 2017-03-12
>>
>> Abstract: In some IPv6 environments the need has arisen for hosts
>> to be able to utilise a unique IPv6 prefix even though the link or
>> media may be shared.  Typically hosts (subscribers) on a shared
>> network, either wired or wireless, such as Ethernet, WiFi, etc.,
>> will acquire unique IPv6 addresses from a common IPv6 prefix that
>> is allocated or assigned for use on a specific link.
>>
>> In most deployments today IPv6 address assignment from a single
>> IPv6 prefix on a shared network is done by either using IPv6
>> stateless address auto-configuration (SLAAC) and/or stateful
>> DHCPv6.  While this is still viable and operates as designed there
>> are some large scale environments where this concept introduces
>> significant performance challenges and implications, specifically
>> related to IPv6 router and neighbor discovery.
>>
>> 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 a unique IPv6 prefix compared to a unique IPv6 address
>> from the service provider are going from improved subscriber
>> isolation to enhanced subscriber management.
>>
>>
>> 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.
>>
>> _______________________________________________ I-D-Announce
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 13 Mar 2017 17:26:18 +0100

> On Mar 13, 2017, at 5:19 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> Please let me clarify.
> 

A /60 may well be too small. Please stop placing such arbitrary limits
in places where they are not necessary and may be harmful.

> SmartPhone plus SmartWatch can not work if all the Smartphone gets is a

Depends. If SmartPhone acts as bridge/l2 switch, then no problem. If it
acts as router, then perhaps no problem depending on parameters.

However, definitely not ideal.

> offering another /64 to the WiFi Clients that connect to it.

True, but it can bridge the same /64 to wifi or split the /64 into arbitrary
chunks of smaller sizes (though as stated above, this is not desirable).

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 13 Mar 2017 17:53:04 +0100

Le 13/03/2017 à 17:26, Owen DeLong a écrit :
>>> I believe that consistent terminology for identifying a device
>>> that is connected. In our case we choose UE (User Equipment). It
>>>  does not feel incorrect to me, particular knowing that in many
>>> situation this is used in community Wifi (or even LAN) use-case
>>> scenario’s, and there we actually do speak about UEs. (in case of
>>> tiny home Wifi installations it is wifi clients indeed, but in
>>> that case the security and operational requirements are totally
>>> different also)
>>
>> interfaces.  They are not end devices.  They need to receive a /60
>> on one side and deliver /64s on the other side.
>
> A /60 may well be too small. Please stop placing such arbitrary
> limits in places where they are not necessary and may be harmful.
>
>>
>> SmartPhone plus SmartWatch can not work if all the Smartphone gets
>>  is a single /64.
>
> Depends. If SmartPhone acts as bridge/l2 switch, then no problem.

SmartPhone can not bridge between WiFi and Bluetooth because there is no
such bridging technology.

> If it acts as router, then perhaps no problem depending on
> parameters.
>
>>> Deviating from this does not seem something that is promoted
>>> often and opens a can of worms regarding the perfect size of
>>> prefix length. It seems that for Community LAN/Wifi networks
>>> selecting /64 is a very reasonable choice.
>>
> True, but it can bridge the same /64 to wifi

Bridging can only happen between compatible technologies.  They form a
subset dominated by Ethernet, but in which cellular, Bluetooth and USB
are absent.  I.e. can't bridge between cellular and Ethernet for example.

> or split the /64 into arbitrary chunks of smaller sizes (though as
> stated above, this is not desirable).

I agree.

Whereas it is possible to make two /65s out of a /64, no end device can
use a /65 to SLAAC an address.

Alex

>>> <[email-masked] on behalf of
>>> [email-masked]> wrote:
>>>
>>> Unique IPv6 Prefix per Host.  And that is wrong.  There should
>>> be more, even though each could be unique in terms of scope.
>>>
>>> And there again it is wrong to assign a Unique IPv6 Prefix per
>>> Host. There should be more.
>>>
>>> Finally, you are saying:
>>>> The architected result of designing the RA as documented above
>>>>  is that each UE/subscriber gets its own unique /64 IPv6
>>>> prefix
>>>
>>> This is wrong.  That prefix should not be limited to being only
>>> a /64. It could be a /63 or a /65.
>>>
>>> Only if you are sure that this BCP is going to be used on
>>> Ethernet can you limit its scope to /64.
>>>
>>> Alex
>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> IPv6 Operations 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-02.txt Pages : 8
>>>> Date : 2017-03-12
>>>>
>>>> Abstract: In some IPv6 environments the need has arisen for
>>>> hosts to be able to utilise a unique IPv6 prefix even though
>>>> the link or media may be shared.  Typically hosts (subscribers)
>>>> on a shared network, either wired or wireless, such as
>>>> Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a
>>>> common IPv6 prefix that is allocated or assigned for use on a
>>>> specific link.
>>>>
>>>> In most deployments today IPv6 address assignment from a
>>>> single IPv6 prefix on a shared network is done by either using
>>>> IPv6 stateless address auto-configuration (SLAAC) and/or
>>>> stateful DHCPv6.  While this is still viable and operates as
>>>> designed there are some large scale environments where this
>>>> concept introduces significant performance challenges and
>>>> implications, specifically related to IPv6 router and neighbor
>>>> discovery.
>>>>
>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>> address from the service provider are going from improved
>>>> subscriber isolation to enhanced subscriber management.
>>>>
>>>>
>>>> submission until the htmlized version and diff are available
>>>> at tools.ietf.org.
>>>>
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>