Subject: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 20 Oct 2015 18:35:57 +0000

Posted yesterday. Your comment solicited.

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
> Date: October 19, 2015 at 12:50:01 PM PDT
> To: <[email-masked]>
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Unique IPv6 Prefix Per Host
>        Authors         : John Jason Brzozowski
>                          Gunter Van De Velde
> 	Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
> 	Pages           : 14
> 	Date            : 2015-10-19
> 
> 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, like Wi-
>   Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
>   prefix that is allocated or assigned for use on a specific link.
>   Benefits of a unique IPv6 prefix compared to a unique IPv6 address
>   from the service provider are going from enhanced subscriber
>   management to improved isolation between subscribers.
> 
>   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).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-host/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00
> 
> 
> 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

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 20 Oct 2015 20:52:22 -0400

John/Gunter,

Overall, good draft, well explained case and detailed explanation of 
deployment.

On to comment...

Based on this text .. "The /64
    prefix can be derived from a locally managed pool or aggregate IPv6
    block assigned to the WLAN-GW or from a pool signalled by the Radius
    server in a radius attribute."

Its seems clear that the /64s would come from a pool and/or block as you 
noted.

I would think that under the operational considerations section we would 
want to add some text that notes the management requirements to 
size/manage those blocks/pools.  Under a traditional case, with a /64 
per WLAN-GW, the number of addresses that can be consumed by that one 
/64 would not require management.

However, in this case, it's possible to exhaust the #  of blocks. If the 
WLAN-GW is L3, then in large venues - say stadiums or open areas, sizing 
for peak demand periods would need to be considered as well.  
Sizing/management is likely not as much of an issue in the "coffee shop" 
deployment instance.

The text need not be complicated, but should note that some attention / 
management is required.

regards,

Victor K

On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 21 Oct 2015 01:30:56 +0000

Thanks Victor.  I will confer with Gunter on some text.

As an aside I view the WLAN-GW as I would a CMTS in DOCSIS networks.  The WLAN-GW IPv6 capacity would have to be managed similar to how we manage block sizes for prefix delegation.  The parent IPv6 block would have to be able to a accommodate the overall capacity of the WLAN-GW.

Once a WLAN-GW reaches capacity either from a bandwidth point of view, IPv6 prefixes, etc. the WLAN-GW split would need to occur.

One more note, the WLAN-GW would only advertise the parent IPv6 block to avoid route table bloat.  Perhaps this should be listed as another operational consideration.

John
+1-484-962-0060

On Oct 20, 2015, at 20:52, Victor Kuarsingh <[email-masked]<mailto:[email-masked]>> wrote:

John/Gunter,

Overall, good draft, well explained case and detailed explanation of deployment.

On to comment...

Its seems clear that the /64s would come from a pool and/or block as you noted.

I would think that under the operational considerations section we would want to add some text that notes the management requirements to size/manage those blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, the number of addresses that can be consumed by that one /64 would not require management.

However, in this case, it's possible to exhaust the #  of blocks.  If the WLAN-GW is L3, then in large venues - say stadiums or open areas, sizing for peak demand periods would need to be considered as well.  Sizing/management is likely not as much of an issue in the "coffee shop" deployment instance.

The text need not be complicated, but should note that some attention / management is required.

regards,

Victor K

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Date: October 19, 2015 at 12:50:01 PM PDT
To: <[email-masked]><mailto:[email-masked]>
Reply-To: [email-masked]<mailto:[email-masked]>

Abstract:

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<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

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

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

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 20 Oct 2015 21:41:09 -0400

On 2015-10-20 9:30 PM, Brzozowski, John wrote:
>
> As an aside I view the WLAN-GW as I would a CMTS in DOCSIS networks. 
>  The WLAN-GW IPv6 capacity would have to be managed similar to how we 
> manage block sizes for prefix delegation.  The parent IPv6 block would 
> have to be able to a accommodate the overall capacity of the WLAN-GW.
>
Yes, that makes sense.

>
> One more note, the WLAN-GW would only advertise the parent IPv6 block 
> to avoid route table bloat.  Perhaps this should be listed as another 
> operational consideration.
Good point. Text saying that would help to ensure the practice is clear.

regards,

Victor K

>> I would think that under the operational considerations section we 
>> would want to add some text that notes the management requirements to 
>> However, in this case, it's possible to exhaust the #  of blocks.  If 
>> the WLAN-GW is L3, then in large venues - say stadiums or open areas, 
>> sizing for peak demand periods would need to be considered as well.  
>> Sizing/management is likely not as much of an issue in the "coffee 
>> shop" deployment instance.
>>
>>
>>>> From:[email-masked]
>>>> To:<[email-masked]>
>>>> Reply-To:[email-masked]
>>>>
>>>>
>>>> until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>>>>
>>>> Internet-Draft directories:http://www.ietf.org/shadow.html
>>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Oct 2015 14:38:23 +0000

Hi, what this draft is discussing is already covered in AERO, where DHCPv6 PD is
used to delegate a unique IPv6 prefix per host. Please refer to that document:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

AERO has been presented at the past 4 IETFs in the dmm working group
(charts available in proceedings). From some of the recent discussions on
multi-addressing and prefix delegation it sounds like it should also be
presented in v6ops.

Thanks - Fred
[email-masked]

From: v6ops [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Tuesday, October 20, 2015 6:31 PM
To: Victor Kuarsingh
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

John
+1-484-962-0060

On to comment...

regards,

Victor K

Begin forwarded message:

                         Gunter Van De Velde

    Pages           : 14

    Date            : 2015-10-19

Abstract:

  IPv6 prefix).

v6ops mailing list

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 21 Oct 2015 15:45:31 +0000

Fred,

Replying here instead of off list.  I took a quick look at the draft and admit there are some aspects of the draft that seem similar to what we have done.  However, there is a lot more to AERO than what we need.  We utilize existing protocols and developed no extensions to the same, there seems to be some new development related to AERO.

Our approach for PD, which is a futures item is basically what we know today for PD, RFC3633.  We saw no need to reinvent the wheel nor do we intend to.

I look forward to hearing more about AERO, its use cases, and available implementations in Yokohama.

John
+1-484-962-0060

From: Fred Templin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 21, 2015 at 10:38
To: John Jason Brzozowski <[email-masked]<mailto:[email-masked]>>, Victor Kuarsingh <[email-masked]<mailto:[email-masked]>>
Cc: v6ops <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

Thanks – Fred
[email-masked]<mailto:[email-masked]>

From: v6ops [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Tuesday, October 20, 2015 6:31 PM
To: Victor Kuarsingh
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

John
+1-484-962-0060

On to comment...

regards,

Victor K

Begin forwarded message:

                         Gunter Van De Velde

    Pages           : 14

    Date            : 2015-10-19

Abstract:

  IPv6 prefix).

v6ops mailing list

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Oct 2015 17:35:18 +0000

Hi John,

At its core, AERO is about DHCPv6 Prefix Delegation over tunnels. A way to get a prefix
to a fixed or mobile device that the device can use to either number its downstream
attached networks, or to assign one or more addresses to the interface over which
the prefix delegation was received (or both). DHCPv6 prefix delegation over tunnels
is very similar to the way it works over an ordinary interface, but there are several
implementation details – AERO specifies those.

AERO also includes IPv6 ND functions to support route optimization. These functions
need not be employed when the end user device can remain tethered to its server
(i.e., the node that provided the prefix delegation). AERO mobility also is optional
if the device that receives the delegated prefix is a fixed node. But, mobility is
based on standard DHCPv6 messaging so it is always available if needed.

AERO is currently running on linux and Android. The linux implementation has been
announced on other IETF lists, and is available for public access:

https://mailarchive.ietf.org/arch/msg/int-area/4Pqp6NYZIkBYn5xZILN7kQQqDHU

I would be happy to discuss any of this at the upcoming meeting.

Thanks – Fred

From: Brzozowski, John [mailto:[email-masked]]
Sent: Wednesday, October 21, 2015 8:46 AM
To: Templin, Fred L; Victor Kuarsingh
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

Fred,

John
+1-484-962-0060

Thanks – Fred

John
+1-484-962-0060

On to comment...

regards,

Victor K

Begin forwarded message:

                         Gunter Van De Velde

    Pages           : 14

    Date            : 2015-10-19

Abstract:

  IPv6 prefix).

v6ops mailing list

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 21 Oct 2015 14:47:26 -0400

WG Chairs,

I would be interested in discussing this topic.  Since this draft documents a real world IPv6 deployment and a real world solution,  I think it has value.  WiFi deployments are growing in number,  so it's timely.

I also think the notion of using existing protocols and working models is of importance and relevance in the operator space.

The flow through conversation in how this topic intersects with AERO is also of interest.

Regards,

Victor K

Sent from my iPhone

> On Oct 21, 2015, at 11:45, Brzozowski, John <[email-masked]> wrote:
> 
> Fred,
> 
> From: Fred Templin <[email-masked]>
> To: John Jason Brzozowski <[email-masked]>, Victor Kuarsingh <[email-masked]>
> Cc: v6ops <[email-masked]>
> On Oct 20, 2015, at 20:52, Victor Kuarsingh <[email-masked]> wrote:
> 
> John/Gunter,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Oct 2015 14:47:19 +0200

Hello,

Assigning a prefix-per-host in a WiFi deployment, rather than an 
individual addresses within a same prefix, has also been considered in 
Proxy Mobile IP deployments and it works ok.  It has some advantages, 
and some inconvenients, depending how it's done.

I have some comments on the draft.

draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
> If radius server discovers that the UE/ subscriber is a fresh device
> trying to gain access onto the Wi-Fi network it will identify some
> parameters (e.g.  IPv6 /64 prefix)
[...]
 > This RA contains a few important parameters for the EU/ subscriber to
 > consume: (1) a /64 prefix and (2) flags.

I would like to suggest to substitute /63 for /64 throughout the 
document.  A /64 will not allow smartphones to tether cleanly.

For a discussion of why 64 one can refer to RFC7521 "Analysis of 64 
boundary..."

For a discussion of why 63 - where to start?

draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>    The WLAN-GW will use the received Radius information to compose the
>    response to the UE/subscriber originated RS message.  The WLAN-GW
>    will answer using a unicast RA (Router Advertisement) to the UE/
>    subscriber.  This RA contains a few important parameters for the EU/
>    subscriber to consume: (1) a /64 prefix and (2) flags.

Since a captive portal is used, it would make sense to use the Captive 
Portal IPv6 RA Option as well (draft-wkumari-dhc-capport-16 LC'ed 
towards RFC end of September).

draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>    When a new UE connects to the community Wi-Fi it connects to the Wi-
>    Fi network by attaching to the relevant 'open' SSID advertised for
>    use as part of the community Wi-Fi offering.

But some community networks use a 'hidden' SSID, known only by members 
of that community.

Yours,

Alex

Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
>> From: [email-masked] Subject: I-D Action:
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date: October
>> 19, 2015 at 12:50:01 PM PDT To: <[email-masked]> Reply-To:
>> [email-masked]
>>
>>
>> Title           : Unique IPv6 Prefix Per Host Authors         :
>> John Jason Brzozowski Gunter Van De Velde Filename        :
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14 Date
>> : 2015-10-19
>>
>> 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, like Wi- Fi or Ethernet, will acquire unique IPv6
>> addresses from a common IPv6 prefix that is allocated or assigned
>> for use on a specific link. Benefits of a unique IPv6 prefix
>> compared to a unique IPv6 address from the service provider are
>> going from enhanced subscriber management to improved isolation
>> between subscribers.
>>
>> 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).
>>
>>
>> _______________________________________________ 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: "Brzozowski, John" <[email-masked]>
Date: Thu, 22 Oct 2015 13:15:26 +0000

Thanks for the comments, see below.

-----Original Message-----

From: v6ops <[email-masked]> on behalf of Alexandre Petrescu
<[email-masked]>
Date: Thursday, October 22, 2015 at 08:47
To: v6ops <[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action:
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

>document.  A /64 will not allow smartphones to tether cleanly.
[jjmb] I believe an RA with a PIO of a /63 will be problematic, we have
already tested the use of a /64 and will likely maintain this for our
deployment of IPv6 for community Wi-Fi.  For tethering over Wi-Fi our
expectation is that DHCPv6 PD would be utilized.
>towards RFC end of September).
[jjmb] we will take a look at this draft to determine applicability.  Stay
tuned.
>But some community networks use a 'hidden' SSID, known only by members
[jjmb] hidden should work as well, providing the end user knows the name
of the SSID.  We will look to see if there are clarifications we can make
to address this.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Oct 2015 15:25:46 +0200

Le 22/10/2015 15:15, Brzozowski, John a écrit :
>  <[email-masked]> Date: Thursday, October 22, 2015 at
> 08:47 To: v6ops <[email-masked]> Subject: Re: [v6ops] Fwd: I-D
> Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>
>> Hello,
>>
>> individual addresses within a same prefix, has also been
>> considered in Proxy Mobile IP deployments and it works ok.  It has
>> some advantages, and some inconvenients, depending how it's done.
>>
>>> If radius server discovers that the UE/ subscriber is a fresh
>>> device trying to gain access onto the Wi-Fi network it will
>>> identify some parameters (e.g.  IPv6 /64 prefix)
>> [...]
>>> This RA contains a few important parameters for the EU/
> [jjmb] I believe an RA with a PIO of a /63 will be problematic,

Why?

> we have already tested the use of a /64 and will likely maintain
> this for our deployment of IPv6 for community Wi-Fi.

Well it is good for that community.

In this respect, I dont think what the community uses should be an
example for other communities (a BCP).

I use 63 and works fine.

> For tethering over Wi-Fi our expectation is that DHCPv6 PD would be
> utilized.

I hear Android not supporting DHCP at this time, so PD would be a pain.

On another hand, just change 64 to 63 will make tethering smartphones
work fine without needing DHCP, nor DHCP-PD.

>>> The WLAN-GW will use the received Radius information to compose
>>> the response to the UE/subscriber originated RS message.  The
>>> WLAN-GW will answer using a unicast RA (Router Advertisement) to
>>> the UE/ subscriber.  This RA contains a few important parameters
>>> for the EU/ subscriber to consume: (1) a /64 prefix and (2)
>>> flags.
>>
>> Since a captive portal is used, it would make sense to use the
>> Captive Portal IPv6 RA Option as well
>> (draft-wkumari-dhc-capport-16 LC'ed towards RFC end of September).
> [jjmb] we will take a look at this draft to determine applicability.
> Stay tuned.
>>
>>> When a new UE connects to the community Wi-Fi it connects to the
>>> Wi- Fi network by attaching to the relevant 'open' SSID
>>> advertised for use as part of the community Wi-Fi offering.
>>
>> But some community networks use a 'hidden' SSID, known only by
>> members of that community.
> [jjmb] hidden should work as well, providing the end user knows the
> name of the SSID.  We will look to see if there are clarifications
> we can make to address this.

Ok.

Alex

>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date:
>>>> October 19, 2015 at 12:50:01 PM PDT To:
>>>> <[email-masked]> Reply-To: [email-masked]
>>>>
>>>>
>>>> Title           : Unique IPv6 Prefix Per Host Authors : John
>>>> Jason Brzozowski Gunter Van De Velde Filename        :
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14
>>>> Date : 2015-10-19
>>>>
>>>> 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, like Wi- Fi or Ethernet,
>>>> will acquire unique IPv6 addresses from a common IPv6 prefix
>>>> that is allocated or assigned for use on a specific link.
>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>> address from the service provider are going from enhanced
>>>> subscriber management to improved isolation between
>>>> subscribers.
>>>>
>>>> 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).
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per
>>>>
>>>>
>>>>
-host/
>>>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host
>>>>
>>>>
>>>>
-00
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>

---

From: [email-masked]
Date: Thu, 22 Oct 2015 15:46:27 +0200

Alex,

>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,

that would violate IPv6 standards. and common implementations don't support it either.

e.g.:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet6/nd6_rtr.c?rev=1.125&content-type=text/plain

                        /* aggregatable unicast address, rfc2374 */
			if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) == 0x20
			 && pi->nd_opt_pi_prefix_len != 64) {
				nd6log((LOG_INFO,
				    "nd6_ra_input: invalid prefixlen "
				    "%d for rfc2374 prefix %s, ignored\n",
				    pi->nd_opt_pi_prefix_len,
				    inet_ntop(AF_INET6, &pi->nd_opt_pi_prefix,
					src, sizeof(src))));
				continue;
			}

cheers,
Ole

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 22 Oct 2015 14:06:10 +0000

Ole responded to the use of the /63.

Regarding your use of this, I am curious which implementation and how many
devices are operating using a /63?

Finally, someone from Google/Android will have to comment on Android and
DHCPv6 for PD support.  I also believe Apple does not support PD yet on
their devices either.  Like the draft says this is future work, we will
see where this goes.

John
+1-484-962-0060

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Oct 2015 15:48:19 +0000

Hello,

> Sent: Thursday, October 22, 2015 7:06 AM
> To: Alexandre Petrescu
> Cc: [email-masked]

I have DHCPv6 PD client working on Android. It is just a few messages
in the AERO client app, and very simple. You don't even need to install
a DHCPv6 client package like what you get from ISC - the AERO client
app does all that is needed.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Oct 2015 16:12:23 +0000

Hello,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, October 22, 2015 5:47 AM
> To: [email-masked]

AERO can delegate any prefix length /64 or shorter. If the client is a host,
then /64 may be all that is necessary. If the client is a router, it might want
to get something shorter (e.g., /60, /56, etc.).

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Oct 2015 18:15:12 +0200

> Ole responded to the use of the /63.

Well.

> devices are operating using a /63?

If the goal is to minimize the importance of a small number of devices 
then the goal is reached.

The implementation is with linux, radvd software and a PMIP implementation.

The question of 63 is little dependent on PMIP.

If the question is about whether a Host can use SLAAC to self-configure 
an address out of a /63 then the answer is yes.  The implementation 
inserts a 0 at the 64th position.  Everybody does that, nobody inserts a 1.

Am I answering?

> their devices either.  Like the draft says this is future work, we will

Instead of further work we can just modify a number (64 to 63).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Oct 2015 18:30:03 +0200

> 			 && pi->nd_opt_pi_prefix_len != 64) {

That's a bug.  It should err on > 64 rather than on != 64.  It should 
not err on 63.

> 				    "%d for rfc2374 prefix %s, ignored\n",

RFC 2374 has some errors, or maybe people take it too much as a too good 
example.  For example, it gives an example of TLA and SLA ID lengths. 
But some people think they should be taken as such.  It is wrong, they 
are just examples.  They should not be hardcoded as we see in the code 
above.

The length of the TLA IDs and SLA IDs are subject of agreements between 
provider and consumer, they are far from being hardcoded.

I have been recently been allocated a /56 - that's not on a RFC2374 
boundary.  It is the boundary that I negotiated with the provider.  We 
could have agreed on 57 if we wanted to, but 56 sounded nicer.

> 				    pi->nd_opt_pi_prefix_len,

Why do we have a variable for prefix len if it errs on anything 
different than 64?

> 				    inet_ntop(AF_INET6, &pi->nd_opt_pi_prefix,

Instead of continuing it should fill 0s between the prefix len and 64. 
0s and not 1s.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 22 Oct 2015 18:49:25 +0200

Hi,

> That's a bug.  It should err on > 64 rather than on != 64.  It should 

No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for
nothing else.

If you believe a /63 is legal, show the relevant RFC that explains how
SLAAC is done for non-/64 cases.

[..]
> could have agreed on 57 if we wanted to, but 56 sounded nicer.

PD size and on-link *prefix* size are totally different things.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Oct 2015 18:56:54 +0200

> No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for

No no, SLAAC RFC is not defined for any particular length.

_Ethernet_ IID length in RFC2464 is defined to be 64.

> SLAAC is done for non-/64 cases.

I believe /63 prefixlength is legal yes.

SLAAC is done for any  length, the doc does not say 64.

The question that can be made is when SLAACing an Ethernet Interface ID 
with a /63 prefix - what to put at position 64?  0 or 1?  There is no 
specification for that.  The implementations I have seen put 0.  Do you 
believe there should be 1 instead?  Why?

> PD size and on-link *prefix* size are totally different things.

I agree.  But neither RFC2374 nor my /56 allocation is an on-link prefix.

RFC 2374 says that the SLA-ID has a particular length, as much as it 
says the Interface ID has a particular length.

The SLA-ID is wrong compared to my /56 allocation.

Alex

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 22 Oct 2015 17:08:26 +0000

We can consider this for future work.

To date we have tested with a wide range of Android, Apple, and Windows
Wi-Fi enabled devices.  All have been verified and work properly, as such
we have not excluded any devices.  Our goal has been to be as inclusive as
possible.  What is documented is, in general, what will be rolled out.

John
+1-484-962-0060

-----Original Message-----
From: Alexandre Petrescu <[email-masked]>
Date: Thursday, October 22, 2015 at 12:15
To: John Jason Brzozowski <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action:

>>>>>>>https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix
>>>>>>>-p
>>>>>>> er
>>>>>>>
>>>>>>>
>>>>>>>
>>> -host/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-
>>>>>>>ho
>>>>>>> st
>>>>>>>
>>>>>>>
>>>>>>>
>>> -00
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 22 Oct 2015 17:12:08 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, October 22, 2015 12:57 PM
To: Gert Doering
Cc: [email-masked]; Brzozowski, John
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

>From RFC 4291, there is this text.

[For all unicast addresses, except those that start with the binary
 value 000, Interface IDs are required to be 64 bits long and to be
 constructed in Modified EUI-64 format.]

Hemant

---

From: Gert Doering <[email-masked]>
Date: Thu, 22 Oct 2015 19:28:19 +0200

Hi,

> No no, SLAAC RFC is not defined for any particular length.

That is the point: for any particular length, SLAAC is *not defined*.

> _Ethernet_ IID length in RFC2464 is defined to be 64.

... and for ethernet, with /64, it is.

> I believe /63 prefixlength is legal yes.

*show* the RFC that explains how it is done for non-/64 cases.

What you do in private is good for your amusement, but we do not want 
to know.

> believe there should be 1 instead?  Why?

It is not defined.  You can do whatever you want.  But a RFC-compliant
implementation will correctly refuse anything that is not a /64 unless
there is a documented standard to handle /63.

Not that it would make any sense at all to use anything larger (shorter
prefix) than a /64 on any sort of link, so this whole discussion is
totally moot in the first place.

[..]
> The SLA-ID is wrong compared to my /56 allocation.

Your allocation is an allocation, and not an on-link prefix.  So it does
not have any meaning for this discussion.

Gert Doering
        -- NetMaster

---

From: 神明達哉 <[email-masked]>
Date: Thu, 22 Oct 2015 10:43:35 -0700

At Thu, 22 Oct 2015 18:49:25 +0200,

> No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for

(maybe an off-topic in the main context but)

This is indeed a bug (or at the very least non-compliant), but I guess
we are conflating different subtle things here.

This OpenBSD implementation is buggy in that it rejects a prefix with
a length other than 64 bits both for SLAAC and for on-link
determination.  The latter is a violation against RFC4861 (or at least
something beyond RFC4861 describes).

Rejecting it for SLAAC is not necessarily incorrect, but hardcoding 64
in this context is probably not very clean, since, in theory, this can
be different for different types of links (btw RFC4862 clarifies the
relationship and possible "inconsistency" between SLAAC and address
architecture regarding the expected IID length).

A better reference of BSD variants on this point would be FreeBSD:
https://raw.githubusercontent.com/freebsd/freebsd/master/sys/netinet6/nd6_rtr.c

It doesn't have the above check in this function (nd6_ra_input()).  It
validates the prefix length only in the context of SLAAC, and in a
more generic way by avoiding hardcoding the magic number:

    /*
     * Address autoconfiguration based on Section 5.5.3 of RFC 2462.
     * Note that pr must be non NULL at this point.
     */
..
        /*
         * Prefix Length check:
         * If the sum of the prefix length and interface identifier
         * length does not equal 128 bits, the Prefix Information
         * option MUST be ignored.  The length of the interface
         * identifier is defined in a separate link-type specific
         * document.
         */
        ifidlen = in6_if2idlen(ifp);
...
        if (ifidlen + pr->ndpr_plen != 128) {
            nd6log((LOG_INFO,
                "prelist_update: invalid prefixlen "
                "%d for %s, ignored\n",
                pr->ndpr_plen, if_name(ifp)));
            goto end;
        }

Regarding the main context, I don't know how advertising /63 helps the
tethering scenario, btw.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 22 Oct 2015 10:54:09 -0700

At Thu, 22 Oct 2015 18:56:54 +0200,

> _Ethernet_ IID length in RFC2464 is defined to be 64.

So you are assuming the 64-bit IID in your scenario, right?  Then,

> SLAAC is done for any  length, the doc does not say 64.

no, this is not legal.  A prefix in an RA PIO whose A bit is 1 and
length is 64 on a link whose IID is supposed to be 64 bits violates
Section 5.5.3 d of RFC 4862:

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 22 Oct 2015 11:06:07 -0700

> Section 5.5.3 d of RFC 4862:

Oops, sorry, there was a very confusing typo: this should have been
"...and length is 63...".

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Oct 2015 10:40:40 +1300

>  constructed in Modified EUI-64 format.]

To be precise, that text is obsoleted by RFC 7136 (and rfc4291bis):
http://tools.ietf.org/html/rfc7136#section-5

Neverthless, the 64 bit length is *not* required by SLAAC. Rather, it's
a parameter for SLAAC. Any SLAAC code that treats it as a constant is faulty:
http://tools.ietf.org/html/rfc7421#section-1

But in reality, it's a parameter that's always set to 64. So for anything to
actually work, if you assign a /63 to a host, it will have to contain
extra logic to assign the two halves of that as two /64s, and to decide
which one to use.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2015 21:56:10 -0300

Hi, Brian,

On 10/22/2015 06:40 PM, Brian E Carpenter wrote:
> a parameter for SLAAC.

Well...this is kind of an artifact of the fact that SLAAC currently
requires that IIDs must be derived of an IEEE LAN MAC address.. hence
they have to be in MOdified EUI-64 format, and hence they must be 64
bit. -- I guess your argument was that it's not SLAAC but RFC4291 that
requires this?

> Any SLAAC code that treats it as a constant is faulty:

Well, If they do RFC7217, they do not need any extra logic ;-)

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Oct 2015 15:11:42 +1300

> bit. -- I guess your argument was that it's not SLAAC but RFC4291 that

Yes. So if you are writing "correct" SLAAC code it definitely needs to be a
variable that's initialised separately for each interface, and as it happens
will always be initialised to 64.

> Well, If they do RFC7217, they do not need any extra logic ;-)

Correct. There's a sneaky little "at least 64" in there which would
allow for generation of 65 bit IIDs, if anybody really tried to implement
a /63 subnet ;-)

    Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 23 Oct 2015 08:55:43 +0200

Hi,

> allow for generation of 65 bit IIDs, if anybody really tried to implement

Interesting RFC and code interpretations aside - could someone remind me
why a /63 would have any advances over a /64, like "the /64 is not big
enough"?

Gert Doering
        -- NetMaster

---

From: Tore Anderson <[email-masked]>
Date: Fri, 23 Oct 2015 09:48:44 +0200

* [email-masked]

> that would violate IPv6 standards. and common implementations don't

FWIW, Linux is the same:

if (pinfo->prefix_len == 64) {
	/* SLAAC stuff here */
	goto ok;
}
net_dbg_ratelimited("IPv6 addrconf: prefix with wrong length %d\n",
		    pinfo->prefix_len);

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c#n2418

Tore

---

From: [email-masked]
Date: Fri, 23 Oct 2015 10:03:40 +0200

Gert,

[changed subject]

> why a /63 would have any advances over a /64, like "the /64 is not big

I think people are trying to solve the problem of extending an existing network ad-hoc with more links. if that's for tethering or VMs.
possibly with or without the consent of the network operator. the latter case obviously being a tricky arms race.

I don't see how /63 in an RA would be any part of a solution to that problem obviously.

DHCP-PD, HNCP, bridging, NAT, sub-netting /64/proxy-ND/multilink subnets
anything I've forgotten from the potential solution space?

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 10:23:00 +0200

Yes, thanks.

As a network operator it is good to accommodate as many devices as 
possible and that goes way beyond the current smartphones like the ones 
you cite.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 10:23:08 +0200

> extra logic to assign the two halves of that as two /64s, and to decide

YEs, that is possible.

IT may also decide to not use any, but make two 65s out of it and use 
them in its LAN subnets.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 10:24:30 +0200

Le 22/10/2015 19:54, 神明達哉 a écrit :
> At Thu, 22 Oct 2015 18:56:54 +0200, Alexandre Petrescu
> <[email-masked]> wrote:
>
>>> No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and
>>> for nothing else.
>>
>>> If you believe a /63 is legal, show the relevant RFC that
>>> explains how SLAAC is done for non-/64 cases.
>>
> If the sum of the prefix length and interface identifier length does
> not equal 128 bits, the Prefix Information option MUST be ignored.

That is what the SLAAC RFC says, yes.

But more precisely, that is a requirement on the sum, not on the value
of _any_ of its parts.

Given a 63 prefix len to that sum, the IID length must be 65.  And that
IID len 65 is wrong compared to RFC2464/4191 requiring the IID len to be 64.

Can we conclude that because of that wrongness, the SLAAC RFC is wrong
with respect to RFC2464-RFC4191?  I dont think so.  Again because the
requirement in SLAAC RFC is on the _sum_ not on the value of the parts.

So, if we can't think that the SLAAC RFC is wrong with respect to
RFC4191-2464 for the IID length being 65, then we can think that is
wrong with respect to a prefix length being 63.  It's just the sum that
must be respected.

Alex

> -- JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 10:24:50 +0200

Le 23/10/2015 08:55, Gert Doering a écrit :
>> Correct. There's a sneaky little "at least 64" in there which
>> would allow for generation of 65 bit IIDs, if anybody really tried
>> to implement a /63 subnet ;-)
>
> Interesting RFC and code interpretations aside - could someone remind
> me why a /63 would have any advances over a /64, like "the /64 is not
> big enough"?

Hi Gert,

Let me start by a negation, as much as I dont like them.  We saw in
other discussions, the number in "/64" is not relevant to size or number
of devices.  Even if 2^64 looks like a big number, it does not mean we
can put that many devices in a subnet, obstacled by link layer
characteristics.

Then, using a "/63" rather than a "/64" prefix assigned (for a certain
interpretation of the word 'assigned') to a device may allow it to
tether cleanly: a smartphone receiving a /63 will be able to create two
"/64"s out of it.  It will 'assign' one so created '/64' for its
bluetooth interface and another one deeper in its LAN.

On another hand, 'assigning' a /64 to a smartphone, even if it allows it
to create two /65s, these are useless for SLAAC in its LAN segments,
because of that Ethernet IID length being 64, and 64+65 being larger
than 128.

Alex

>
> Gert Doering -- NetMaster
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 10:25:23 +0200

Le 22/10/2015 19:43, 神明達哉 a écrit :
[...]
> Regarding the main context, I don't know how advertising /63 helps
> the tethering scenario, btw.

Giving a '/63' to the smartphone allows it to create some '/64's out of
it.  They are useful for SLAAC in its LAN segments.  Giving it a '64'
allows it to create '65's which can not be used with SLAAC in its LAN
segments.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Oct 2015 04:09:13 -0300

> why a /63 would have any advances over a /64, like "the /64 is not big

Well, me, I never really thought of /63 but rather of longer prefixes
(e.g. /80 or whatever). If we start heading in the "/63 subnets"
direction, then the (eventual) need for IPv7 starts to look not so crazy...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Oct 2015 19:55:36 +1100

On 23 October 2015 at 19:25, Alexandre Petrescu
<[email-masked]> wrote:
> it.

Does code exist that already does this? If it doesn't, why wouldn't it
be better to implement DHCPv6-PD, the existing, tested and proven
mechanism to do this sort of thing?

>  They are useful for SLAAC in its LAN segments.  Giving it a '64'

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 11:03:35 +0200

> not have any meaning for this discussion.

But it is the same: that RFC not only requires the IID length to be 64 
but requires other parts of the IPv6 address to have some particular 
length.  In particular, it requires the SLA-ID to have a particular 
length.  In practice, that length is ignored by everybody.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 11:03:52 +0200

>   constructed in Modified EUI-64 format.]

Yes, I agree.  There are thus two places which require the IID length to 
be 64: one is the Ethernet IID (all IPv6 over foo) and the other is the 
Architecture RFC.

There is however no place which explicitely requires the prefix length 
in RA to be 64.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 11:13:53 +0200

Le 23/10/2015 10:55, Mark Smith a écrit :
>> Le 22/10/2015 19:43, 神明達哉 a écrit : [...]
>>>
>>> Regarding the main context, I don't know how advertising /63
>>> helps the tethering scenario, btw.
>>
>>
>> Giving a '/63' to the smartphone allows it to create some '/64's
>> out of it.
>
> Does code exist that already does this?

I dont know?

I know that in homenet they have this Prefix Assignment RFC-to-be which 
talks about 'portioning' a prefix.  The problem of automatically making 
sub-prefixes out of a prefix is well sensed in homenets.

> If it doesn't, why wouldn't it be better to implement DHCPv6-PD, the
> existing, tested and proven mechanism to do this sort of thing?

DHCPv6-PD - yes there is software available and it works ok on many 
platforms as I've tried it extensively.

But it looks simpler to make 64s out of a 63 - it's a local decision on
the device.

All the operators must do is not hardcode 64 prefixlengths, i.e. have it 
as a parameter.

Some operators moved from a 64-centric for end-user way of thinking - 
it's a parameter.

Alex

>> allows it to create '65's which can not be used with SLAAC in its
>> LAN segments.
>>
>> Alex
>>
>>>
>>> -- JINMEI, Tatuya
>>>
>>

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Oct 2015 20:46:47 +1100

> But it looks simpler to make 64s out of a 63 - it's a local decision on

I don't think it is simpler.

It relies on only one device being on the link.

It relies on the upstream router knowing there is only one device on
the link, so that it doesn't ND NS for any addresses in the space it
is advertising, instead it sends all traffic to the device.

It relies on the link being point to point, because the above
conditions can only be true if the link is a point-to-point link
between a router and host that might want to act as a router if it
decides to.

We end up with:

If ConditionA, ConditionB and ConditionC, then

SolutionY (/63s)

else

SolutionX (DHCPv6-PD)

Where as,

If ConditionA, ConditionB and ConditionC, then

SolutionX (DHCPv6-PD)

else

SolutionX (DHCPv6-PD)

or just

SolutionX (DHCPv6-PD)

will also work for both situations.

The code in a smartphone to do /63s divided into /64s might be simpler
than the code to do DHCPv6-PD. However, there is also code overhead in
the upstream router, and there are also human mental, operational and
troubleshooting overheads, because now there are two solutions to the
same problems which have to be learned, operated, troubleshooted, and
a set of conditions to learn to know which solution will or might be
used when, which is also more human mental overhead.

(The existence of the "sharing /64" RFC shouldn't be seen as an
indication that multiple solutions to this sort of problem is ok - it
has a number of limitations, and is only a work around to 3GPP
freezing feature sets such that for certain devices it isn't possible
to deploy DHCPv6-PD, despite the devices really just being pocket
computers/hosts that just happen to be able to also make phone calls.)

Regards,
Mark.

> All the operators must do is not hardcode 64 prefixlengths, i.e. have it as
> a parameter.
>
> Some operators moved from a 64-centric for end-user way of thinking - it's a
> parameter.
>
> Alex
>
>>
>>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 13:20:16 +0200

Le 23/10/2015 11:46, Mark Smith a écrit :
>>>> Giving a '/63' to the smartphone allows it to create some
>>>> '/64's out of it.
>>>
>>>
>> I know that in homenet they have this Prefix Assignment RFC-to-be
>> which talks about 'portioning' a prefix.  The problem of
>> automatically making sub-prefixes out of a prefix is well sensed
>> in homenets.
>>
>>> If it doesn't, why wouldn't it be better to implement DHCPv6-PD,
>>> the existing, tested and proven mechanism to do this sort of
>>> thing?
>>
>>
>> But it looks simpler to make 64s out of a 63 - it's a local
>> decision on the device.
>>
>

Well yes and no.

A possibility is the /63 prefix would be advertised as not being
on-link, and the device would not form a global address out of it.

Also, the case described by the jjmb draft proposes each device a unique
prefix.  Not sure how that translates to subnets and links - maybe there
are several subnets present on a link already.

>  is advertising, instead it sends all traffic to the device.

That is true, provided the device configures an address within that /63
prefix.

> between a router and host that might want to act as a router if it

It may be that what the jjmb draft proposes looks as a point-to-point link.

> will also work for both situations.

I can agree.  I just dont know how to persuade others to implement
DHCP-PD.  Especially operators.

> The code in a smartphone to do /63s divided into /64s might be
> simpler than the code to do DHCPv6-PD. However, there is also code
> overhead in the upstream router,

There is code overhead in the upstream router only if the device
configures an address for its egress interface out of that /63.
Otherwise there is not.

Remark the jjmb draft already proposes some changes in the upstream
router in order to realize the unique-prefix/device work on WiFi.  They
dont recomment DHCP-PD.  Should one advise to rather use DHCP-PD?

> and there are also human mental, operational and troubleshooting
> overheads, because now there are two solutions to the same problems
> which have to be learned, operated, troubleshooted, and a set of
> conditions to learn to know which solution will or might be used
> when, which is also more human mental overhead.

I can agree.

> computers/hosts that just happen to be able to also make phone

I can agree.  But I think it is hard to suggest operators of networks
supporting mobile devices to implement DHCP-PD.

Alex

>
> Regards, Mark.
>
>
>> All the operators must do is not hardcode 64 prefixlengths, i.e.
>> have it as a parameter.
>>
>> Some operators moved from a 64-centric for end-user way of
>> thinking - it's a parameter.
>>
>> Alex
>>
>>>
>>>
>>>
>>>> They are useful for SLAAC in its LAN segments.  Giving it a
>>>> '64' allows it to create '65's which can not be used with
>>>> SLAAC in its LAN segments.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> -- JINMEI, Tatuya
>>>>>
>>>>
>>>> list [email-masked]

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 23 Oct 2015 12:56:57 +0000

Alexander,

We have based our work on data that tells us what sort of devices
(including operating systems) are appearing on Wi-Fi networks, our Wi-Fi
networks.  To ensure we meet our customer’s expectations we use this data
as a cornerstone for our design and planning.  As new devices appear there
are two choices I see based on my experience:

* New devices (like the ones you are citing) are implemented to be
compatible with standards and hence existing deployments
* New devices implement additional/experimental functionality (like what
you describe) while remaining compatible with existing standards and
deployments

Given the above, support for new, experimental functionality could be
planned in an incremental fashion if required.

John

-----Original Message-----
From: Alexandre Petrescu <[email-masked]>
Date: Friday, October 23, 2015 at 04:23
To: John Jason Brzozowski <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action:

>>> inserts a 0 at the 64th position.  Everybody does that, nobody inserts
>>>a
>>> 1.
>>>
>>> Am I answering?
>>>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 23 Oct 2015 07:26:05 -0700

At Fri, 23 Oct 2015 10:24:30 +0200,

> That is what the SLAAC RFC says, yes.

I don't understand what you were trying to say below, but in any case,
my point was (correcting a typo):

  If an implementation performs SLAAC per RFC4862 Section 5.5.3 for a
  prefix in an RA PIO whose A bit is 1 and length is 63 on a link
  whose IID is supposed to be 64 bits, the implementation is "illegal"
  (meaning violating RFC4862).

I believe others used legal/illegal for the same meaning.  Perhaps you
wanted to say it's not explicitly prohibited to use an implementation
to use the /63 prefix for something other than SLAAC by "legal".  If
so, it would have been better to not use the word "legal" but explain
this is some new protocol extension you wish to have.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 17:00:31 +0200

John,

It is an excellent business case, but may not be the best common 
practice.  There are many wifi networks out there on which routers 
connect, as opposed to the cited devices.

Currently it seems the best recommendation to give a prefix per host is 
DHCP-PD.  I could agree with it as best common practice.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 17:34:15 +0200

>    (meaning violating RFC4862).

The !128 sum is illegal.  RFC4862 can't say which part is illegal.

If we take RFC4862 alone (not with rfc2464, nor 4291) then there is no 
violation in using a /63 with it.

There are many reasons to not take rfc2464 into consideration when 
discussing WiFi: WiFi and Ethernet are very different things.

There are some reasons to ignore some parts of RFC 4291.

> this is some new protocol extension you wish to have.

Well, thanks for the explanation.

In truth this wish is more operational than protocol extension.

It is how to make /64s out of a /63.

It is how a smartphone tethers bigger LANs if it receives a /63 rather 
than a /64.

There is no new message exchange or new bits in message formats.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Oct 2015 16:55:43 +0000

Hi,

I read this draft in more detail, and I am left with many questions. First,
I don't see any provisions for mobility or route optimization. In terms of
mobility, the UE's IPv6 prefix appears to be tethered to the current AP
point and cannot move with the UE as it moves from AP to AP. In terms
of route optimization, everything needs to go through the WLAN-GW
and cannot go directly from UE to UE even if the two UEs are right next
to one another.

The approach also still requires the UE to do DAD over the interface it
receives the IPv6 RA with PIO from. Approaches that properly delegate
an IPv6 prefix (e.g., DHCPv6 PD) do not require DAD over the interface
the prefix is received on because the prefix itself must not be assigned
to that interface. And, DHCPv6 PD client is trivial to implement today
and does not need to be pushed into the far distant future.

The approach is also a network-based approach using in-the-network
tunneling, but there are already many solutions that do this including
PMIPv6, Proxy AERO, and CAPWAP. A better mobility and route
optimization experience is also possible when the encapsulation is
removed from the network and placed on the UE such as for client
MIPv6 and client AERO. For AERO in particular, it is a very simple app
that runs on the UE that can be downloaded and invoked in a similar
fashion as for VPN clients like OpenVPN.

Finally, I am assuming that in large deployments there will be many
WLAN-GWs - each associated with potentially many APs. But, there
is no discussion of how networking between the WLAN-GWs will
occur - especially if UEs are allowed to roam between different
WLAN-GWs. This is covered in detail in AERO and other approaches.

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 24 Oct 2015 09:54:56 +1100

>>>> Does code exist that already does this?

So we know that code does exist for DHCPv6-PD, and it has been proven
though production deployments.

> on-link, and the device would not form a global address out of it.

So would the router blindly forward traffic for the /63 to the host,
regardless of whether the host was using it? It would have to unless there
was a way to signal its use, and that mandates an assumption that there is
only one device on the link that can use the /63.

If there are two or more devices on the link that could use the /63, then
you need a signaling method to indicate which one is using it.

> DHCP-PD.  Especially operators.

We need to find out why they aren't implementing DHCPv6-PD first.

It could just be that they don't have a need right now for a delegated
prefix solution (although given what I've heard about some carriers, it
might be because they object to the idea of tethering from a business point
of view.)

There is no evidence that DHCPv6-PD is fatally flawed at performing this
task, so there is no need to invent an alternative. By doing so, it creates
a greater barrier to adopting either of them, because now a value and
somewhat subjective judgement has to be made as to which one is
functionally best, which one is likely going to have the most vendor
support, which one is going to be most commonly understood by people
operating network using them.

More choice isn't always good.

> configures an address for its egress interface out of that /63.

So if the /63 is used by the device, than that had to be signaled to the
router, so the router treated the device as a next hop for the prefix,
which equals more code in the router to process the signaling.

The thing is, when you address all of the issues that crop up, you end up
with having invented something that is going to look very similar to
DHCPv6-PD.

> dont recomment DHCP-PD.  Should one advise to rather use DHCP-PD?

I think so, it is the way prefixes have been delegated to devices in
production networks for many years now.

>From what I remember, "share /64" was an interim work around to certain
revisions of 3GPP devices, and later revisions of the 3GPP specs specified
DHCPv6-PD as the solution.

So operators not impending this can't just be assumed to be because they
don't find DHCPV6-PD to be an acceptable solution.

Regards,
Mark.

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 23 Oct 2015 23:55:45 +0000

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Fred Templin
<[email-masked]>
Date: Friday, October 23, 2015 at 12:55
To: v6ops <[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action:
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

>point and cannot move with the UE as it moves from AP to AP.
[jjmb] as the draft sites APs are largely transparent.  Mobility is
support between APs, however, WLAN-GW to WLAN-GW will result in a
renumbering.  As far as route optimization is concerned I am not sure how
else we can optimize routing to a default gateway.
>In terms
[jjmb] this is actually deliberate and considered a feature.  Also note
the L bit is set to 0 to further encourage the use of the default gateway
(WLAN-GW) to facilitate node to Internet and node to node communications.
>receives the IPv6 RA with PIO from.
[jjmb] this could conceivably be omitted other than the DAD for the UE
link local address.  Perhaps we can optimize DAD by setting additional
flags in the RA.
>Approaches that properly delegate
>to that interface.
[jjmb] this is what is planned for when/if we support PD.
> And, DHCPv6 PD client is trivial to implement today
[jjmb] the incremental nature of this has nothing to do with the client,
has to do with two things.  1) we are doing this incrementally and 2) we
need to make sure the WLAN-GW implementations support this universally to
avoid partial support.
>fashion as for VPN clients like OpenVPN.
[jjmb] I have no control over the clients as such I can not enforce the
installation of such software.  I am quite I would get a very different
from this crowd and the public in general if I mandated additional
software.
>WLAN-GWs - each associated with potentially many APs.
[jjmb] yes many APs to a single WLAN-GW.  Multiple WLAN-GWs.  An AP will
associate to one and only one WLAN-GW.
>But, there
>WLAN-GWs. 
[jjmb] internetworking between UEs served by different WLAN-GW will be
done using layer 3 routing as we know it today, where applicable.
>This is covered in detail in AERO and other approaches.
[jjmb] I am sure AERO is a great solution for your use case, however,
there is little to no overlap for our deployment of IPv6 for community
Wi-Fi.

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 24 Oct 2015 00:46:23 +0000

Hi John,

> Sent: Friday, October 23, 2015 4:56 PM
> To: Templin, Fred L; [email-masked]
> support between Aps

The draft doesn't say how that is done; it just says that there is a GRE
tunnel between the AP and the WLAN-GW. Wireless solutions need
to speak to mobility as a matter of course. Unless we are trying to
further engender a population of couch potatoes that never leave
their own living rooms.

> however, WLAN-GW to WLAN-GW will result in a renumbering. 

Roaming between WLAN-GWs does not need to result in a
renumbering event, which would be very unfortunate.
Renumbering never happens with AERO, and UEs get to
use their same delegated prefixes wherever they happen
to pop up in the network.

> As far as route optimization is concerned I am not sure how

Route optimization is brokered by the network for the benefit of the
clients and also to remove traffic concentration from performance
critical network elements. AERO specifies a means for client to client
route optimization that removes the default gateway from the path.

> (WLAN-GW) to facilitate node to Internet and node to node communications.

AERO provides route optimization requested by the client and brokered
by the network. The network can either permit or deny route optimization
as it is configured to do so, and provides a trust basis for clients to engage
in the route optimization.  (Also check 6rd that provides natural route
optimization as a fundamental aspect of its design.) Route optimization
offloads performance-critical infrastructure and provides a better client
to client experience.

> link local address.  Perhaps we can optimize DAD by setting additional

What additional flags would you set in the RA that an unmodified host
would be able to recognize as a signal not to do DAD?

> [jjmb] this is what is planned for when/if we support PD.

PD gives the node a prefix that the network certifies will not be given
to any other node. The prefix is not to be assigned to the link over
which it was received, so there is no need to DAD for any of the
addresses assigned from the prefix. And, there could be millions
of such addresses.

> need to make sure the WLAN-GW implementations support this universally to

I don't understand your meaning here, but what matters is a robust
and acceptable end user experience throughout all rollout phases.

> from this crowd and the public in general if I mandated additional

If you don't want to control the clients, then have a look at PMIPv6,
Proxy AERO and/or CAPWAP.

> associate to one and only one WLAN-GW.

That is fine, but you still need to care for mobiles that jump from AP
to AP and in the process may roam between WLAN-GWs. That
requires a mobility management scheme that I do not see in the draft.

> done using layer 3 routing as we know it today, where applicable.

Layer 3 routing how, though? If you inject millions upon millions of
UE prefixes into the routing system it is a recipe for disaster. Using
a private BGP instance as specified in AERO is a way to avoid this.
 
> there is little to no overlap for our deployment of IPv6 for community

Many AERO use cases are examined in RFC6139, but the list there
is not exhaustive. The use case described in your draft is indeed
another use case for AERO.

Thanks - Fred
[email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 26 Oct 2015 13:04:58 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Friday, October 23, 2015 4:56 AM
To: Alexandre Petrescu
Cc: [email-masked]; Brzozowski, John; 神明達哉
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)

>Does code exist that already does this? If it doesn't, why wouldn't it be better to implement DHCPv6-PD, the existing, tested and proven mechanism to do this sort of thing?

The OpenWRT home router Linux implementation supports DHCPv6 PD.   Several vendors support DHCPv6 PD in their home routers.   

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Oct 2015 15:27:28 +0000

Top-posting my own message from last Friday, I realized after clicking send
that I was out of line and want to apologize to John for the tone of the note.
John knows and understands the community WiFi service use case in ways
that I do not, so it was inappropriate for me to profess knowledge of the
use case that I do not have.

That said, I think there are two areas that need further discussion:

1) Use of SLAAC PD vs DHCPv6 PD
2) Applicability to other domains

Regarding 1), there seems to be a growing interest in SLAAC-based prefix
delegation as an easy means for multi-addressing in some environments.
However, IMHO DHCPv6 PD is still the more appropriate method for many
use cases including enterprise/corporate, aviation networks, etc. The
relatives merits of both approaches should therefore be examined
according to their intended use cases.

Regarding 2), John's document indicates an interest in exploring other
domains of applicability such as corporate/enterprise and campus. But,
those are the use cases AERO has been primarily focused on for a long
time as documented here:

https://datatracker.ietf.org/doc/draft-templin-aeroent/

That is all I have to say for now.

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Friday, October 23, 2015 5:46 PM
> To: Brzozowski, John; [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 Oct 2015 20:23:37 +0900

> mechanism to do this sort of thing?

Because this is an operational working group, and the document describes an
operational solution.

No popular operating system currently implements DHCPv6 PD on wifi, and
even if they all implemented it tomorrow, it would take years before a
substantial number of devices supported it.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 Oct 2015 12:47:19 +0100

> substantial number of devices supported it.
Apple's iOS distribution model disagrees with you.  Multiple trend sites
suggest that ios9, released 6 weeks ago, is currently standing at 55-60%
adoption across all iDevices. 

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Oct 2015 15:11:26 +0000

Hi Lorenzo,

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, October 27, 2015 4:24 AM
To: Mark Smith
Cc: 神明達哉; [email-masked]; Brzozowski, John
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)

On Fri, Oct 23, 2015 at 5:55 PM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Does code exist that already does this? If it doesn't, why wouldn't it
be better to implement DHCPv6-PD, the existing, tested and proven
mechanism to do this sort of thing?

Because this is an operational working group, and the document describes an operational solution.

No popular operating system currently implements DHCPv6 PD on wifi, and even if they all implemented it tomorrow, it would take years before a substantial number of devices supported it.

I have a DHCPv6 PD app running on Android today. It is really just a few client-side
messages, and then you get a prefix for provisioning addresses and/or for further
sub-delegation.

Thanks – Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Oct 2015 17:17:04 +0000

Actually, forget my little homegrown app – ISC DHCP client already has
DHCPv6 PD and runs on a number of OSes. Am I missing the point?

Thanks – Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, October 27, 2015 8:11 AM
To: Lorenzo Colitti; Mark Smith
Cc: [email-masked]; 神明達哉; Brzozowski, John
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)

Hi Lorenzo,

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, October 27, 2015 4:24 AM
To: Mark Smith
Cc: 神明達哉; [email-masked]<mailto:[email-masked]>; Brzozowski, John
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)

Thanks – Fred

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 27 Oct 2015 23:39:49 +0000

Thank you Fred, sincerely appreciate your comments below.

I agree with your two bullets below.

I agree that DHCPv6 PD is widely use, however, I think we should consider
the possibility that more than one approach maybe appropriate/needed.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Fred Templin
<[email-masked]>
Date: Monday, October 26, 2015 at 15:27
To: John Jason Brzozowski <[email-masked]>, v6ops
<[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action:
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 Oct 2015 11:38:51 +0100

I've skimmed quickly through this draft.

1) Section 4.2 mentions that DAD is used, but it is not clear to me how
this will work for LLAs. If two UEs (potentially attached to different
APs) are using the same link-local address, how will they see each
others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does
not relay DAD messages across the split BUM horizon, how will it deal
with the possiblity of two unique UEs both using the same LLA? I'm
guessing that in a large-scale deployment, the chances of two UEs
having statically configured, e.g., fe80::1 is quite likely.

2) Regarding the following text in Section 4.2:

>   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6),
>      this flag may be set to 1 in the future if/when DHCPv6 prefix
>      delegation support over Wi-Fi is desired)

As I understand it (and I do stress that), the M-flag indicates whether
or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
(IA_PD) is something different. Therefore, assuming that availability of
IA_PD is signalled using RA flags to begin with, then it is "other
configuration" and thus signalled with the O-flag, not the M-flag. I
know of at least one wireline ISP that has such a deployment, i.e.,
they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
using M=0 + O=1.

3) The draft describes tunneling traffic in a stateless manner. I take
that to mean that the APs and WLAN-GW will be incapable of performing
reassembly at tunnel egress (and by extension that they won't fragment
GRE packets on ingress either). That in turn means that you either 1)
need to allow for jumbo frames in the transport network between the
WLAN-GW and the APs, or 2) provide UEs with a reduced MTU (which
implies the RA MTU option should be used and possibly also TCP-MSS
clamping at the WLAN-GW). Since this is an operational guidance
document I believe this is something that should be discussed.

4) Is UE roaming between APs/BSSIDs supported, and if so how does this
work? As I understand it, the WLAN-GW will have 1 GRE interface per AP,
so if a UE roams from one AP to another, its MAC address and all of its
associated IPv6 addresses will (from the WLAN-GW's POV) move from one
GRE interface to another, which would in turn require the WLAN-GW to
somehow notice this and move the associated /64 and any NDP entries
from the previous GRE interface to the current one. Right? If so, some
discussion on how that happens would be appreciated (or at least a
statement that "secret vendor sauce is assumed to be applied here" if
that is indeed the case).

5) This is just a thought, but regarding the operational consideration
in section 5 regarding supporting privacy addresses: Would it be
possible for the WLAN-GW to simply send all traffic destined for the
UE's dedicated /64 to the UE's MAC address without maintaining ND
entries for each address in use? This way, a single UE could use
gazillions of IPv6 addresses without risking resource exhaustion in the
WLAN-GW. OTOH, maybe that would cause problems for UEs that are
providing tethering to downstream hosts using layer-2 bridging?

6) Some editorial nits I noticed (although I wasn't specifically
looking for them): Missing «.» at the end of page 7, s/Lawfull/Lawful/
on page 12.

Tore

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Oct 2015 11:44:10 +0100

Le 27/10/2015 18:17, Templin, Fred L a écrit :
> No popular operating system currently implements DHCPv6 PD on wifi,
> and even if they all implemented it tomorrow, it would take years
> before a substantial number of devices supported it.
>

Absolutely not.

It is reasonable to expect community devices to be pre-installed with
DHCP-PD clients by the operator. Or otherwise the owners to download
DHCP-PD as part of a 'community advanced tethering' application from a
store.

We can ask the operator to show the IPv6 addressing architecture laid on
the operator topology, substituting "2001:db8::" where necessary.  I
suppose this will help.

Alex

> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Templin,
> Fred L *Sent:* Tuesday, October 27, 2015 8:11 AM *To:* Lorenzo
> Colitti; Mark Smith *Cc:* [email-masked]; 神明達哉; Brzozowski, John
> *Subject:* Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action:
>  draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
>
> Hi Lorenzo,
>
> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Lorenzo
> Colitti *Sent:* Tuesday, October 27, 2015 4:24 AM *To:* Mark Smith
> *Cc:* 神明達哉; [email-masked] <mailto:[email-masked]>; Brzozowski, John
> *Subject:* Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action:
>  draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
>
> Does code exist that already does this? If it doesn't, why wouldn't
> it be better to implement DHCPv6-PD, the existing, tested and proven
> No popular operating system currently implements DHCPv6 PD on wifi,
> and even if they all implemented it tomorrow, it would take years
> before a substantial number of devices supported it.
>
> [email-masked] <mailto:[email-masked]>
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Oct 2015 15:49:33 +0000

Hi Tore,

> From: v6ops [mailto:[email-masked]] On Behalf Of Tore Anderson
> Sent: Wednesday, October 28, 2015 3:39 AM
> To: [email-masked]

For properly delegated prefixes (i.e., prefixes that are granted by the
network for the UE's exclusive use), DAD over the link over which the
prefix was received is not necessary. If the prefix was advertised to
multiple UEs, then DAD would still be required.

The trouble with (A=1; L=0) in PIO advertisements is that there is
no way for an unmodified UE to know whether the prefix is being
granted by the network for its exclusive use. RFC4861 says that
L=0 only means that there is "no statement about on-link or off-link
properties of the prefix". It is therefore unreasonable for the UE
to assume that the prefix is being granted for its exclusive use.

> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this

This surprises me, but I'll take your word for it. However, on some links
such as AERO it should be possible to do DHCPv6 PD without first receiving
an RA.

> document I believe this is something that should be discussed.

Documents that discuss tunnel fragmentation are RFC7676, 
draft-ietf-intarea-tunnels, and AERO. Also, CAPWAP does fragmentation
and reassembly to ensure sufficient MTU, and I am not yet convinced
that John's use case cannot be satisfied by CAPWAP.

Fragmentation need only be applied in the path from the WLAN-GW
to the AP, and not in the reverse direction. This is because the AP can
signal a reduced MTU to the UEs without risk of PMTUD failures.

> that is indeed the case).

This is the same question I asked about mobility and route optimization,
and where I realized that I needed to back off and bump up to a higher
level. The problem is that we just don’t understand enough about
John's use case (yet) to know whether or not full mobility management
will be important, or whether some limited form of mobility support
(or no support at al) will be sufficient. I think John's use case needs
much more thorough discussion before any particular solution can
be applied.

> providing tethering to downstream hosts using layer-2 bridging?

Only if the prefix is properly delegated to the UE, such as with
DHCPv6 PD.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Oct 2015 16:03:44 +0000

Hi Alex,

> Sent: Wednesday, October 28, 2015 3:44 AM
> To: [email-masked]
> Subject: Re: [v6ops] how /63 helps tethering
> 
> 
> 

This goes back to the point about insufficient information about John's
use case. Does his use case expect completely unmodified COTS UEs
such as the end user would buy at a consumer electronics store? Or,
will there be opportunity to install a small piece of software, either
by the operator or directly by the end user? We simply don't know
enough about the use case, and I would encourage John to provide
more details.

> the operator topology, substituting "2001:db8::" where necessary.  I

The operator's service prefix (e.g., a /32 or something) should be well
known. UE prefixes should be derived from the service prefix and
delegated according to the UE's needs, and not necessarily bound
to the operator's topology.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Wed, 28 Oct 2015 10:54:52 -0700

At Wed, 28 Oct 2015 11:38:51 +0100,

> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this

Interesting point.  Personally I've been assuming that the O-flag
being on implies (if anything) a "stateless" DHCPv6 service.  That's
significant in this context, since the client would send an
Information-request message for stateless services, while prefix
delegation requires a DHCPv6 session beginning with a Solicit message.
I'm not sure how widely my assumption is shared, but, in any case,
the specifications are actually unclear as you indicated above.

(And, of course, there is another level of issue that the semantics of
MO flags is too unclear in general in the first place...)

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Thu, 29 Oct 2015 03:21:47 +0900

> MO flags is too unclear in general in the first place...)

DHCPv6 PD availability is not signalled through M/O bits or RAs at all.
two reasons for that; firstly routers don't typically process Router Advertisements, secondly we would have needed more flags.

Best regards,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Oct 2015 18:45:45 +0000

Hi Ole,

> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, October 28, 2015 11:22 AM
> To: 神明達哉; Tore Anderson
> Cc: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
> 

+1 

> two reasons for that; firstly routers don't typically process Router Advertisements, secondly we would have needed more flags.

I agree with non-requirement for RAs, but there is also a use case where the
"requesting router" is actually a host. The host acts as a requesting router
from the standpoint of DHCPv6 PD, but when it receives a prefix it assigns
it to a loopback interface. The host disables IP forwarding, and assigns
addresses constructed from the delegated prefix to the interface over
which the delegation was received. It can assign millions of such addresses,
and never need to do DAD for any of them because the prefix is delegated
for the hosts exclusive use. The host initially has only a default route pointing
to the delegating router, but can discover more-specific routes via Redirects.

The only difference when the requesting router is actually a router is that
it turns on IP forwarding and sub-delegates the delegated prefix to its
downstream-attached networks. All other prefix delegation messaging
is exactly the same as the host case.

Thanks - Fred

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 Oct 2015 20:32:38 +0100

* [email-masked]

> DHCPv6 PD availability is not signalled through M/O bits or RAs at

For what it's worth, what gave me this understanding are two things:

1) From RFC 7084:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.

Since O is redundant (implicitly 1) whenever M=1 (RFC4861 section 4.2)
I think a reasonable intepretation of this is that it is DHCPv6 PD is
considered part of what is considered "other configuration", whose
availability is signalled with the O flag.

2) RFC 4861 section 4.2 itself:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].
[...]
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.

What DHCPv6 options the term "other configuration" encompasses isn't
limited in any way. It is IMHO therefore reasonable to interpret this
as *any* configuration available via DHCPv6, except for "addresses". So
I read the above as follows:

M flag: signals availability of addresses
O flag: signals availability of everything that is not
addresses (which would include prefixes)

> two reasons for that; firstly routers don't typically process Router
> Advertisements, secondly we would have needed more flags.

Well, as described by RFC 7084, CE routers (which are the primary
consumers of DHCPv6-PD to the best of my knowledge) *do* process RAs,
and if the O flag can be interpreted to mean "everything except
addresses", the two flags are all that is needed.

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Oct 2015 08:34:06 +1300

> MO flags is too unclear in general in the first place...)

"If the M flag is set, the O flag is redundant and
can be ignored because DHCPv6 will return all
available configuration information."

So Tore is slightly wrong: if the M flag is set, the O flag contains
no information, whatever value it has. Don't even test it.

If the M flag is clear, and the O flag is set, you can't get addresses.
You can get some things from DHCPv6, but you don't know what. Maybe
IA_PD is available, maybe not.

If M=O=0, DHCPv6 is a waste of space.

Or:

if M==1
  {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
   /*try to get IA_PD from DHCPv6 if you want*/;
   /*try to get other DHCPv6 options if you want*/;}
   else {/*get addresses using SLAAC*/;
        if O==1
          {/*try to get IA_PD from DHCPv6 if you want*/;
           /*try to get other DHCPv6 options if you want*/;}}

    Brian

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 Oct 2015 20:55:45 +0100

* Templin, Fred L

> to assume that the prefix is being granted for its exclusive use.

Hi Fred,

Please not that I am talking specifically about LLAs. Those aren't
advertised in RA or DHCPv6.

I do understand that each UE is expected to be alone in its unique
GUA /64, making DAD for those addresses redundant.

However this is not the case for LLAs, unless I have misunderstood the
I-D - from the WLAN-GW's point of view, every UE attacached to a single
AP will belong to the same link (the same Soft-GRE tunnel interface,
that is). Thus there is a possibility of address conflicts.

Tore

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 Oct 2015 21:03:41 +0100

* Tore Anderson

> addresses (which would include prefixes)

Correcting myself:

M=1: signals that addresses are certainly available, and that other
stuff in addition to addresses *might* be available.
O=1: signals that at least some other stuff, that is, *not* addresses,
is available via DHCPv6.
M=O=0: possibly nothing is available via DHCPv6 (but it could still be,
both addresses and/or other stuff - it might just be that the RA
originator is unaware of it)

«Other stuff» here might include prefixes, or it might not. Only way to
know for sure is for the client to ask for it.

Tore

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Oct 2015 21:31:33 +0000

Hi Tore,

> From: Tore Anderson [mailto:[email-masked]]
> Sent: Wednesday, October 28, 2015 12:56 PM
> To: Templin, Fred L
> Cc: [email-masked]

Yes, but that can only happen if the prefix is properly delegated to
the UE and not also advertised to other UEs. I don't think there is
a way for the UE to tell that based only on the (A, L) bits in a PIO.

> that is). Thus there is a possibility of address conflicts.

OK, I see your point: if it is a shared link where LLA duplication is possible
then DAD for the LLAs is needed, yes. AERO is a shared link where LLA
duplication is not possible; hence, AERO avoids DAD even for LLAs.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 11:57:48 +0100

Le 28/10/2015 19:21, [email-masked] a écrit :
>>> As I understand it (and I do stress that), the M-flag indicates
>>> whether or not *addresses* are available via DHCPv6 (RFC 4861
>>> s4.2). Prefixes (IA_PD) is something different. Therefore,
>>> assuming that availability of IA_PD is signalled using RA flags
>>> to begin with, then it is "other configuration" and thus
>>> signalled with the O-flag, not the M-flag. I know of at least one
>>> wireline ISP that has such a deployment, i.e., they support
>>> DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this using M=0
>>>  + O=1.
>>
>> being on implies (if anything) a "stateless" DHCPv6 service.
>> That's significant in this context, since the client would send an
>> delegation requires a DHCPv6 session beginning with a Solicit
>> message. I'm not sure how widely my assumption is shared, but, in
>> any case, the specifications are actually unclear as you indicated
>>  above.
>>
>> (And, of course, there is another level of issue that the semantics
>> of MO flags is too unclear in general in the first place...)
>
> DHCPv6 PD availability is not signalled through M/O bits or RAs at
> all. two reasons for that; firstly routers don't typically process
> Router Advertisements, secondly we would have needed more flags.

This (DHCP-PD availability not conveyed) looks like a lack in
specification.

There is another such lack illustrated by practical experience: there is
no easy way for a UE to learn whether the network in front of it
supports PD or just DHCP.  There are some suggestions in DHC WG (e.g.
Solicit with IA_PD and check Advertise for IA==Noaddrsavail, subject
"Two comments..." in archives 23 July 2015) but no spec.

Maybe a better spec would persuade operators to deploy PD?  Have the
operators felt this lack?

>> firstly routers don't typically process Router Advertisements,

But it's mostly Routers that would need a prefix from DHCP-PD.

Alex

> Best regards, Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 11:58:35 +0100

> the specifications are actually unclear as you indicated above.

I agree.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 12:32:57 +0100

Fred,

Le 28/10/2015 17:03, Templin, Fred L a écrit :
[...]
> to the operator's topology.

I agree.  It sounds like a good start for designing an IPv6 address 
architecture for a jjmb-like topology.

But it should be done carefully, in order to allow for future use of 
Prefix Delegation for future tethering UEs.  If not done carefully at 
the start, the addressing architecture risks forbidding Prefix 
Delegation later (because in IPv6 there is no NAT to extend the network, 
and there is a boundary at /64).

May I explain.

In the straighforward way 2001:db8:1::/48 is assigned for access through 
AP1, 2001:db8:2::/48 through AP2 and so on; for UEs we reserve 
2001:db8:1:1::/64 to 1:n through AP1 and so on.  But later we realize we 
have no space left for allocating /64 prefixes to future tethering UEs. 
  It is illustrated:

                                          +-----+
                                          | AAA |
                                          +-----+
                                             /
                                          Radius
                                           / 2001:db8:ffff:1::/64
                                     +----+
                                     | CP |
                 +----+              +---------+
UE1..UEn-802.11-| AP |---Soft_GRE---| WLAN-GW |----Internet/WAN
                 +----+              +---------+    2001:db8::/32
           2001:db8:1:1::/64              |
           2001:db8:1:2::/64           IP/HTTP
               ...                        | 2001:db8:ffff:2::/64
           2001:db8:1:n::/64   +---------------------+
                               | HTTP Captive Portal |
                               +---------------------+

A better way is to refine from the start a part of the prefix to reserve 
it for future prefix allocations for tethering UEs.

                                              +-----+
                                              | AAA |
                                              +-----+
PD-allocated                                   /
2001:db8:0201:1::/64                         Radius
2001:db8:0201:2::/64                         / 2001:db8:ff00:1::/64
   ...                                   +----+
2001:db8:0201:n::/64                    | CP |
                     +----+              +---------+
         UE--802.11--| AP |---Soft_GRE---| WLAN-GW |----Internet/WAN
                     +----+              +---------+    2001:db8::/32
            2001:db8:0101:1::/64              |
            2001:db8:0101:2::/64           IP/HTTP
                   ...                        | 2001:db8:ff00:2::/64
            2001:db8:0101:n::/64   +---------------------+
                                   | HTTP Captive Portal |
                                   +---------------------+

I do not know what is the IPv6 addressing architecture on the jjmb 
topology, and I hope it is ready for Prefix Delegation to tethering UEs.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Oct 2015 14:23:25 +0100

Hi,

> bluetooth interface and another one deeper in its LAN.

No, it can't.  If the smartphone sees "there is a /63 on this link", it
has no knowlege on whether it can "just so" take one of the /64s to
use for something else - someone else might be sharing the link, and
have the same idea.

So, /63 on a link is totally useless, in addition to being not defined
for SLAAC.

(If you *know* that this is a link just for you and nobody else, like
a PPP link or a 3G PDP context, this could be done - but is still not
overly useful, as you can do the tethering thing already perfectly well
with the single /64 you get there)

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 14:43:55 +0100

Gert - have you noticed jjmb is 'prefix-per-host'?

> use for something else - someone else might be sharing the link, and

Except when that link is a point-to-point link[*] not a shared link. 
And this is precisely the case with the prefix-per-host concepts which 
are assumed in the jjmb draft: they make point-to-point links laid over 
underlying shared links.

[*] the actual distinguishing characteristic for point-to-point vs 
'shared' links is the kind of route present in the gateway for this 
prefix: 'C'onnected qualifier for route on Cisco, or '*'-vs-address in a 
routing table for linux are the right indicators of that characteristic.

If the route at the gateway points the /63 to a next-hop value as an 
address, then it is certainly possible for the UE to derive two /64s out 
of that /63 and make subnets in its LAN.  Remember that a 
'prefix-per-host' concept can not work if the gateway does not have such 
a route pointing to an address (rather than '*'); this is so because 
there must be a means for the gateway to know _which_ prefix belongs to 
_which_ host.

If on the other hand the route at the gateway points a /63 to a '*' then 
yes, that '/63' can not be used by the UE to form /64s for its LANs. 
But this does not allow for 'prefix-per-host' concepts.

> So, /63 on a link is totally useless, in addition to being not defined

I can agree /63 on-link is maybe undefined, although I am sure linux 
implementations do make addresses out of a /63 with SLAAC.

A /63 totally useless - maybe we should think of it in terms of IPv6 
addressing architecture.  I think an IPv6 addressing architecture may be 
such designed that does not allow to even think that a UE may need a 
/63, and that /64 is all what users desire.

> with the single /64 you get there)

That kind of tethering only allows for _one_ subnet in the LAN.

One couldn't tether to 2-3 subnets present in one's car for example.  Or 
small ship, or whenever more than just smartphone+tablet formula.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Oct 2015 15:05:56 +0100

Hi,

> Gert - have you noticed jjmb is 'prefix-per-host'?

Yes, and what exactly does this have to do with "/63 in RAs, with SLAAC"?

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 15:14:47 +0100

> Yes, and what exactly does this have to do with "/63 in RAs, with SLAAC"?

If done it helps with tethering.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Oct 2015 15:16:43 +0100

Hi,

> If done it helps with tethering.

No, as you have already discovered.  

And note that "a gateway routing a /63 over a point-to-point link" is 
NOT the same as "a /63 put on-link by means of RA".

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Oct 2015 14:33:09 +0000

Hi Alex,

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Thursday, October 29, 2015 4:33 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [v6ops] how /63 helps tethering - addressing architecture
> 
> Fred,
> 

Not what I had in mind. If the tunnel were to extend all the way to the
UE, there would be no need to assign 2001:db8:*::/48 prefixes to an
AP. There would be only the /32 (or similar) operator's service prefix
and the /64 (or similar) UE prefixes. Complete de-aggregation. This
allows UEs to seamlessly roam between APs and even between
WLAN-GWs without needing to renumber.

All it would take would be to install a little app on the UE - either by
the operator, or by the user visiting a website. Then, DHCPv6-PD and
multi-addressing are made available with full support for mobility and
route optimization. If there are any questions on how this works,
either let me know or have a look at the AERO draft.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 15:38:09 +0100

I can agree.

But "a /63 put on-link by means of RA" can not happen without "a gateway 
routing that /63 to that link (be it '*' or address)".

If someone puts a /63 (or /64 for that matter) on-link and does not 
route to it then someone disconnects it from the Internet.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Oct 2015 15:40:03 +0100

Hi,

> route to it then someone disconnects it from the Internet.

You totally do not seem to understand the difference between "routing 
across a link" and "*on* a link", like "with ND for every address in it".

I will now totally ignore you, which I should have done much earlier.

Apologies to the list for contributing noise.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 15:53:16 +0100

> across a link" and "*on* a link", like "with ND for every address in it".

I dont know what makes you think I dont understand...

In the jjmb draft context, advertising a prefix on a link can not happen 
without routing to that prefix.

Putting a /63 in an RA, means that the UE will benefit of that prefix 
being routed to it.

Putting a /64 in the RA (nothing else than that precise figure "64"), 
means that the UE can not use anything else than just that /64.  If more 
is needed, then a new routing entry must be added in the gateway for 
this additional prefix.

I think an operator that does not want to deploy DHCP-PD will not want 
to add these new prefixes in the gateways either.

As for statements about ignoring somebody: it's called killfiling 
someone and your MUA is free to do so.  I wonder why it did not do it 
until now.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Oct 2015 16:00:05 +0000

> Sent: Thursday, October 29, 2015 7:33 AM
> To: Alexandre Petrescu
> Cc: [email-masked]

Let me amend what I said slightly by saying the completely de-aggregated
approach applies also when the tunnel ends at the AP. In that case, Proxy
AERO would be used, and the UEs would not need to install any software.

Thanks - Fred

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 29 Oct 2015 17:17:26 +0000

See below.

-----Original Message-----

From: v6ops <[email-masked]> on behalf of Ole Trøan
<[email-masked]>
Date: Wednesday, October 28, 2015 at 19:21
To: 神明達哉 <[email-masked]>, Tore Anderson <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] I-D Action:
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

>> MO flags is too unclear in general in the first place...)
[jjmb] I think the above is from Tore.  Tore I think most people who have
deployed IPv6 share the same interpretation, at least I do.
>DHCPv6 PD availability is not signalled through M/O bits or RAs at all.
[jjmb] I think this may be your interpretation, since the beginning of the
IPv6 deployment at Comcast and the work we did specifying IPv6 for DOCSIS
we have used the M/O to signal the use of DHCPv6.
>Advertisements, secondly we would have needed more flags.
[jjmb] routers do process RAs, thus far ~75%+ of my customers are native
dual stack enabled using these techniques without incident.  No additional
flags appear to be required.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 29 Oct 2015 20:39:51 +0100

* Brian E Carpenter

>            /*try to get other DHCPv6 options if you want*/;}}

Hi Brian,

I am in 100% agreement with you, but I have clearly failed to express
this correctly. What I have been meaning to say is that IA_PD is
considered part of the "other configuration" (a.k.a. "not addresses")
class of DHCPv6 options whose availability can be explicitly signaled
through O=1 *or* implicitly through M=1.

So your pseudo-code above reads correct to me, and matches RFC 7084
WPD-4 as well as the wording in section 4.2 of RFC 4861.

My original point is that my reading of
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt suggests a
different and incorrect interpretation of the flags, which implies the
following new pseudo-code (removing IA_PD from your «if O==1 {}» block):

if M==1
          {/*try to get other DHCPv6 options if you want*/;}}

That is, the draft suggests that the availability of IA_PD is tied to
the value of the M flag exclusively, instead of the boolean expression
(M OR O). I on the other hand believe (M OR O) is the correct
interpretation. I think we're in agreement on this point?

Tore

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Oct 2015 20:59:55 +0000

Hi, I won't disagree with Brian and Tore but on some IPv6 links waiting to
receive an RA may be redundant and unnecessary before directly
attempting DHCPv6 PD. On those links, DHCPv6 messaging alone may
be all that is necessary, and no RS/RA is required.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Oct 2015 10:42:22 +1300

below...

> interpretation. I think we're in agreement on this point?

Yes.

Somebody did mention that in practice, M==O==0 might actually mean
"we run DHCPv6 but forgot to set the bits". But I don't know what to
do about that.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Oct 2015 10:52:44 +1300

Fred,

> be all that is necessary, and no RS/RA is required.

How is an IPv6 stack fresh from the factory supposed to guess that?
Surely we don't want to add configuration knobs?

I think RA is a required feature. RFC 6434 says:

7.2.2.  Use of Router Advertisements in Managed Environments

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   are expected to determine their default router information and on-
   link prefix information from received Router Advertisements.
...
12.2.  Neighbor Discovery for IPv6 - RFC 4861

   Sending Router Advertisements and processing Router Solicitations
   MUST be supported.

     Brian

---

From: [email-masked]
Date: Fri, 30 Oct 2015 06:59:27 +0900

Brian,

>   Sending Router Advertisements and processing Router Solicitations

in the general case:
it isn't required for router to router links.
nor is it required for DHCPv6 PD.

in the 7084 case:
we've tied the CE router's default routing to ND Router Discovery.

Best regards,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Oct 2015 22:03:31 +0000

Hi Brian,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 29, 2015 2:59 PM
> To: Brian E Carpenter
> Cc: Templin, Fred L; Tore Anderson; [email-masked]; 神明達哉

The same as what Ole said. Also, an IPv6-over-(foo) document can specify that
DHCPv6-only autoconfiguration is used on that link. In that way, IPv6 nodes
that connect to a (foo) link already known in advance what sorts of link
ND/DHCPv6 services they can expect.

Thanks - Fred

---

From: [email-masked]
Date: Fri, 30 Oct 2015 07:09:38 +0900

I've changed subject.

> through O=1 *or* implicitly through M=1.

that's incorrect.
7084 describes a specific deployment model where a router has an upstream interface acting both as a host and a router (in 4861 terms).
there are other deployment models of PD.
you can very well implement 7084 with DHCP and RA processing completely independent. i.e. ignoring the M/O flags. the implementation could use the M flag to determine to include IA_NA in that request or it might run two DHCP sessions.

> interpretation. I think we're in agreement on this point?

PD is not tied to the M/O flags at all, apart from using them as an indication that DHCP service might be available on the link.

note that for a 7084 router PD is mandatory.

reading very much into the M/O flags is futile. as you will figure out if you read the thousands of messages on this subject in the 6man archive.

7084 pseudocode:
if A=1: do SLAAC

if M=1
 /* include IA_NA in request to DHCPv6 server /*
 /* include requests for other configuration options (not IA_*) /*
else if O==1:
 /* include requests for other configurations options */

do DHCP PD (include other options as indicated above)

your pseudocode also had the bug of coupling DHCP and SLAAC address assignment.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Oct 2015 11:45:00 +1300

Ole, Fred,

>> it isn't required for router to router links.

That may be so in practice, but is it actually documented that way?
(I agree that it makes sense.)

>> nor is it required for DHCPv6 PD.

I don't see any wiggle room in the section 12.2 quote above. But anyway,
the only practical interpretation of that is "if you think you might
like to get an IA_PD, then try DHCPv6 regardless of RA."

>> we've tied the CE router's default routing to ND Router Discovery.

Right... which is a safe choice, because it's consistent with RFC 6434.

> DHCPv6-only autoconfiguration is used on that link. 

Really? RFC 4861 does allow exceptions, but mainly in terms of NBMA
links. Also, DHCPv6 is only a SHOULD in node requirements.

> In that way, IPv6 nodes

Well, the IPv6-over-foo modules can know in advance. But host stacks as a whole
need to figure this out dynamically, I think. Again, I am assuming that we want
to get avoid configuration knobs.

Regards
   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Oct 2015 22:53:06 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, October 29, 2015 3:45 PM
> To: Templin, Fred L; [email-masked]
> Cc: Tore Anderson; [email-masked]; 神明達哉
> links.

Yes, I should have said NBMA. That is what I meant.

> Also, DHCPv6 is only a SHOULD in node requirements.

That is for IPv6 node requirements, yes. Requirements for nodes that
connect to a specific link type can change the SHOULD to a MUST.

> to get avoid configuration knobs.

A node connecting to a link type that has DHCPv6 as a MUST will naturally
do DHCPv6, yes.

Please note that I am not saying "DHCPv6-only". IPv6 ND functions such
as Redirect and NUD may still be needed, and if the node sends an RS
it should probably expect to receive an RA in reply (unicast).

Thanks - Fred

---

From: [email-masked]
Date: Fri, 30 Oct 2015 10:01:38 +0900

Brian,

[off topic warning]

> Right... which is a safe choice, because it's consistent with RFC 6434.

well, the choice isn't all that obvious. implementations/deployments do also vary.
the most obvious choice is a routing protocol.

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 30 Oct 2015 13:12:19 +1100

Hi Fred,

>> -----Original Message-----
<snip>
> DHCPv6-only autoconfiguration is used on that link.

Do any exist that state that?

I'd hope in that case the IPv6-over-(foo) document mentions that if a
stateful DHCPv6 server is not available, the hosts are only left with
link-local addresses to use for all IPv6 operations and applications.

Regards,
Mark.

---

From: Tore Anderson <[email-masked]>
Date: Fri, 30 Oct 2015 07:58:49 +0100

Hi Ole,

* [email-masked]

> > through O=1 *or* implicitly through M=1.

I hear you say that, but I am struggling to find any reference in any
standard that supports this view. Mailing list posts doesn't really
count here, even if they number in the thousands. I'm interested in
learning which section of which RFC is telling me I'm incorrect. Give
me a pointer to that and I'll shut up.

We can even disregard RFC 7084, as it's not a standard. RFC 4861
Section 4.2 is where the flags and their meaning is specified. It says,
and I quote:

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

So DHCPv6-provided configuration is divided into two categories:

1) addresses
2) other

The availability of both of these categories of configuration is
signalled through the M/O flags. Nowhere that I can find is a third
«other than "other"» category of DHCPv6-provided configuration defined
or even hinted at.

So to me, the only logical interpretation of the above, is that the
availability of every single DHCPv6 option - including IA_PD - is
signalled through the O/M flags.

What RFC 4861 goes on to say makes me even more certain of this
interpretation:

        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.

> do DHCP PD (include other options as indicated above)

Your pseudocode seems to confirm that you consider the IA_PD to be in
this third apparently-not-specified-anywhere «other than "other"»
category of DHCPv6-provided configuration.

It also appears to ignore the «If neither M nor O flags are set, this
indicates that no information is available via DHCPv6» statement. (But
I would agree that ignoring this "indication" is not forbidden.)

And finally it does not faithfully represent RFC 7084. Your code will
unconditionally request IA_PD in the O=M=0 case, while RFC 7084 says
this combination is «out of scope»:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.  Behavior of the
           CE router to use DHCPv6 prefix delegation when the CE router
           has not received any RA or received an RA with the M and the
           O bits set to zero is out of scope for this document.

In other words, your pseudocode seems to instead represent this
requirement (which is *not* a quote from RFC 7084):

           delegation.

That said, I do not mean to say that requesting IA_PD when O=M=0 is a
wrong thing to do for a RFC 7084 CE. The O=M=0 case is, after all, left
unspecified.

> your pseudocode also had the bug of coupling DHCP and SLAAC address

Agreed.

In any case, I think we can also agree that it is improper for
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00 to imply that the
availability of IA_PD is contingent on the M flag alone?

The authors could avoid opening this apparent can of worms by changing
the current bullet:

With:

   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6).

That way, the draft doesn't say anything controversial, and we can
leave the discussion on if IA_PD is «addresses», «other than
addresses», or «other than "other than addresses"» for another day.

[The draft does in any case goes on to say that O should be set to 1,
which means the described network already accomodates for (future) use
of IA_PD for both of our world views: an UE implemented by me would
then request IA_PD because of O=1, and one written by you would - AIUI
- just ignore the O/M flags and request IA_PD unconditionally.]

Tore

---

From: Tore Anderson <[email-masked]>
Date: Fri, 30 Oct 2015 08:17:39 +0100

* Brian E Carpenter <[email-masked]>

> "we run DHCPv6 but forgot to set the bits". But I don't know what to

Another possibility is that there are multiple routers on the link
but not all of them one of them include a, or are aware of any, DHCPv6
service present on the link.

To accomodate for such a network I'd expect nodes to determine the
effective value of the flag in question to be 1 as long as at least 1
RA with the flag set to 1 is received (boolean OR, in other words).
Consequentally, a single RA with M=O=0 shouldn't be understood to
authoritatively communicate that there is no DHCPv6 service present on
the link.

However if each and every received RA on the link contain M=O=0 I think
it is the most expected node behaviour (cf. RFC4861's statement that
M=O=0 «indicates that no information is available via DHCPv6») to not
start any DHCPv6 client at all - and for the record, that would mean
not requesting IA_PD.

Tore

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Oct 2015 08:38:54 +0100

Hi,

[..]
> «other than "other"» category of DHCPv6-provided configuration defined

I do not have RFCs to counter that, but my interpretation is a bit
different.  I see that section of 4861 as traditionally applied to 
*hosts*, while IA_PD traditionally is a *router* function, so out of 
scope for the "host part" of 4861.

Now this gets all muddled together when you have a router that also 
wants an address for itself (= acting as a host for that purpose) or 
a host that wants a prefix (= serving as a router for that prefix).

Conceptually, still, "address for me" is a fairly independent thing
from "prefix for something I serve as a router"...  and 4861/O/M only
seem to cover the "address for me" part.

Gert Doering
        -- NetMaster

---

From: Tore Anderson <[email-masked]>
Date: Fri, 30 Oct 2015 09:10:55 +0100

Hi Gert,

* Gert Doering <[email-masked]>

> scope for the "host part" of 4861.

Section 4.2 of RFC 4861 simply describes the RA message format, it's
not in a "host part" of the RFC as far as I can tell. Keep in mind that
RAs are typically multicast to all IPv6 nodes, so the originating router
does not know whether it is a host or a router (or both, or none) that
will be receiving the RA.

Thus, when determining whether or not to set the M/O flags, the
[operator configuring the] RA originating router will have to ask
himself the following question:

«Is there information available through DHCPv6 to nodes on this link?»

If the answer to that question is «yes», the M or O flag should be set.
If the answer is «no», they should be both unset.

> a host that wants a prefix (= serving as a router for that prefix).

I'll note that this discussion started with a comment on
draft-jjmb-v6ops-unique-ipv6-prefix-per-host. This draft talks about
hosts, not routers. It even says so right there in the file name and
the title.

Then you have RFC 7084 which to the best of my knowledge is describes
the only use case for DHCPv6-PD which has seen significant deployment
to date. Its WPD-4 requirement clearly indicates that the availability
of DHCPv6-PD is something that should be communicated through the M/O
options.

The WPD-4 requirement essentially states that if you operate a network
that provides IA_PD and sets M=O=0, it's unspecified ("out of scope")
whether or not any connecting devices conforming to RFC 7084 end up
with a delegated prefix or not.

Tore

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Oct 2015 09:21:31 +0100

Hi,

> will be receiving the RA.

Yes, but that is the point - "typical routers" do not need to *listen* to 
RAs, because that's not required for their job.  They will speak a 
routing protocol, and not default-route, etc.

As I said, boundaries between "hosts" and "router" are less than clear
today - but this is my interpretation on how these have come into place.

> If the answer is «no», they should be both unset.

There might not even *be* a RA if this is a pure router-to-router link...

> hosts, not routers. It even says so right there in the file name and

True, but as soon as a host requests a prefix for "a bunch of VMs" running
on that same host, and forwards traffic between "the outside router" and
"the various VMs", it very much becomes a router...

Gert Doering
        -- NetMaster

---

From: Tore Anderson <[email-masked]>
Date: Fri, 30 Oct 2015 09:55:38 +0100

> Yes, but that is the point - "typical routers" do not need to
> *listen* to RAs, because that's not required for their job.  They
> will speak a routing protocol, and not default-route, etc.

Who is listening for RAs or not seems to me to be besides the point. It
boils down to this: If you are about to originate an RA to a link, and
know that there is information available in DHCPv6 on said link, you
should set set the M or O flag. Otherwise you're supplying false
information by indicating that there is no information available in
DHCPv6.

The possibility of there being a node (router) on the link that does
not listen to RAs does not seem relevant - you'd still be giving out
false information to anyone else on that link.

> today - but this is my interpretation on how these have come into place.

Indeed. Thus I believe claims like «hosts don't request prefixes» or
«routers don't process RAs» can't be considered true (unless a node can
be both simultaneously).

> There might not even *be* a RA if this is a pure router-to-router

If you're not sending any RAs to begin with then you obviously do not
have to set any RA flags. That's fine. My point is just that IFF you
send RAs, make sure you send correct information - by setting the M or O
flag if there is any form DHCPv6 service being provided to the link.

In any case I don't think RA-less pure router-to-router links are
particularly relevant to a discussion on whether or not DHCPv6-PD is
signalled using the M/O RA flags. At least I have never seen a use case
where DHCPv6-PD being used on such RA-less router-to-router links, have
you?

> as soon as a host requests a prefix for "a bunch of VMs" running on
> that same host, and forwards traffic between "the outside router" and

...that, crucially, will continue to process RAs (just like a RFC 7084
CE router will). So the RA we're sending that host ought to contain
correct information.

Tore

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Oct 2015 10:06:47 +0100

Hi,

> information by indicating that there is no information available in

No, the point I was trying to made is: conceptually, DHCPv6 PD is happening
outside RA.  RA is "information to hosts", PD is "done by routers".

But I already agreed that this is not written down anywhere, but my
interpretation on how this can all make sense.

[..]
> «routers don't process RAs» can't be considered true (unless a node can

We had this discussion in the context of the CPE spec - a CPE is a 
router (obviously), but for acquiring its management IPv6 address and
for being talked to on the management address, it's very obviously a
host as well.  So of course a node can be both.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Oct 2015 14:42:07 +0000

Hi Mark,

> From: Mark Smith [mailto:[email-masked]]
> Sent: Thursday, October 29, 2015 7:12 PM
> To: Templin, Fred L
> Cc: [email-masked]; Brian E Carpenter; [email-masked]; Tore Anderson; 神明達哉

Yes, AERO is an example. 

> link-local addresses to use for all IPv6 operations and applications.

In the case of AERO, if a stateful DHCPv6 server is not available the
hosts can still communicate using link-layer addressing and the AERO
link will not be activated.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Oct 2015 14:45:08 +0000

Hi Gert,

> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Friday, October 30, 2015 2:07 AM
> To: Tore Anderson
> Cc: [email-masked]; [email-masked]
> Subject: Re: [v6ops] M/O flags and PD
> 
> Hi,
> 
> > Indeed. Thus I believe claims like <hosts don't request prefixes> or
> > <routers don't process RAs> can't be considered true (unless a node can
> > be both simultaneously).
> 

Right, and it is fine for a host to act as a requesting router from the
standpoint of DHCPv6 PD but then use the delegated prefix for its
own multi-addressing purposes rather than to provision addresses
for other hosts.

Thanks - Fred

---

From: Sander Steffann <[email-masked]>
Date: Fri, 30 Oct 2015 16:24:38 +0100

Hi Tore,

> will be receiving the RA.

I always understood this bit from RFC 3633 to mean that any host configuration flags (such as M/O) are not relevant to DHCPv6-PD: "Note that this use of DHCP is not bound to the assignment of IP addresses or other configuration information to hosts".

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Oct 2015 08:08:32 +1300

> I always understood this bit from RFC 3633 to mean that any host configuration flags (such as M/O) are not relevant to DHCPv6-PD: "Note that this use of DHCP is not bound to the assignment of IP ad…

The phrase "is not bound to" is rather unclear, don't you think? It neither says
nor implies that routers are thereby exempt from issuing correct RAs.

However, being realistic, note that
On 30/10/2015 21:55, Tore Anderson wrote:

> It boils down to this: If you are about to originate an RA to a link, and
> should set set the M or O flag.

Even if you accept that, in the case that you *don't* know that such information
is available, you physically cannot set the M or O flag. So in the real world,
a node that is interested in IA_PD had better go fishing for it, whatever the
MO bits say. So I retract all the if statements in the pseudocode that I sent.
The only robust implementation is one that always looks for DHCPv6 information.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Sat, 31 Oct 2015 08:12:14 +1100

In message <[email-masked]>, Brian E Carpenter writes:
> > I always understood this bit from RFC 3633 to mean that any host configuration flags (such as M/O) are not relevant to DHCPv6-PD: "Note that this use of DHCP is 
> not bound to the assignment of IP addresses or other configuration information to hosts".
> 

Read the whole paragraph.  This has nothing to do with RA bits.

   "Note that this use of DHCP is not bound to the assignment of IP
   addresses or other configuration information to hosts, and that no
   mechanism is currently available to communicate delegated prefixes to
   a DHCP server that serves such a function.  This may be an item of
   future work, should usage warrant."

I see that as saying that there is no mechanism defined to inform
a DHCPv6 server of the prefix obtained and that the IETF may need
to do so in the future.  In most cases of the use cases DHCP server
is in the router so the router vendor just figures this out for
themselves (e.g. the dhcp client updates the dhcp server's configuration
and tells the dhcp server to reload).  In case where there is a
seperate DHCP server and the router is just the DHCP relay is left
unspecified how the obtained addresses are communicated.

Additional there is no requirement for there to be a DHCPv6 server
at all.  SLAAC or something else is sufficient.  This is the first
part of the paragraph.

This document is not a complete solution.  There are missing bits that
need to be specified to make it a complete solution.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Sat, 31 Oct 2015 09:46:21 +0100

* Brian E Carpenter

> > I always understood this bit from RFC 3633 to mean that any host
> > configuration flags (such as M/O) are not relevant to DHCPv6-PD:
> > addresses or other configuration information to hosts".	
> 
> The phrase "is not bound to" is rather unclear, don't you think? It
> neither says nor implies that routers are thereby exempt from issuing
> correct RAs.

Agreed.

Also, note that RFC 3633 did *not* update RFCs 2461/2462, which at the
time defined the meaning of the O/M flags to be essentially the same as
what RFC 4861 defines them to be today.

> Even if you accept that, in the case that you *don't* know that such
> information is available, you physically cannot set the M or O flag.
> So in the real world, a node that is interested in IA_PD had better
> go fishing for it, whatever the MO bits say. So I retract all the if
> statements in the pseudocode that I sent. The only robust
> implementation is one that always looks for DHCPv6 information.

That might indeed be the case - but it's not what the standards are
currently telling the implementers to do. Furthermore, accepting this
would mean that the M/O flags are essentially pointless. In that case,
deprecating the flags would be the logical thing to do.

(You explicitly called out IA_PD, but as your argument applies equally
well to any other DHCPv6 option I'm going to assume you meant IA_PD
just as an example.)

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Nov 2015 07:59:47 +1300

> deprecating the flags would be the logical thing to do.

I know. It's a bit depressing.

> well to any other DHCPv6 option I'm going to assume you meant IA_PD

Yes, although it's the example that led to this thread.

  Brian