Subject: [v6ops] regarding draft-ietf-v6ops-unique-ipv6-prefix-per-host [WAS: Re: [ALU] Re: multiple-ipv6-prefixes-per-host]

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

The draft draft-ietf-v6ops-unique-ipv6-prefix-per-host is addressing a application realm as mentioned in the abstract. It is not trying to address all types of devices and all use-case scenario’s. I am sure that the proposed does not address all different permutations of address related requirements, but for the application realm intended for the document it offers a perfectly reasonable approach. Please do not extend the use-case domain to include CPE’s etc…

When looking at the draftabstract as shown below, it seems that the application realm is really well documented and 
clear, not? … From re-reading it there seems little room for confusion on what/where and how:

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

Next:
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 full abstract can be found below, and clearly identifies the application domain for this draft… 

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.

Be well,
G/

On 13/03/2017, 17:19, "Alexandre Petrescu" <[email-masked]> wrote:

    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:
    >
    > 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:
    >> 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
    >
    > Le 13/03/2017 à 05:09, [email-masked] a écrit :
    >>
    >> 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/
    >>
    >> _______________________________________________ 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: Alexandre Petrescu <[email-masked]>
Date: Mon, 13 Mar 2017 17:53:53 +0100

How is this draft helping deployment of DHCPv6 Prefix Delegation?

How is this draft delaying deployment of DHCPv6 Prefix Delegation?

Alex