Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

From: [email-masked]
Date: Sun, 03 Jan 2016 19:16:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Host address availability recommendations
        Authors         : Lorenzo Colitti
                          Vint Cerf
                          Stuart Cheshire
                          David Schinazi
	Filename        : draft-ietf-v6ops-host-addr-availability-04.txt
	Pages           : 13
	Date            : 2016-01-03

Abstract:
   This document recommends that networks provide general-purpose end
   hosts with multiple global IPv6 addresses when they attach, and
   describes the benefits of and the options for doing so.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-04

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

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 4 Jan 2016 12:25:58 +0900

On Mon, Jan 4, 2016 at 12:16 PM, <[email-masked]> wrote:

> [...]

Summary of the changes in this version :

   1. The text about omitting DAD agreed with Fred Templin.
   2. The suggestions from David Farmer to clarify the scope of the
   document: explicitly say that protocol changes and host behaviour are out
   of scope, reword "assign" to provide", etc.
   3. A statement that while RFC 3633 talks about "requesting router",
   DHCPv6 PD itself doesn't actually require that the client forward packets,
   and thus does not require that the client be a router as defined in RFC
   2460.

Cheers,
Lorenzo

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 4 Jan 2016 13:42:07 +0100

Le 04/01/2016 04:25, Lorenzo Colitti a écrit :
> On Mon, Jan 4, 2016 at 12:16 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>              Filename        :
>     draft-ietf-v6ops-host-addr-availability-04.txt
>              Pages           : 13
>              Date            : 2016-01-03
>
>     [...]
>
>     document: explicitly say that protocol changes and host behaviour
>     are out of scope, reword "assign" to provide", etc.
>     DHCPv6 PD itself doesn't actually require that the client forward
>     packets, and thus does not require that the client be a router as
>     defined in RFC 2460.

Lorenzo - I noticed earlier emails where a doubt about DHCP-PD RFC 
relying on these to be Routers, or not.

I agree with you the DHCP-PD RFC calls them Routers.  It may rightfully 
not go too deep into requiring them to forward packets or maintain a 
FIB.  It would be too many things to require.  Maybe just calling them 
Routers is sufficient, for brevity.

At the same time, certainly DHCP-PD RFC is not specified with Hosts in 
mind and this is not good.

Alex

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jan 2016 16:15:29 +0000

Hi Lorenzo,

I believe this document should also include an informative reference to AERO
as the method for managing DHCPv6-PD delegated prefixes.

Thanks – Fred
[email-masked]

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Sunday, January 03, 2016 7:26 PM
To: internet-drafts
Cc: [email-masked] WG; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

On Mon, Jan 4, 2016 at 12:16 PM, <[email-masked]<mailto:[email-masked]>> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

[...]

  1.  The text about omitting DAD agreed with Fred Templin.
  2.  The suggestions from David Farmer to clarify the scope of the document: explicitly say that protocol changes and host behaviour are out of scope, reword "assign" to provide", etc.
  3.  A statement that while RFC 3633 talks about "requesting router", DHCPv6 PD itself doesn't actually require that the client forward packets, and thus does not require that the client be a router as defined in RFC 2460.
Cheers,
Lorenzo

---

From: David Farmer <[email-masked]>
Date: Mon, 4 Jan 2016 10:24:31 -0600

> On Jan 4, 2016, at 06:42, Alexandre Petrescu <[email-masked]> wrote:
> Lorenzo - I noticed earlier emails where a doubt about DHCP-PD RFC relying on these to be Routers, or not.
> 
> I agree with you the DHCP-PD RFC calls them Routers.  It may rightfully not go too deep into requiring them to forward packets or maintain a FIB.  It would be too many things to require.  Maybe just calling them Routers is sufficient, for brevity.
> 
> At the same time, certainly DHCP-PD RFC is not specified with Hosts in mind and this is not good.
> 
> Alex

In RFC3633, requesting router is defined "the router that acts as a DHCP client and is requesting prefix(es) to be assigned."  In RFC3315, DHCP Client (or Client) is defined as, "a node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers."  With the clarification Lorenzo provides I think it is clear that DHCPv6 PD is just a protocol to obtain a prefix as a configuration parameter and makes no requirements that only routers can obtain prefixes.

How about the further clarification;

   While [RFC3633] primarily considers the use case defined in [RFC3769] and 
   refers to the DHCP client as a "requesting router", DHCPv6 PD itself does not 
   require that the DHCP client receiving the IPv6 prefix parameter forward 
   IPv6 packets not addressed to itself, and thus does not require that the DHCP 
   client be an IPv6 router as defined in [RFC2460].  

Thanks

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Jan 2016 01:40:36 +0900

Fred.

I do not think it is appropriate to add such a reference. AERO is only one
way to use address space delegated by DHCPv6 PD, and there are other,
perhaps more obvious ways, such as using the addresses directly without a
tunnel. I think providing a taxonomy of the different ways to make DHCPv6
PD work is out of scope for a document whose primary message but "don't
limit the number of addresses the network hands out to hosts".

Cheers,
Lorenzo

On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L <[email-masked]>
wrote:

> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *Lorenzo
> Colitti
> *Sent:* Sunday, January 03, 2016 7:26 PM
> *To:* internet-drafts
> *Cc:* [email-masked] WG; [email-masked]
> *Subject:* Re: [v6ops] I-D Action:

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Jan 2016 01:45:43 +0900

On Mon, Jan 4, 2016 at 9:42 PM, Alexandre Petrescu <
[email-masked]> wrote:

> not go too deep into requiring them to forward packets or maintain a FIB.
> It would be too many things to require.  Maybe just calling them Routers is
> sufficient, for brevity.
>

Do you disagree with the text that is in the draft now?

      While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
      PD itself does not require that the client forward IPv6 packets
      not addressed to itself, and thus does not require that the client
      be an IPv6 router as defined in [RFC2460].

That statement seems pretty straightforward to me.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 4 Jan 2016 16:49:43 +0000

I was silent in front of the avalanche about -03 but as things are quieter now:

This document is on the obvious side for problem statement and solutions (all sensible).

I would argue that a lot of text could be removed (such as the discussion on why organizations use DHCP rather than SLAAC -- but hey my own employer uses DHCP :-) )

Some questions:

  *   Q1) The I-D is about multiple addresses with a prefix, but, should it mention as well the possibility of having different prefixes? (à la MIF on a single link) ==> should explicitely reduce the scope of the I-D
  *   Q2) Any reason why only a /64 per host when using DHCP-PD?
  *   Q3) Should the I-D write anything about the stability of the delegated prefix? I.e. Being always the same for the same DUID? Goal: avoid renumbering within the host? Of course 'if technically feasible'

-éric

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: lundi 4 janvier 2016 04:25
To: internet-drafts <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

[...]

Cheers,
Lorenzo

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jan 2016 16:55:22 +0000

Hi Lorenzo,

People have asked about how fault tolerance works, and AERO provides the answer.
People have asked about how mobility works, and AERO provides the answer.
People have asked how path MTU robustness works, and AERO provides the answer.
People should be asking how route optimization works, and AERO provides the answer.

In my experience, the IETF loves a problem and will not tolerate a solution. In this
case, AERO is a widely applicable solution that is being overlooked and ignored in
this fashion. We need to break out of that mold and go with something that
stands a chance of working, and AERO is it.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, January 04, 2016 8:41 AM
To: Templin, Fred L
Cc: internet-drafts; [email-masked] WG; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

Fred.

I do not think it is appropriate to add such a reference. AERO is only one way to use address space delegated by DHCPv6 PD, and there are other, perhaps more obvious ways, such as using the addresses directly without a tunnel. I think providing a taxonomy of the different ways to make DHCPv6 PD work is out of scope for a document whose primary message but "don't limit the number of addresses the network hands out to hosts".

Cheers,
Lorenzo

On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lorenzo,

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

From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lorenzo Colitti
Sent: Sunday, January 03, 2016 7:26 PM
To: internet-drafts
Cc: [email-masked]<mailto:[email-masked]> WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

[...]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Jan 2016 11:50:08 +0900

Fred,

yes, I know you think AERO provides the answer to all known problems ;-)

More seriously:

   - As an author, I oppose adding a reference for the reasons I gave above
   (and additionally, I think there is likely a procedural issue with citing
   an experimental RFC from a BCP).
   - As a host implementer, I would much rather implement DHCPv6 PD without
   AERO than with AERO. It's much simpler on the client side, and it has no
   network-side dependencies, so it seems more likely to be deployable. This
   is my opinion, and I doubt that I will easily be convinced otherwise.

That said: the IETF process is based on rough consensus. From what I've
seen so far, you are the only WG participant arguing for a reference to
AERO in this document, but if somehow rough consensus emerges that this is
the right thing to do (and it emerges quickly; bear in mind that we're well
past the end of the supplemental post-WGLC comment period that Fred
declared a few weeks ago), then we can re-evaluate.

Cheers,
Lorenzo

On Tue, Jan 5, 2016 at 1:55 AM, Templin, Fred L <[email-masked]>
wrote:

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Monday, January 04, 2016 8:41 AM
> *To:* Templin, Fred L
> *Cc:* internet-drafts; [email-masked] WG; [email-masked]
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Jan 2016 12:17:41 +0900

On Tue, Jan 5, 2016 at 1:49 AM, Eric Vyncke (evyncke) <[email-masked]>
wrote:
>
> Some questions:
>
>    - Q1) The I-D is about multiple addresses with a prefix, but, should
>    it mention as well the possibility of having different prefixes? (à la MIF
>    on a single link) ==> should explicitely reduce the scope of the I-D
>
> I think that question is out of scope for this document. Addresses from
multiple prefixes are orthogonal to the main thrust of the draft, which is
"don't restrict the number of addresses". Multihoming with multiple
prefixes is actively being worked on elsewhere - Fred's drafts in 6man,
homenet, etc.

>
>    - Q2) Any reason why only a /64 per host when using DHCP-PD?
>
> Section 6 talks about all cases - < /64, /64 and > /64 (but says that /64
is outside the current IPv6 specifications). The recommendation is /64 to
balance flexibility (e.g., the ability to be extended downstream) with
address space conservation.

>
>    - Q3) Should the I-D write anything about the stability of the
>    delegated prefix? I.e. Being always the same for the same DUID? Goal: avoid
>    renumbering within the host? Of course 'if technically feasible'
>
> I think that should be out of scope.

---

From: David Farmer <[email-masked]>
Date: Mon, 4 Jan 2016 21:56:51 -0600

I would oppose such a reference only to AERO.  I wouldn't oppose a list 
of "other solutions", that included AERO, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host, and others too, maybe 
added to sections 6 in a small paragraph following the table.  However, 
I think the draft is fine without it currently, especially with only 1 
or 2 others to add.

On 1/4/16 20:50 , Lorenzo Colitti wrote:
>   * As an author, I oppose adding a reference for the reasons I gave
>     above (and additionally, I think there is likely a procedural issue
>     with citing an experimental RFC from a BCP).
>   * As a host implementer, I would much rather implement DHCPv6 PD
>     without AERO than with AERO. It's much simpler on the client side,
>     and it has no network-side dependencies, so it seems more likely to
>     be deployable. This is my opinion, and I doubt that I will easily be
>     convinced otherwise.
>
> AERO in this document, but if somehow rough consensus emerges that this
> is the right thing to do (and it emerges quickly; bear in mind that
> we're well past the end of the supplemental post-WGLC comment period
> that Fred declared a few weeks ago), then we can re-evaluate.
>
> Cheers,
> Lorenzo
>
> On Tue, Jan 5, 2016 at 1:55 AM, Templin, Fred L
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Lorenzo,____
>
>     __ __
>
>     People have asked about how fault tolerance works, and AERO provides
>     the answer.____
>
>     People have asked about how mobility works, and AERO provides the
>     answer.____
>
>     People have asked how path MTU robustness works, and AERO provides
>     the answer.____
>
>     People should be asking how route optimization works, and AERO
>     provides the answer.____
>
>     __ __
>
>     In my experience, the IETF loves a problem and will not tolerate a
>     solution. In this____
>
>     case, AERO is a widely applicable solution that is being overlooked
>     and ignored in____
>
>     this fashion. We need to break out of that mold and go with
>     something that____
>
>     stands a chance of working, and AERO is it.____
>
>     __ __
>
>     Thanks - Fred ____
>
>     __ __
>
>     *From:*Lorenzo Colitti [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* internet-drafts; [email-masked] <mailto:[email-masked]> WG;
>     [email-masked] <mailto:[email-masked]>
>
>
>     draft-ietf-v6ops-host-addr-availability-04.txt____
>
>     __ __
>
>     Fred.____
>
>     __ __
>
>     I do not think it is appropriate to add such a reference. AERO is
>     only one way to use address space delegated by DHCPv6 PD, and there
>     are other, perhaps more obvious ways, such as using the addresses
>     directly without a tunnel. I think providing a taxonomy of the
>     different ways to make DHCPv6 PD work is out of scope for a document
>     whose primary message but "don't limit the number of addresses the
>     network hands out to hosts".____
>
>     __ __
>
>     Cheers,____
>
>     Lorenzo____
>
>     __ __
>
>     On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:____
>
>         Hi Lorenzo,____
>
>         ____
>
>         I believe this document should also include an informative
>         reference to AERO____
>
>         as the method for managing DHCPv6-PD delegated prefixes.____
>
>         ____
>
>         Thanks – Fred____
>
>         [email-masked] <mailto:[email-masked]>____
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 5 Jan 2016 06:37:10 +0000

Lorenzo,

Regarding Q1, my only suggestion is to clarify the scope of your I-D by stating something along the line of 'This technique should be applied to all prefixes on the link'

-éric

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: mardi 5 janvier 2016 04:17
To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

On Tue, Jan 5, 2016 at 1:49 AM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Some questions:

I think that question is out of scope for this document. Addresses from multiple prefixes are orthogonal to the main thrust of the draft, which is "don't restrict the number of addresses". Multihoming with multiple prefixes is actively being worked on elsewhere - Fred's drafts in 6man, homenet, etc.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Jan 2016 15:50:13 +0900

On Tue, Jan 5, 2016 at 3:37 PM, Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Regarding Q1, my only suggestion is to clarify the scope of your I-D by
> stating something along the line of 'This technique should be applied to
> all prefixes on the link'
>

No objections with your intent, but... isn't that obvious?

I don't see how it's possible to interpret the text of this document as
saying that a network can/should provide unlimited addressing on one prefix
but only one address on another prefix.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Jan 2016 10:30:35 +0100

Le 04/01/2016 17:24, David Farmer a écrit :
>
> On Jan 4, 2016, at 06:42, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>>> 3. A statement that while RFC 3633 talks about "requesting
>>> router", DHCPv6 PD itself doesn't actually require that the
>>> client forward packets, and thus does not require that the
>>> client be a router as defined in RFC 2460.
>>
>> I agree with you the DHCP-PD RFC calls them Routers.  It may
>> rightfully not go too deep into requiring them to forward packets
>> or maintain a FIB.  It would be too many things to require.  Maybe
>> just calling them Routers is sufficient, for brevity.
>>
> In RFC3633, requesting router is defined "the router that acts as a
> DHCP client and is requesting prefix(es) to be assigned." In
> RFC3315, DHCP Client (or Client) is defined as, "a node that
> initiates requests on a link to obtain configuration parameters from
> one or more DHCP servers." With the clarification Lorenzo provides I
> think it is clear that DHCPv6 PD is just a protocol to obtain a
> prefix as a configuration parameter and makes no requirements that
> only routers can obtain prefixes.
>
>
> While [RFC3633] primarily considers the use case defined in
> [RFC3769]

...for fixed routers, and RFC6276 and RFC7148 for mobile routers,

> and refers to the DHCP client as a "requesting router", DHCPv6 PD
> itself does not require that the DHCP client receiving the IPv6
> prefix parameter forward IPv6 packets not addressed to itself.

This reads sufficient.

> and thus does not require that the DHCP client be an IPv6 router as
> defined in [RFC2460].

This is superfluous.  The "thus" does not follow.

The rfc2460 definition of a router includes a "Note" which, if 
understood as I do, makes think that a DHCPv6 PD Host with multiple 
interfaces is actually a Router.

Alex

>
>
> Thanks
>
>
> -- =============================================== David Farmer
> Email: [email-masked] <mailto:[email-masked]> Office of Information
> Technology University of Minnesota 2218 University Ave SE Phone:
> +1-612-626-0815 Minneapolis, MN 55414-3029   Cell: +1-612-812-9952

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Jan 2016 10:40:38 +0100

Le 04/01/2016 17:45, Lorenzo Colitti a écrit :
> On Mon, Jan 4, 2016 at 9:42 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     rightfully not go too deep into requiring them to forward packets or
>     maintain a FIB.  It would be too many things to require.  Maybe just
>     calling them Routers is sufficient, for brevity.
>
>

The statement is too long.

For one, its latter part clashes with some interpretation of rFC2460 by 
which a Router does forward between its virtual interfaces.

I think the intention is to express that DHCP-PD has not been specified 
as a way for a single-interfaced Host to obtain multiple addresses for 
itself.  If that's the intention then I agree.  Because DHCPv6-PD has 
been specified and implemented mainly for site routers like CPEs, or for 
(P)MIP Mobile Routers - they all RA the delegated prefixes further down 
to other computers.  This behaviour (send RA containing the delegated 
prefix) is always in the implementations although the DHCP-PD specs are 
mostly silent about it, IIRC.

This can lead to a problem statement.

Because what one wants in this newDHCP-PD Client behaviour is to _not_ 
RA the delegated prefix to other computers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Jan 2016 10:41:31 +0100

>   * Q2) Any reason why only a /64 per host when using DHCP-PD?

I have the same question.

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 5 Jan 2016 10:49:41 +0100

Hi,

> I have the same question.

At some point the address policy fairy will come and eat you all.

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: Philip Homburg <[email-masked]>
Date: Tue, 05 Jan 2016 14:08:21 +0100

>   (and additionally, I think there is likely a procedural issue with citin=
>g
>   network-side dependencies, so it seems more likely to be deployable. Thi=
>s

Just my opinion, reclassify as informational and then just include the
reference to AERO.

>From all the discussion we had, we know:
- there are essentially no hosts requesting DHCPv6-PD
  (I wonder if there are any hosts requesting multiple addresses using
  DHCPv6 IA_NA).
- we know that in the CPE world there are at least two different approaches of
  doing DHCPv6-PD which does affect how the network provides those
  addresses. (And also affects client implementations)

So in short, there simply is no real practice when it comes to a large part
of this document. Which also why Fred can bring up AERO, because there
may even be more actual hosts (rather than CPEs) doing AERO than hosts
requesting DHCPv6-PD through other means.

And we also have to curious word play where a host that uses a prefix 
obtained through DHCPv6-PD has to be a router from the point of view of ND, and
is actually a router in one of the use cases (tethering). And will be a router
in many implementations (AREO seems an exception in assigning adresses to
the upstream interface), but we insist in calling it a host.

So, publish as informational. Actually get some experience deploying 
exactly what is proposed here. And then write a BCP on what is actually
deployed and how that works.

I think we need a lot more of 'this is how IPv6 really works' and not
these are the 5 different ways you can do stuff.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Jan 2016 00:21:17 +0900

On Tue, Jan 5, 2016 at 10:08 PM, Philip Homburg <[email-masked]>
wrote:

> of this document.

But it's not a "large part of the document" at all. It's not even a large
part of the requirements section. I think what you are disagreeing with is
only one of the recommendations, which is "if your network will only allow
hosts to connect if they do DHCPv6, then don't hand out an addres via
IA_NA, but hand out a prefix via DHCPv6 PD".

> obtained through DHCPv6-PD has to be a router from the point of view of ND,

No, that's not true. A router is "a node that forwards packets not
explicitly addressed to itself" [RFC2460]. A host that uses a prefix
obtained using DHCPv6 PD does not need to do that.

> and is actually a router in one of the use cases (tethering). And will be
> a router

> the upstream interface), but we insist in calling it a host.

Looks like you're assuming that a node needs to be a router in order to
send a packet on one interface with a source address assigned to another
interface. That's not true at all. In fact, to give you an idea on how this
works I just ran a DHCPv6 PD client on my linux laptop to get a prefix from
my home router, picked an address out of the prefix, assigned it to lo, and
used it:

   1. dhclient -d -6 -D LL -P eth0   # Run PD and note the prefix you get.
   I got 2400:2410:20c0:4450::/60
   2. ip -6 addr add dev lo 2400:2410:20c0:4450::1/128    # Pick an address
   out of the prefix, assign to lo
   3. ping6 -I 2400:2410:20c0:4450::1 www.google.com   # Use that address
   to talk to the Internet via eth0

This all works as expected (and as predicted by the specifications). My
laptop sends the packets on eth0 because it's the interface with the
default route, both my laptop and my home router do NUD for the link-local
address of the other device, and packets flow. My laptop is most certainly
a host, and IPv6 forwarding is off.

As for tethering - sure, a device with tethering enabled is a router. But
that's a minor point. If you were to pick only one of the two, would you
say that your phone and your laptop are "hosts" or "routers"? I think it's
appropriate to call them "hosts", even though they occasionally act as
routers. I suppose the word "node" would be more correct, but it would be
much less readable.

> deployed and how that works.

Again, I think you're not seeing the forest for the (DHCPv6 PD) tree. The
point of this document is not "networks should use DHCPv6 PD". The point of
this document is "networks that provide service to general purpose devices
should provide those devices with multiple addresses at connection time".
As the draft says, that statement is true of the networks used by tens of
millions of devices every day: pretty much every home network, all 3GPP
networks, and so on.

DHCPv6 PD is cited simply because if a network has decided "we will use
DHCPv6 and nothing else", then the only possible way to assign enough
addresses is to use DHCPv6 PD. But that's a tiny minority of the networks
out there, and it's only a small part of the draft.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jan 2016 18:43:49 +0000

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Monday, January 04, 2016 6:50 PM
To: Templin, Fred L
Cc: [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

Fred,

More seriously:
• As an author, I oppose adding a reference for the reasons I gave above (and additionally, I think there is likely a procedural issue with citing an experimental RFC from a BCP).

FLT>>> The citation would be to “draft-templin-aerolink” which is being proposed as standards-track.
FLT>>> There are plenty of examples of informative citations of works in progress in published RFCs.

• As a host implementer, I would much rather implement DHCPv6 PD without AERO than with AERO. It's much simpler on the client side, and it has no network-side dependencies, so it seems more likely to be deployable. This is my opinion, and I doubt that I will easily be convinced otherwise.

FLT>>> That is incorrect. My AERO DHCPv6 client code is much simpler than, e.g., the ISC dhclient
FLT>>> code that does not do AERO. Have a look at my code.

That said: the IETF process is based on rough consensus. From what I've seen so far, you are the only WG participant arguing for a reference to AERO in this document, but if somehow rough consensus emerges that this is the right thing to do (and it emerges quickly; bear in mind that we're well past the end of the supplemental post-WGLC comment period that Fred declared a few weeks ago), then we can re-evaluate.

FLT>>> It seems like there is still emerging consensus on this. Remember also that
FLT>>> many questions were asked and AERO provided answers to each. That
FLT>>> would seem to indicate a need for an informative reference.
FLT>>>
FLT>>> Thanks - Fred

Cheers,
Lorenzo

On Tue, Jan 5, 2016 at 1:55 AM, Templin, Fred L <[email-masked]> wrote:
Hi Lorenzo,

 
Thanks - Fred 

 
Fred.

Cheers,
Lorenzo
 
On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L <[email-masked]> wrote:
Hi Lorenzo,

Thanks – Fred

[...]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Jan 2016 10:41:49 +0900

> progress in published RFCs.

Fair enough, but my earlier concerns (also expressed by David Farmer, IIRC)
still stand.

> • As a host implementer, I would much rather implement DHCPv6 PD without

I stand by my statement. I don't see how you can argue that implementing
DHCPv6 PD plus AERO is simpler than implementing DHCPv6 PD by itself. The
fact that your code is simpler than the ISC client doesn't prove that AERO
is simpler to implement, it only proves that ISC wrote more complicated
code than you did.

> FLT>>> It seems like there is still emerging consensus on this.

It's not my role to declare consensus, but that is very far from my read of
the situation.

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Jan 2016 12:16:31 +0900

> requesting DHCPv6-PD through other means.

I think your assertion is false.

    - The bulk of the document is concerned with important Internet
architectural points.

    - There is obviously considerable experience with SLAAC, a ton of
experience with a unique IPv6 prefix per host on 3GPP, and we have a
document about unique IPv6 prefix per host on wifi in the queue.

    - There are (literally) only a handful of references to PD, which
seems to be your laser focus here.

> deployed and how that works.

I think instead we can publish this as is, and in future v6ops can
look at a document describing host PD implementation and network
operations experience, if such a document even proves necessary (which
I doubt).

I don't see any issue here.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jan 2016 13:58:42 +0100

>IA_NA, but hand out a prefix via DHCPv6 PD".

We discussed this before. I suggested getting rid of all technical detail
and just leave the part that hosts should get multiple addresses. You felt
that we have to say something on how how it should be done.

So, if the technical details are required then in my opinion we also need
to have experience with them. And for general hosts we don't have that
for PD. And there are even two different way in which the network can
provide PD which impacts hosts as well.

So, get rid of the technical details or wait until we have experience with
the listed mechanisms. 

>obtained using DHCPv6 PD does not need to do that.

If you run a VM on a host and create a virtual ethernet to connect to
the VM, then from a networking point of view the host is a router.

There may not be any physical wire, but it behaves very much like a
router.

For the most part a delegated prefix behaves as if it is assigned to a router
even if in some cases it may technically be a host.

>a host, and IPv6 forwarding is off.

Did you look at the ND traffic? Do you expect all traffic from neighboring
hosts to 2400:2410:20c0:4450::/60 to go through your router instead of 
instead of directly to your laptop?

If you ping something other than 2400:2410:20c0:4450::1/128 does that end
up in a blackhole? Or how does your laptop know to send a destination 
unreachable ICMP?

>routers. I suppose the word "node" would be more correct, but it would be

I think we should be more clear on the 'almost be not quite router
devices'. Or it will come back to bite us. 

Yes, a phone or a laptop routing packets is a router. And we should
figure out how to best make them work as routers.

Possibly in a home context, they should just join the homenet routers
to create a single coherent view of what is out there.

Possibly, the same applies to big wifi networks where hosts roam while
providing tethering services.

>out there, and it's only a small part of the draft.

It is simple, if PD is not needed, remove it. PD causes all kinds of 
complexity we don't need. 

If it is just a tiny minority of nework, just write that it doesn't work in
all cases. Solves the problem.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jan 2016 14:04:54 +0100

>operations experience, if such a document even proves necessary (which

I don't think we should write a BCP and then in a future document
describe how it works. That's not what a BCP is for.

If the PD part is not required for this document, then just remove it.

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Jan 2016 22:33:37 +0900

> If the PD part is not required for this document, then just remove it.

I disagree.  PD is a perfectly valid way of addressing the issue and
it needs to be included at some level of description for completeness.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Jan 2016 14:36:20 +0100

sidenote...

Le 05/01/2016 16:21, Lorenzo Colitti a écrit :
> On Tue, Jan 5, 2016 at 10:08 PM, Philip Homburg
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> But it's not a "large part of the document" at all. It's not even a
> large part of the requirements section. I think what you are disagreeing
> with is only one of the recommendations, which is "if your network will
> only allow hosts to connect if they do DHCPv6, then don't hand out an
> addres via IA_NA, but hand out a prefix via DHCPv6 PD".
>

If one reads the Note attached to the router definition in 2460, then 
one understands that a host that uses a prefix obtained with DHCP-PD 
does need to forward, and maybe its apps to explicitate the source address.

>     and is actually a router in one of the use cases (tethering). And
>     will be a router
>
> interface. That's not true at all. In fact, to give you an idea on how
> this works I just ran a DHCPv6 PD client on my linux laptop to get a
> prefix from my home router, picked an address out of the prefix,
> assigned it to lo, and used it:
>
>  2. ip -6 addr add dev lo 2400:2410:20c0:4450::1/128    # Pick an
>     address out of the prefix, assign to lo
>  3. ping6 -I 2400:2410:20c0:4450::1 www.google.com
>     <http://www.google.com>   # Use that address to talk to the Internet
>     via eth0
 >

This is not as expected.  It is the "unusual" word of 2460.

It is unusual in that you had to argument "-I" to that ping6.

The usual way is to be able to say just "ping6 google.com" without 
arguments.

Alex

> default route, both my laptop and my home router do NUD for the
> link-local address of the other device, and packets flow. My laptop is
> most certainly a host, and IPv6 forwarding is off.
>
> As for tethering - sure, a device with tethering enabled is a router.
> But that's a minor point. If you were to pick only one of the two, would
> you say that your phone and your laptop are "hosts" or "routers"? I
> think it's appropriate to call them "hosts", even though they
> occasionally act as routers. I suppose the word "node" would be more
> correct, but it would be much less readable.
>
> Again, I think you're not seeing the forest for the (DHCPv6 PD) tree.
> The point of this document is not "networks should use DHCPv6 PD". The
> point of this document is "networks that provide service to general
> purpose devices should provide those devices with multiple addresses at
> connection time". As the draft says, that statement is true of the
> networks used by tens of millions of devices every day: pretty much
> every home network, all 3GPP networks, and so on.
>
> addresses is to use DHCPv6 PD. But that's a tiny minority of the
> networks out there, and it's only a small part of the draft.
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 00:22:54 +0900

> provide PD which impacts hosts as well.

Assuming that by "technical details" you mean DHCPv6 PD, then we do have
experience with that. As an industry, we do know how to run networks that
delegate prefixes via DHCPv6 PD to routers. It is widely deployed, and your
previous "how can we possibly deal with failure mode X" questions asked on
this list appear to have been answered satisfactorily.

So, given that we know how to build networks that delegate space to routers
using PD, then what is the concern with having the network behave exactly
the same, but have the PD client be a host? I see three possible concerns:

   1. We cannot implement the host part correctly.
   2. We _can_ correctly implement the host part correctly, but we
   _shouldn't_ because there is a better solution.
   3. We _don't know how_ to implement the host part correctly, and we
   should hold off on anything until we know.

#1 seems hard to believe. As for #2, I see no other solution on the
horizon. Are you suggesting we develop a new solution? Why, when we know we
can implement DHCPv6 PD correctly and we have experience with it?

I think you're claiming #3. In other words, you're not saying that we can't
implement PD on hosts, and you're not saying there is a better solution
than PD, but we don't know exactly how to implement it. But I'd argue that
#3 is not a strong technical argument, for two reasons.

First, host behaviour is out of scope for this draft. Because we know how
to do the network side, we can put host behaviour in a subsequent draft, or
leave it to implementers. (Personally it seems to me that that's not rocket
science, since a host is not very different from a router with its LAN
interface unplugged. Also, implementers figured out how to do the network
side correctly without any RFC to guide them. The deployment scenarios in
RFC 3633 certainly doesn't look like the majority of PD networks. Finally,
there is already running code that does this in standard Linux
distributions.)

Second: this document has targeted BCP status and has contained the text on
DHCPv6 from the very beginning. It has survived multiple consensus calls in
that form, so I think that the WG has always been happy with those points.
In the absence if is a solid technical concern that hasn't been thought of
before, I would assume that the WG is still happy with them.

> There may not be any physical wire, but it behaves very much like a

Sure, sometimes VM software routes. Sometimes it bridges. But that's wasn't
the point. My point is that your earlier assertion is incorrect. A host can
use a prefix obtained through DHCPv6 PD without being a router. The IP
addresses in the prefix don't have to be handed out to VMs, they can be
assigned to whatever the host feels like - for example to applications, as
ILA does.

For the most part a delegated prefix behaves as if it is assigned to a
> router

What does that mean? A host "behaves", and a router "behaves", but a prefix
does not "behave". It's just a set of numbers.

> instead of directly to your laptop?

As for ND - like I said, there's NUD for the link-local address. Traffic
from neighbouring hosts will go through the router, of course - from the
perspective of the router, my laptop is exactly the same as a subtended CPE
router connected to one of its LAN ports, which is a fairly common
configuration today. Again - the point is that as far as the network is
concerned, it doesn't matter if the requesting node is a host or a router,
the behaviour is the same.

> up in a blackhole? Or how does your laptop know to send a destination

It depends on how you configure the laptop. In this instance I configured
things manually, so it won't. But you can configure it to. But again -
that's host behaviour, which is out of scope for this draft.

> devices'. Or it will come back to bite us.

Do we? A node is either a host or a router. Everyone agrees that DHCPv6 PD
works for routers. If it works for hosts, and it works for routers, then by
definition it works for all nodes.

> all cases. Solves the problem.

We can't do that, because that leaves the problem of what to do on a
network that has decided to provide address space only via DHCPv6. It seems
to me that there has been pretty strong agreement all along that such
networks should also provide sufficient address space to hosts.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 00:27:40 +0900

On Wed, Jan 6, 2016 at 10:36 PM, Alexandre Petrescu <
[email-masked]> wrote:

> If one reads the Note attached to the router definition in 2460, then one
> understands that a host that uses a prefix obtained with DHCP-PD does need
> to forward, and maybe its apps to explicitate the source address.
>

Why? Consider the ULA use case where a host gets a /64 via DHCPv6 PD and
uses this to assign a different IPv6 address to every process on the
system. The host does not need to forward any packets to anyone on any
interface, and thus is not a router.

> This is not as expected.  It is the "unusual" word of 2460.

The "unusual" word in RFC 2460 refers to a node that forwards packets
arriving on some interfaces but not on others. That is not the case here.
My laptop was not forwarding packets from any interface to any interface
and it was purely a host.

> The usual way is to be able to say just "ping6 google.com" without

If I had not specified -I, someone would have said "there is no proof that
this works, your laptop could have been using another address, one that was
not obtained via DHCPv6 PD". :-)

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 15:56:36 +0000

Hi Lorenzo,

Speaking only to the complexity concern, there are major pieces of DHCPv6 client (e.g.,
DNS server discovery) that are not needed by AERO and hence are not implemented.
AERO is DHCPv6 PD only (no IA_NA, IA_TA, etc.) and adds route optimization, fault
tolerance and mobility support – all of which are optional. You don’t get something
for nothing, so if you want to have, e.g., mobility support it needs to be implemented
but the code for this is not large. The AERO client is thin in the same way that all
DHCPv6 clients should be thin. Are you arguing that it is not thin enough?

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, January 05, 2016 5:42 PM
To: Templin, Fred L
Cc: [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

On Wed, Jan 6, 2016 at 3:43 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
FLT>>> The citation would be to “draft-templin-aerolink” which is being proposed as standards-track.
FLT>>> There are plenty of examples of informative citations of works in progress in published RFCs.

Fair enough, but my earlier concerns (also expressed by David Farmer, IIRC) still stand.

I stand by my statement. I don't see how you can argue that implementing DHCPv6 PD plus AERO is simpler than implementing DHCPv6 PD by itself. The fact that your code is simpler than the ISC client doesn't prove that AERO is simpler to implement, it only proves that ISC wrote more complicated code than you did.

It's not my role to declare consensus, but that is very far from my read of the situation.

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Jan 2016 20:00:13 +0100

Hi,

> that form, so I think that the WG has always been happy with those points.

I missed that this was intended for BCP, otherwise I would have complained
earlier.  Haven't seen anyone state that they are deploying DHCPv6-PD to
hosts except you, so "CP" is really questionable... 

For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds 
about right.

[..]
> the behaviour is the same.

The network is evolving - especially with homenet, the whole model of
cascading DHCPv6-PD CPEs is being abandoned, because there are better ways.

> Do we? A node is either a host or a router. 

Most routers are also hosts by necessity of talking IP for their 
management plane.

[..]
> networks should also provide sufficient address space to hosts.

"just provide multiple addresses with DHCPv6 IA_NA"?

Is actually quite a bit easier to roll out than "build a DHCPv6 PD 
infrastructure"... memory on the DHCPv6 server is cheap, slots on routers
are expensive.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jan 2016 08:39:31 +1300

> For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds 

That seems to be a misunderstanding of the main point of the draft.
PD is incidental to that, surely?

I agree that PD is far from the only implementation mechanism.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 19:57:14 +0000

Hi Gert,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Wednesday, January 06, 2016 11:00 AM
> To: Lorenzo Colitti
> Cc: [email-masked] WG

I have also been talking about PD for hosts:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

> "just provide multiple addresses with DHCPv6 IA_NA"?

As we have been saying, this could result in lots of multicast ND messaging
on the link over which the IA_NAs are received when clients configure lots
of addresses. It is also incompatible withclient mobility,.

> infrastructure"... memory on the DHCPv6 server is cheap, slots on routers

It depends on the service needed by the clients and the deployment of critical
infrastructure in the network. If the clients are mobile, they need to be tracked
in some kind of routing system. The best way to do that is to have a delegated
prefix that travels with the client wherever it goes. If the routing tables are
spread over many routers in the network (i.e., instead of concentrated within
just one or a few routers) then each router will only need to handle a fraction
of the mobile client user base, and load balancing and fault tolerance are
supported.

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Jan 2016 22:20:58 +0100

Hi,

> of addresses. It is also incompatible withclient mobility,.

Supposedly multicast is one of the strong points of IPv6, and for mobility,
there is mobile IPv6.

If we think that these are all historic errors, and the future is IPv6
over GRE (or LISP), maybe we should make this more clear.

Gert Doering
        -- NetMaster

---

From: David Farmer <[email-masked]>
Date: Wed, 6 Jan 2016 15:50:20 -0600

> it needs to be included at some level of description for completeness.

I agree DHCPv6 PD needs to be included and should not be removed.

However, lets look at the recommendation section.

    ...
    If the network requires explicit requests for address space (e.g.,
    if it requires DHCPv6 to connect), it is RECOMMENDED that the network
    assign a /64 prefix to every host (e.g., via DHCPv6 PD).  Using
    DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses
    (e.g. 32) would accommodate current clients but sets a limit on the
    number of addresses available to hosts when they attach and would
    limit the development of future applications.
    ...

This is could be interpreted as saying that networks SHOULD NOT use 
Stateful DHCPv6 for which there is a clear and unambiguous specification 
for Stateful DHCPv6 host behavior, and they should use DHCPv6 PD for 
which there is NOT a clear and unambiguous specification for DHCPv6 PD 
host behavior.  However, there is a clear and unambiguous specification 
for DHCPv6 PD router behavior, but the importance of this distinction is 
debatable.

What if the recommendation section was rewritten making the DHCP v6 PD 
part permissive and not a normative recommendation.

    8.  Recommendations

    In order to avoid the problems described above, and preserve the
    Internet's ability to support new applications that use more than one
    IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
    multiple IPv6 addresses from each prefix to general-purpose hosts
    when they connect to the network.  To support future use cases, it is
    RECOMMENDED to not impose a hard limit on the size of the address
    pool assigned to a host.

    If the network requires explicit requests for address space (e.g.,
    if it requires DHCPv6 to connect), the network MAY assign a /64
    prefix to every host (e.g., via DHCPv6 PD).  Using DHCPv6 IA_NA or
    IA_TA to request a sufficient number of addresses (e.g. 32) would
    accommodate current clients but sets a limit on the number of
    addresses available to hosts when they attach and would limit the
    development of future applications.  Assigning prefixes longer than
    a /64 will limit the flexibility of the host to further assign
    addresses to any internal functions, virtual machines, or downstream
    clients that require address space - for example, by not allowing
    the use of SLAAC.

In some ways I like this better, it more clearly says /64 per host is 
only an option.  The previous language formed as a conditional 
recommendation, which was confusing in my opinion.

What do others think?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 22:55:18 +0000

Hi Gert,

> From: Gert Doering [mailto:[email-masked]]
> Sent: Wednesday, January 06, 2016 1:21 PM
> To: Templin, Fred L
> Cc: Gert Doering; Lorenzo Colitti; [email-masked] WG
> Supposedly multicast is one of the strong points of IPv6,

Many people are saying that it is too harsh for some wireless access technologies.

> and for mobility, there is mobile IPv6.

Mobile IPv6 is about associating a mobile host's home address with a
care-of address through the insertion of a mobility extension header
(i.e., an encapsulation). It is about a mobile host that goes wandering
away from its home link yet wants to be able to still communicate as
though it was still at home. It is uni-addressing centric, whereas we
want to support mobile devices that need multi-addressing.

> over GRE (or LISP), maybe we should make this more clear.

Did I mention that AERO works over GRE:

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

And, my understanding of LISP is that it requires an online mapping
database facility. This is no more or no less of a critical infrastructure
requirement than for AERO.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Jan 2016 15:31:29 -0800

On Wed, Jan 6, 2016 at 1:50 PM, David Farmer <[email-masked]> wrote:
> This is could be interpreted as saying that networks SHOULD NOT use Stateful
> DHCPv6 for which there is a clear and unambiguous specification for Stateful
> DHCPv6 host behavior, and they should use DHCPv6 PD for which there is NOT a
> clear and unambiguous specification for DHCPv6 PD host behavior.  However,
> there is a clear and unambiguous specification for DHCPv6 PD router
> behavior, but the importance of this distinction is debatable.
>
> What if the recommendation section was rewritten making the DHCP v6 PD part
> permissive and not a normative recommendation.
>
>    8.  Recommendations
>
> In some ways I like this better, it more clearly says /64 per host is only
> an option.  The previous language formed as a conditional recommendation,
> which was confusing in my opinion.
>
> What do others think?

For ILA needs I prefer the recommendation of a /64 assignment. While
we could alternatively define variable length identifiers and locators
I think that would be a significant increase in complexity in both the
protocol and implementation. Is there an argument that recommending
/64 assignment is too big to be a practical recommendation?

Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 23:38:45 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Wednesday, January 06, 2016 3:31 PM
> To: David Farmer
> Cc: [email-masked]

Similarly, AERO would prefer a /64 or shorter (e.g., /60, /56. etc.). I do not
think /64 is too big, and I think cellular operators are already doing this.

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Wed, 6 Jan 2016 17:55:18 -0600

> /64 assignment is too big to be a practical recommendation?

I think you are making my point, the previous language wasn't a straight 
up recommendation of a /64 either.

   assign...

That isn't that much different than;

   If the network requires explicit requests for address space (e.g., if
   it requires DHCPv6 to connect), the network MAY assign...

But, I think the later eliminates the mistaken believe that a /64 or 
DHCPv6 PD is being recommend in all cases, it's NOT in either case.

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 08:38:26 +0100

Hi,

On Wed, Jan 06, 2016 at 03:50:20PM -0600, David Farmer wrote:
>     prefix to every host (e.g., via DHCPv6 PD).  

This is much better.  It remains a somewhat unexplained mystery, though,
why the recommendation is to delegate a /64.  

Why not a /96?  (Which would still be more addresses than the host 
could ever configure locally)

Why not a /60, so internal virtual subnets on the host could be accomodated,
if that is what "we" want?

If "we" recommend burning /64s in large scale, has someone done math what
this does to the /48 which is typically permitted per site if that site
has a large number of users requesting prefixes?

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 08:40:38 +0100

Hi,

> think /64 is too big, and I think cellular operators are already doing this.

The cellular argument doesn't really apply here - in cellular, hosts are
doing SLAAC out of the /64, so it MUST be a /64, no less, no more.

In DHCPv6-PD-to-the-host, the mechanism how the host configures addresses
out of the prefix delegated is fully unspecified.  So the "it has to be a
/64" rule for SLAAC does not apply.

I think a /64 per user in an enterprise network is needlessly wastive.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 16:47:21 +0900

> has a large number of users requesting prefixes?

The math is in the draft. Have you read it?

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 08:58:20 +0100

Hi,

> The math is in the draft. Have you read it?

I assume you're talking about section 9.2?  This is a bit of handwaving
and telling us that "this is not a problem because where it might be a
problem, people will be using SLAAC, and thus, it is not a problem", 
right?

I do see this is as potential problem for an enterprise that only has 
a /48 (because that is what a site will get from RIPE), has multiple
attachment points, does not want 65k routes in their IGP (so, aggregation 
is needed per attachment point) and has couple of 1000 users using this
- and then they will come and complain to the RIR of choice that they
could not get sufficient address space to do this.

Please spell out clearly that using this technology is not RIR-sanctioned
and will not entitle them to a single extra IPv6 subnet.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 17:11:36 +0900

> problem, people will be using SLAAC, and thus, it is not a problem",

The recommendation is to provide a /64 if the network requires explicit
requests for address space. A network that does SLAAC does not require such
requests.

> could not get sufficient address space to do this.

I don't buy that. Running out of a /48 with 4000 users means a 95%
aggregation loss. You don't need to put 64k routes in your IGP to get much
more efficiency than that.

> and will not entitle them to a single extra IPv6 subnet.

RIR policies can be changed, and if this document is published, it should
not be hard to change them. I cannot imagine anyone at a RIR successfully
arguing that assigning a /40 to a medium-sized enterprise is wasteful.

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 09:19:51 +0100

Hi,

> arguing that assigning a /40 to a medium-sized enterprise is wasteful.

I can see myself in that position.  IETF recommendation is "/48 per site",
and this is what the RIRs are following.

I have a hard time argueing for more than 64k subnets at a single site
if that is all virtual in the end.

(And knowing RIR communities, you won't find many more people supporting
a somewhat conservative approach than "just don't care, out with the bits")

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 17:20:31 +0900

> cascading DHCPv6-PD CPEs is being abandoned, because there are better ways.

Funny - Philip is arguing that this is too new and we don't know how to do
it, and you're arguing that it's legacy :-)

> Most routers are also hosts by necessity of talking IP for their

That's a pretty gratuitous objection, given that my point was that PD can
work on both hosts and routers. ("Either a host or a router" is also
technically true - see RFC 2460.)

> "just provide multiple addresses with DHCPv6 IA_NA"?

That point is addressed in the draft in multiple places.

> infrastructure"... memory on the DHCPv6 server is cheap, slots on routers

Actually, as discussed in section 9.3, one prefix per host is much more
scalable than one TCAM entry per address. As discussed in section 7, the
number of addresses are needed if the host does not do NAT66 can be quite
high. Doing that with multiple IA_NA entries is going to hit the last-hop
routers much much harder than one /64 per host. Not to mention all the ND
traffic that others have mentioned.

Gert: a lot of the points you make are already discussed in the draft. If
you want to make statements that these recommendations are misguided, then
please discuss the text where the draft provides rationale for those
recommendations, instead of attacking the recommendations out of context.

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 09:24:42 +0100

Hi,

> it, and you're arguing that it's legacy :-)

Router-to-router it's legacy, router-to-host I find myself in surprising
and unusual agreement with Philip.

> technically true - see RFC 2460.)

Then don't spell it "either...or" - and it isn't.  A router is always
also a host, unless you throw in funny SDN stuff that does not communicate
over IPv6 for the control plane.

[..]
> scalable than one TCAM entry per address. 

That very much depends on the architecture of your network and devices.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 17:28:55 +0900

> over IPv6 for the control plane.

RFC 2460 is not on your side. Take that up with the authors of 2460bis, not
with me :-)

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 09:33:20 +0100

Hi,

> RFC 2460 is not on your side. Take that up with the authors of 2460bis, not

The fact that some RFC states something obviously silly is no compelling
reason to repeat it.

Remember this when you ssh to your router next time, and ask yourself, how
does the router do this, if it's not a host... :-)

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 17:40:48 +0900

> The fact that some RFC states something obviously silly is no compelling

Hey - I'm with you. I think that distinction is completely bogus. But when
we write IETF documents, we have to write things that conform to the
applicable standards, or what we write cannot be published.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 17:47:27 +0900

>    prefix to every host (e.g., via DHCPv6 PD).

And if it doesn't choose to observe the MAY, then what? The network will
end up restricting the amount of address space available to the host,
right? So it will violate the spirit of this draft, but not the letter?

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 09:48:59 +0100

Hi,

> right? So it will violate the spirit of this draft, but not the letter?

It might just decide that up-to-100 IA_NA fits the restrictions of the
local gear better than PD, and does that instead.

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Jan 2016 20:11:06 +1100

> local gear better than PD, and does that instead.

IOW, some networks might want to do that, others might want to delegate a
/64 or greater via DHCPv6-PD.

This argument is getting into minutiae about applicability, possibility and
parameters of specific methods. That sounds to me like the main and
fundamental point is accepted by everyone.

So I'd say ship it.

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 10:12:37 +0100

Hi,

> /64 or greater via DHCPv6-PD.

Right.

> fundamental point is accepted by everyone.

No.  Neither as a BCP, nor with the strong recommendation for DHCPv6-PD,
nor with the emphasis on /64 (if DHCPv6-PD).

What you say above is about choice, but the draft isn't.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Jan 2016 01:39:25 -0800

> On Jan 6, 2016, at 23:38 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

No real need to do so…

1. The /48 is the minimum amount allowed per site without further justification
	by all RIRs currently.

2. Every RIR policy I am familiar with allows for more than a /48 per site if
	need can be shown. ARIN policy also defines site in such a way that each
	customer in the same site could be considered a “tenant in a multitenant
	structure” allowing for each tenant to be considered a separate site.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Jan 2016 01:44:02 -0800

> On Jan 7, 2016, at 00:19 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Unless RIPE tightened things up since the last time I looked, I’m pretty sure
that you can justify more than a /48 for a site _IF_ you have adequate
justification.

I also believe that the RIPE PDWG would do the needful if this is
adopted and there is an issue.

> if that is all virtual in the end.

That’s a different problem and while I’m somewhat inclined to agree with you,
I think for purposes of this particular draft, it’s really a corner case.

> a somewhat conservative approach than "just don't care, out with the bits”)

I’m somewhat familiar with RIR communities and the policies they produce.

I don’t see a genuine problem here.

Owen

---

From: David Farmer <[email-masked]>
Date: Thu, 7 Jan 2016 03:47:01 -0600

> On Jan 7, 2016, at 02:47, Lorenzo Colitti <[email-masked]> wrote:
> 
> And if it doesn't choose to observe the MAY, then what? The network will end up restricting the amount of address space available to the host, right? So it will violate the spirit of this draft, but not the letter?

Are you saying that the use of DHCPv6 IN_NA has to violate the spirit of this draft?  And, to meet the spirit you have to use DHCPv6 PD or SLAAC?

If you are, then you have to be more clear about that, because that's not how I read even your current text.  And if that is the case then you would need a MUST use DHCPv6 PD, not a RECOMMENDED anyway.  And, I'm not sure there is consensus for a MUST, especially since that would essentially deprecate DHCPv6 IN_NA.

Personally, I'm fine with RECOMMENDED, but even that doesn't mean that use of DHCPv6 IN_NA violates the intent of this draft as I read it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 19:57:13 +0900

> local gear better than PD, and does that instead.

Sigh. We've been over all of this already. There are many problems with
that.

The first is that the host can't know in advance that network A provides
100 IA_NA, network B provides 8, and network C provides 1. That leaves the
choice between three bad options:

   1. Start from 256 IA_NA, and if you don't get them, keep asking for
   smaller numbers until you get what you want. That's not in the draft
   because I think almost everyone would agree it's silly.
   2. Hope that the IETF or the industry agrees on a reasonable minimum
   number of addresses (where what is "reasonable" is in section 7) that hosts
   can expect will be widely accepted. That's not in the draft because it
   seems unlikely.
   3. Ask for 1 IA_NA to start with, and whenever you need more, ask again.
   The problems with this strategy are dealt with in section 4. If you haven't
   read that, here's a summary: code complexity, high latency, user
   aggravation when they can't do what they want (e.g., the hotel network they
   connect to won't allow them to start a VM), and consequent pressure on host
   implementers to implement NAT66. (I know that's what I would do.)

For the reasons that #3 above is bad, the draft recommends that addresses
be made available to hosts "when they connect to the network".

And here there's another problem: even if the host somehow knew that it can
get 100 IA_NA, that won't fit in an IPv6 packet, because an IA_NA is 44
bytes long, so the practical maximum is around 30-35 for a 1280-1500 MTU.
(Yes, there is a Fragment header. No, it won't work in practice, and you
know it.)

When you consider extending the network you have another problem. Every
level of hierarchy (tethered device, VM inside a container, etc.) needs to
act as a DHCPv6 relay. (Don't say "bridging" because that doesn't work on
wifi except using MAC NAT or virtually-impossible-to-deploy WDS.)

And so on. From the point of view of a host implementer and of a user,
that's a total nightmare. Search the archives for the total nightmare that
is implementing ePDG on a split application processor/baseband processor
architecture with only one IPv4 address. This is what your phone does when
you do wifi calling, and the result is either an unreliable device, or lack
of other features because so much software engineering time had to be spent
on getting it right.

Implementing NAT66 is way easier than that. I think nobody in this working
group wants things to go that way, but that's what will happen if we go
this route.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 20:10:00 +0900

On Thu, Jan 7, 2016 at 6:47 PM, David Farmer <[email-masked]> wrote:
> Are you saying that the use of DHCPv6 IN_NA has to violate the spirit of
> this draft?  And, to meet the spirit you have to use DHCPv6 PD or SLAAC?
>
> If you are, then you have to be more clear about that, because that's not
> how I read even your current text.  And if that is the case then you
> would need a MUST use DHCPv6 PD, not a RECOMMENDED anyway.  And, I'm not
> sure there is consensus for a MUST, especially since that would essentially
> deprecate DHCPv6 IN_NA.
>
> Personally, I'm fine with RECOMMENDED, but even that doesn't mean that use
> of DHCPv6 IN_NA violates the intent of this draft as I read it.
>

When you say "IA_NA", do you mean "IA_NA only" or "IA_NA in addition to
other address assignment methods"?

A network that uses IA_NA in addition to another method such as SLAAC, PD,
 /64-per-host, AERO, or other non-restrictive address assignment method
obviously fulfills the spirit of this draft. There are good reasons to do
this. For example, you could use IA_NA to assign a predictable/stable IPv6
address for incoming connections, and other methods for other addresses.

As for a network that requires IA_NA in order to connect, I don't know. How
do you build such a network in a way that doesn't end up restricting
address availability? How would you solve the problems I described to Gert
above?

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Jan 2016 22:45:29 +1100

> What you say above is about choice, but the draft isn't.

Who forces you to follow BCPs? Who is saying you MUST use DHCPv6-PD and
MUST give hosts /64s?

The title itself is stating this is a recommendation, and the abstract
describes the methods to do so as options.

It's a BCP because hosts lacking addresses in an IPv6 network should never,
ever be the reason an application partially or completely fails to operate.

It is recommending (but not prescribing) DHCPv6-PD and at least a /64
because it is the only current method of putting a device in charge of a
large amount of address space for its own use and management, instead of
the other methods where hosts have ask for or generate addresses one at a
time.

>         -- NetMaster
DHCP

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 13:41:19 +0100

Hi,

>    implementers to implement NAT66. (I know that's what I would do.)

Actually, the description of all these details makes me wonder why we're
not recommending that the VM in question shouldn't just send its own
DHCPv6 IA_NA request when it wants an address.

Specifying "the network SHOULD add all that complexity" while at the
same time not even specifying how that example VM would then end up 
receiving the address (is the host OS supposed to run SLAAC?  DHCPv6?),
*and* argueing about implementor complexity while not even giving
implementors guidelines how to handle what the network is supposed
to be offering them is a bit unsatisfying.

[..]
> (Yes, there is a Fragment header. No, it won't work in practice, and you

Which makes a strong argument for having the VM itself request the IA_NA
when it wants an address.  This DUID stuff *must* be useful for something.

> wifi except using MAC NAT or virtually-impossible-to-deploy WDS.)

With DHCPv6-PD, you need multiple levels of DHCPv6-PD, *and* DHCPv6-IA_NA
to the VM, because if you get a /64 from the network, you can't do SLAAC
on more than one internal network (and obviously the draft also applies
to internal networks, so the VM could rightfully expect DHCPv6-PD to 
succeed, no?).

The "bridging is impossible" is something that needs to be solved - as
the draft permits SLAAC, the VM example would totally break without
bridiging of some sort, because it won't be able to do SLAAC otherwise.

[..]
> of other features because so much software engineering time had to be spent

Bringing in the poor quality of baseband processor implementations isn't
really a strong argument either way...

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 13:53:02 +0100

>     clients that require address space - for example, by not allowing

Sounds better to me. It is clearer with respect to the /64 point.

It could say "not allowing the use of SLAAC/Ethernet" (remark
"Ethernet"), because that's an Ethernet limination (Ethernet IID must be
64bit long) not a SLAAC limitation (SLAAC allows arbitrary prefix
lenghts). (the Ethernet limitation has been propagated to many other
link specs, like 802.15.4 RFC, but all, like IP/USB).

When it says "assigning prefixes longer than /64" it begs the question
about "assigning prefixes shorter than /64" but is silent in that respect.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 22:01:06 +0900

> DHCPv6 IA_NA request when it wants an address.

That's the same problem as stated earlier - what if the request is denied?
For example, what if the network has decided that the host's MAC address
(remember, on wifi the VM's MAC address cannot appear on the wire except if
you're using WDS or MAC NAT) has already received too many addresses?

There's a reason why vmware implemented NAT66. That's in the draft too,
BTW. Consider reading it, BTW. It might save on typing.

> to be offering them is a bit unsatisfying.

What the host OS does depends on what the network gives it. Host behaviour
is out of scope here, but one simple way to do it is to request a prefix if
SLAAC is not available.

> when it wants an address.  This DUID stuff *must* be useful for something.

Again, please read the draft before making comments that are already
addressed there. Using different DUIDs is discussed in section 6. It is not
clear that the network will expect the client (as identified by the host's
MAC address) to use more than one DUID.

> bridiging of some sort, because it won't be able to do SLAAC otherwise.

Nested PD and NA are not necessary. Inside a host, or in a simple tethered
topology with no loops, you can simply do bridging or ND proxying and rely
on SLAAC. That applies regardless of whether the network provides address
space via SLAAC or DHCPv6 PD. That is one of the reasons why the draft
recommends assigning a /64.

> really a strong argument either way...

The issue is not quality. The issue is that sharing an IP address without
NAT (you can't easily do NAT because the baseband needs to accept
unsolicited incoming packets, do IPsec, etc. etc.) is a nightmare.

If you're arguing that splitting a phone into a baseband processor and
application processor doesn't make sense, you might change your mind if you
compare the battery life impact of voip calling with the battery life
impact of VoLTE calling.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 14:05:01 +0100

> want to support mobile devices that need multi-addressing.

Yes, it is a total network-layer centric solution smoothly hiding all 
address change events from applications.

Mobile IPv6 is also about Mobile Routers (NEMO - Network Mobility, RFC3963).

Uni-address centric?  No, because in NEMO there is also use of DHCPv6-PD 
between the Mobile Router and the Home Agent.

The only aspects that could be considered as disadvantages to Mobile 
Routers implementing Mobile IPv6/NEMO are:
- this totality coverage of address change disruption (some apps dont
   really need, some deal with it themselves).
- lack of coverage of other mobility events (e.g. lack of deal with
   intermittent reconnection to precisely same network).
- lack of securely established optimal routes (the famous RO).
- lack of multi-tier edge IP address architectures (a Mobile
   Router is in theory one CPU with several IP interfaces, whereas in
   practice Mobile Routers are themselves separated in multiple CPUs
   tightly bound by some specific interfaces some being IP-enabled
   others not).

> requirement than for AERO.

I agree with this point. Many mobility solutions actually require
infrastructure support - LISP, MIP, AERO. Because one of the fundamental
principles of the Internet architecture is that one address is valid at
one single particular point in the topology (it's not like e.g. the
POBox address architecture which says that I can keep my POBox number
wherever in the postal address system I am situated).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 14:09:28 +0100

> /64 assignment is too big to be a practical recommendation?

/64 assigned by DHCP-PD to a computer is not necessarily too big, and
can be a practical recommendation.

The only inconvenient is that computer will not be able to assign
_sub-prefixes_ out of that /64 (e.g. /65s) by using SLAAC/Ethernet to
other virtualboxes in that computer, or to other real computers
networked to it. Ethernet and similar links are very popular and they
all require 64bit Interface IDs. The use of SLAAC is also very popular
in IPv6 (much more than DHCPv6). There is no relationship between the
64bit limitation of Ethernet and SLAAC - SLAAC can accommodate /65
prefix lengths.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 14:11:43 +0100

Hi,

> That's the same problem as stated earlier - what if the request is denied?

"then you have no IPv6 for that VM"

> BTW. Consider reading it, BTW. It might save on typing.

No need to go through every individual text block if the conclusion alone
is worth objecting to.

> is out of scope here, but one simple way to do it is to request a prefix if

You're the one argueing that this all needs to be done to avoid implementation
complexity in the host OS - by introducing *more* implementation complexity
(are you assuming that all networks will support this?  What if someone
supports SLAAC and IA_NA, but not PD?  Yes, another implementation variant)

[..]
> MAC address) to use more than one DUID.

Wouldn't it be MUCH easier to recommend that networks support multiple
DUIDs per client / per MAC?

> recommends assigning a /64.

The VM wouldn't know it's "inside the host".  What if it wants multiple
addresses?  Like, for a nested VM?

Why is bridging / ND proxying inside the host suddenly OK then?

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 14:12:02 +0100

> think /64 is too big, and I think cellular operators are already doing this.

YEs, cellular operators use DHCPv6-PD between routers in the network
infrastructure to assign some prefix lengths; and use RA to announce
/64s to the user equipment; and use DHCPv6-address to assign 128bit
address(es) to the UE.

Yet cellular operators dont provide DHCPv6-PD to the UE. When they do,
there will be no problem to move that /64 which was initially in the RA
to a DHCPv6 Advertize message.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 22:35:06 +0900

> "then you have no IPv6 for that VM"

Right, and on an IPv6-only network, "you have no network for that VM".

Why do you think the NAT66 mode exists in vmware? Users don't like to be
told what they can't do, and product managers don't like engineers to tell
them "we can't implement user-visible feature X on this network because it
will break <incomprehensible bit about end-to-end that no non-engineer
understands>"

Is that what you want to have happen everywhere?

> supports SLAAC and IA_NA, but not PD?  Yes, another implementation variant)

If a network supports SLAAC but not PD, the host can just use SLAAC.
Internally I think it can use pretty much the same code for both. In the PD
case the host needs to send an RA, but that's really not hard.

> DUIDs per client / per MAC?

Not sure. Not sure it's worth pursuing since I doubt it will be possible to
come to an agreement on how many "multiple" is. Bear in mind that the
number can't just be a small number like 4 if the numbers in section 7 are
to be believed. Do you think it's realistic to come to consensus on, say,
"networks SHOULD support 32 DUIDs per MAC address, and hosts MAY ask for 32
DUIDs at connection time"? That seems much less scalable than one prefix,
or SLAAC.

> Why is bridging / ND proxying inside the host suddenly OK then?

It's much easier to ensure there are no loops, and even if a loop is
somehow created it doesn't take down affect other people except the user of
the host. Because the host uses software, it scales better than having to
put all the MAC addresses inside the TCAM of the first-hop router.

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 14:40:13 +0100

Hi,

> put all the MAC addresses inside the TCAM of the first-hop router.

Using that scaling argument, you should recommend that people do not 
use SLAAC either - because wrt scaling the router's ND tables, there is
no difference between SLAAC or IA_NA.

Scaling ND tables by burdening FIB tables (SLAAC/IA_NA vs. PD) is a local 
tradeoff that will look very different depending on the equipment you use.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 23:00:21 +0900

> no difference between SLAAC or IA_NA.

Yes, from the perspective of the first-hop router, PD does scale better.
That's the subject of section 9.3. SLAAC and IA_NA are mostly identical in
this respect.

(I was trying to answer your "why is it OK to bridge inside the host but
not between host and network" question.)

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 16:01:00 +0000

Hi Alex,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, January 07, 2016 5:09 AM
> To: [email-masked]

Agreed. But shorter prefixes (e.g., /60, /56, etc.) should also be possible.

> 64bit limitation of Ethernet and SLAAC - SLAAC can accommodate /65

Networking with a shorter prefix is possible with full support of SLAAC.
There is also RFC7278.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 16:13:54 +0000

Hi,

> Sent: Wednesday, January 06, 2016 11:58 PM
> To: Lorenzo Colitti
> Cc: [email-masked]

I want to address the assertion that assigning /64 prefixes from a /48
would cause up to 65k routes being propagated in the IGP. Using the
WLAN-GW model documented in "unique-ipv6-prefix-per-host", the
WLAN-GW only needs to advertise the /48 in the IGP and not the
individual /64s. Instead, the /64s would be maintained in the FIB
of the WLAN-GW and do not need to be synchronized among all
routers that participate in the IGP.

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 17:19:50 +0100

Hi,

> routers that participate in the IGP.

That assumes that the WLAN-GW owns the /48.

It doesn't.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 16:27:28 +0000

Hi Gert,

> Sent: Thursday, January 07, 2016 8:20 AM
> To: Templin, Fred L
> Cc: Gert Doering; Lorenzo Colitti; [email-masked]

The /48 is owned by the "site", and advertised into the global IPv6 BGP
routing system by site border BGP routers. Within the site, the /48 can
be provisioned to the WLAN-GW through the advertisement of a single
/48 that gets populated through the IGP and eventually all paths lead
to the WLAN-GW. From there, the /64s show up only in the FIB of the
WLAN-GW. That's really all there is to it.

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 17:32:43 +0100

Hi,

> WLAN-GW. That's really all there is to it.

I do understand aggregation, thanks :-) - but people will and do choose
different aggregation points in their networks than "the single WLAN-GW".

Like, they might have two.  Or three.

Or a somewhat structured network.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 16:45:13 +0000

Hi Gert,

> Sent: Thursday, January 07, 2016 8:33 AM
> To: Templin, Fred L

Or hundreds or thousands.

> Or a somewhat structured network.

AERO explains how this all works. Let's say we had hundreds or thousands
of  WLAN-GWs and we wanted to network them. Have the WLAN-GWs
participate in a private BGP instance that *does* carry all /64 prefixes.
When a UE associates with a WLAN-GW, the WLAN-GW injects the UE's
/64 into the BGP routing instance. When the UE disassociates with the
WLAN-GW, the WLAN-GW withdraws the /64. If the UE pops up at a
different WLAN-GW, that new WLAN-GW then injects the route into
the BGP routing system.

You may worry that this would require all WLAN-GWs to peer with all
other WLAN-GWs, but that is not necessary if we introduce a new
architectural construct - call lit a WLAN-RELAY. There might be a few
10s of those, and each WLAN-RELAY peers with all WLAN-GWs. So,
the WLAN-RELAYS discover all /64 prefix assignments and which
WLAN-GW the prefix is currently assigned to. The WLAN-GWs then
only need to know about their current working set of /64s, and
set default routes to one or more WLAN-RELAYs. The WLAN-RELAYs
then advertise the /48 into the IGP or (if the WLAN-RELAYs are
also site border routers) into the global Internet BGP routing system.

Yes, this means that the WLAN-RELAYs would need to carry up
to 65K /64s in the private BGP routing instance. But, we know from
experience that public Internet BGP routers can carry hundreds
of thousands of routes - maybe even as many as a million. It
works, and it scales - this is also explained in AERO.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 13:23:23 +0100

Le 06/01/2016 16:27, Lorenzo Colitti a écrit :
>
> On Wed, Jan 6, 2016 at 10:36 PM, Alexandre Petrescu
>     If one reads the Note attached to the router definition in 2460,
>     then one understands that a host that uses a prefix obtained with
>     DHCP-PD does need to forward, and maybe its apps to explicitate the
>     source address.
>
>

In that case (ULA prefix for every process on the system), the system 
would need to forward between processes in that sytem.  That makes it a 
router.
> arriving on some interfaces but not on others. That is not the case
> here. My laptop was not forwarding packets from any interface to any
> interface and it was purely a host.
>
>     The usual way is to be able to say just "ping6 google.com
>     <http://google.com>" without arguments.
>
>
> If I had not specified -I, someone would have said "there is no proof
> that this works, your laptop could have been using another address, one
> that was not obtained via DHCPv6 PD". :-)

One can give a proof it works by copy/paste the ping output - it tells 
the src and dst addresses.

One another hand, does that ping work w/o saying -I?  I guess not.

Alex

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Jan 2016 10:46:46 +1100

>> <[email-masked] <mailto:[email-masked]>>
<snip>
> In that case (ULA prefix for every process on the system), the system would
> need to forward between processes in that sytem.  That makes it a router.
>>

So if the definition of a router is forwarding between interfaces,
then any host that implements the Weak Host Model (RFC1122, "Weak ES
Model"), then it is not a host, it is a router, despite the name.

I think the distinction between a router and a host is different. It
isn't at the level of whether or not a packet received on one
interface is conceptually sent to another interface inside the device.
I think it is a simpler question - what does the device do with a
packet who's destination address doesn't match one of its own? Drop
it, making it a host, or see what the route table says to do with it,
making it a router.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 8 Jan 2016 23:57:38 +0000

Speaking as chair, and hoping to guide this discussion.

I am seeing a lot of discussion here that I think is pretty far afield of what the working group said it wanted a working group BCP draft to describe. That purpose was, in essence, to ask network operators, mobile, enterprise, and ISP, to permit hosts in their networks to have multiple addresses from the same prefix in use on an interface, consistent with RFC 4291 section 2.1.

Operationally, we have a *lot* of experience with the allocation of multiple temporary and permanent addresses from the prefix used in a LAN subnet to a physical or virtual host, using SLAAC; where this draft started out, I understood it to ask that the same thing be possible and supported using DHCP or other address allocation technologies, and for operators provisioning networks to act accordingly. That is actually an important point, one I had to clarify with a Cisco colleague from a product perspective just this week.

If virtual machines or containers are in view, I'm not sure I see a lot of difference between a physical router in a data center infrastructure and a virtual router located in the physical host the virtual machines are in, and therefore between the use of DHCP-PD in a router that is physical vs one that is virtual. I see a lot of stuff floating around reinventing the wheel for virtual systems; I tend to think we can simplify a lot of that by conceptually erasing the distinction - a router is a router, and a host is a host, whether physical or virtual, and (whatever the implementation issues might be) the specifications we write for them should be the same. From that perspective, if we have experience with DHCP-PD on routers, the expansion to virtual routers in the physical host is a very small step, and I don't see what the hubbub is about.

What we don't have a lot of experience with is assigning a prefix to a host and using addresses from it to identify (clusters of) application instances without the container/virtual machine context.

We don't need to tell the host what to do with the prefix assigned to it, or (IMHO) even what size that prefix should be... This is about network provisioning.

So it seems to me that the experience question devolves to wanting to let the technology that erases the virtual machine/container and simply applies addresses to applications percolate, but make a comment on that which we in fact have experience on - the use of DHCP-PD by routers (physical or virtual), and the allocation of multiple addresses in the same prefix to a host.

This entire discussion seems to me to be trending far afield of the initial purpose of the document, to the point that we have substantive calls to reduce its proposed status from BCP to Informational and refer to technologies that are at experimental status and not widely deployed by operators in this community. I think the working group's consensus in adopting the draft is better served if we can identify those factors that are in fact describable as "Best Current Practice", and make the draft target those.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jan 2016 15:18:01 +1300

Fred,

IMHO you are 100% correct, and most of the recent discussion is way off the point.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 9 Jan 2016 14:15:21 +0900

> would need to forward between processes in that sytem.  That makes it a

No: even in the RFC 2460 definition of router, a node is a router if it
forwards packets "not addressed to itself". All these packets are addressed
to different applications on the node itself.

> One can give a proof it works by copy/paste the ping output - it tells the
> src and dst addresses.
>

It does work, but it would have preferred one of the addresses assigned to
eth0 instead of the address I manually assigned to lo. If I didn't have an
address on eth0 via SLAAC, it would have worked and chosen the lo address.

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jan 2016 22:18:40 -0800

> So if the definition of a router is forwarding between interfaces,

Forwarding between interfaces involves receiving a packet on one
interface and emitting it on another.

> Model"), then it is not a host, it is a router, despite the name.

The weak host model involves receiving a packet on one interface and
interpreting that as receiving the packet on another interface. There's
no emitting going on. The weak model simply interprets addresses as
belonging to the host rather than the interface.

FWIW, most Internet stacks implement a strong link layer and a weak
network layer, but there are notable exceptions to both.

(Fred: though I agree this is afield from the original thread, I find it
hard to understand how a coherent discussion about host addressing can
occur given the confusion about what a host is on this list)

Joe

---

From: Erik Kline <[email-masked]>
Date: Tue, 12 Jan 2016 23:53:04 +0900

> occur given the confusion about what a host is on this list)

Somewhat similarly, I find it hard to understand where things stand
with this document at this moment.

Let me propose two things:

    [1] Is it important that we, as IPv6 folk, can make a Best
Practices statement about ensuring that the bounty of IPv6 addresses
be shared far and wide, avoiding incentives for NAT66.  As such, I
favour some document with BCP status.

    [2] Perhaps we can resolve people's concerns with the "C" in BCP
by simply adding a few statements to the effect of:

        "[WRT to the set of multiple address solutions] Outside of
SLAAC there is currently little experience with either DHCPv6 multiple
IA_NA or IA_PD in host OSes.  Nevertheless, these are the only
currently standardized solutions theoretically capable of fulfilling
the requirements [ref = Section 7]."

...or something worded more intelligently by someone not minutes from sleep.

Would this work?

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jan 2016 16:38:44 +0100

>favour some document with BCP status.

I fully agree that it would be absurd if address shortage would cause people
if deploy NAT66.

However, why do we need a BCP now?

By and large we don't have a problem in networks that use SLAAC. And I'm not
aware of any developments that suggest that it will be a problem in the
near future. Of course SLAAC is sub-optimal if the device has a complex
desk area network behind it (or has a complex VM/container configuration)

We may have a problem in networks that use DHCPv6 IA_NA. But that is
exactly the configuration where we cannot give any advice based on experience.

So why not add some DHCPv6 IA_NA (that requests multiple address) or IA_PD
support to a popular host platform, encourage a big DHCPv6 site to support
it and then publish a BCP based on that experience.

Maybe have DHCP-only networks at IETF (or RIR) meetings to see if devices 
properly support DHCPv6 or not.

---

From: David Farmer <[email-masked]>
Date: Tue, 12 Jan 2016 09:47:59 -0600

> ...or something worded more intelligently by someone not minutes from sleep.

I agree with both points!

And, not so clearly and concisely I think it says that already.  So yes, 
I support that language or something very much like it.

Additionally, I think DHCPv6 with multiple IA_NA is a viable solution to 
the issue and if the authors do not, they need to more clearly explain 
why not.  Personally, I'm OK with recommending DHCPv6 IA_PD over 
multiple IA_NA, I think there are definite advantages to DHCPv6 IA_PD. 
However, without a stronger explanation why DHCPv6 with multiple IA_NA 
is not a viable solution, it should not be implied that multiple IA_NA 
is not a viable solution.  I think it needs to be more clearly stated 
that DHCPv6 with multiple IA_NA is a viable solution, even if it is not 
the recommended solution.  Further, I think it should be clearly stated 
that DHCPv6 with a single IA_NA does not meet the requirements of the 
draft.

Thanks.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 Jan 2016 16:00:09 +0000

> On Jan 12, 2016, at 6:53 AM, Erik Kline <[email-masked]> wrote:
> 

On that I strongly agree.

> the requirements [ref = Section 7]."

That would encapsulate what I understand to have been agreed to.

---

From: [email-masked]
Date: Tue, 12 Jan 2016 17:22:09 +0100 (CET)

> multiple IA_NA, I think there are definite advantages to DHCPv6 IA_PD. 

Fully agreed.

> that DHCPv6 with a single IA_NA does not meet the requirements of the 

We can certainly recommend DHCPv6 IA_PD as a better solution - but
DHCPv6 with multiple IA_NA *will* happen. I see nothing wrong with it.

Steinar Haug, AS2116

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 12 Jan 2016 16:46:25 +0000

+2 (1 per bullet)

On 12/01/16 15:53, "v6ops on behalf of Erik Kline" <[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2016 06:33:13 +1100

> However, why do we need a BCP now?

I think the "now" is not so much 2016, I think it is more about being
proactive, and trying to make a strong statement that IPv4's address
conservatism mentality is not only unnecessary but also will be limiting in
an IPv6 context.

I'm not sure what motivated the authors to start writing this, however it
feels like the right time to me for a variety of reasons - VMs and
containers, IoT and RIRs running out of IPv4 addresses are all going to be
bringing the need for more addresses to the forefronts of peoples' minds. I
think the need to deploy IPv6 will become more obvious to those people if
it isn't already.

To some extent this is more of a BCP on what not to do (artificially and
unnecessarily limit addresses) rather than what to do, as, as you observe,
there probably isn't much address limiting going on right now (although I
wouldn't be all that surprised if some mobile carriers try it on given
their tethering history,).

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jan 2016 13:39:58 +0900

> And, not so clearly and concisely I think it says that already.  So yes, I
> support that language or something very much like it.
>

Ok, then. How about putting this at the end of section 6:

   It should be noted that while providing multiple addresses via SLAAC is
   well understood, there is currently limited experience in host operating
   systems with DHCPv6 PD, and little or no experience providing multiple
   addresses via multiple IA_NA options or multiple DUIDs per host. However,
   these are the only currently standardized options that can provide
multiple
   addresses on networks that do not use SLAAC.

And leaving the current recommendations section as is, like so?

   [...] If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD).  Using DHCPv6 IA_NA or IA_TA to request a sufficient
   number of addresses (e.g. 32) would accommodate current clients but
   sets a limit on the number of addresses available to hosts when they
   attach and would limit the development of future applications.
   Assigning prefixes longer than a /64 will limit [...]

> the issue and if the authors do not, they need to more clearly explain why
> not.  Personally, I'm OK with recommending DHCPv6 IA_PD over multiple
> IA_NA, I think there are definite advantages to DHCPv6 IA_PD. However,
> without a stronger explanation why DHCPv6 with multiple IA_NA is not a
> viable solution, it should not be implied that multiple IA_NA is not a
> viable solution.  I think it needs to be more clearly stated that DHCPv6
> with multiple IA_NA is a viable solution, even if it is not the recommended
> solution.  Further, I think it should be clearly stated that DHCPv6 with a
> single IA_NA does not meet the requirements of the draft.
>

It seems to me that the text already addresses the points you raise. It
does not say or imply that multiple IA_NA is not viable, it just recommends
IA_PD over IA_NA for the reason that it is more future-proof and more
extensible. Also, I think it is already pretty clear that a single IA_NA
does not meet the requirements, because the text says "it is RECOMMENDED
that IPv6 network deployments provide multiple IPv6 addresses [...]", and
"multiple" obviously cannot mean one.

As for multiple IA_NA, yes - it is much more limited. Without using
fragmentation (and it seems like a pretty bad idea to rely on fragmentation
for DHCPv6 packets), the practical limit to the number of addresses that
can be assigned is about 30, less if lengthy options such as long domain
search lists are used. So, what do you do downstream? Because the draft
recommends that addresses be provided to hosts "when they connect to the
network", what is a host supposed to do if it gets 20 IA_NA and the user
starts a VM? How many should it provide to that VM? 10? What if the user
starts two more VMs, does the third one start IPv4-only? At what point is
the host - which to its VMs acts as the "network" be forced to violate the
spirit of this draft because it simply didn't get enough space from the
upstream to provide enough addresses to the VMs?

This is a very important consideration, but it does not really belong here
because host behaviour is out of scope for this draft. I think that the
current text recommending DHCPv6 PD is a reasonable compromise. As the
draft says, /64 has none of these problems because it provides 17 orders of
magnitude more space.

Cheers,
Lorenzo

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Jan 2016 08:22:48 +0100

Hi,

On Wed, Jan 13, 2016 at 01:39:58PM +0900, Lorenzo Colitti wrote:
> Because the draft

I actually think that this is a tremendously silly recommendation, for the
reasons that you describe.  Leaving out the DHCP discussion for the moment,
even with SLAAC "grabbing all the addresses that this host might 
*potentially* need at network connection time" is madness - how many to
grab?  10, 100, 1000, with associated DAD?

> draft says, /64 has none of these problems because it provides 17 orders of

Except that it totally ignores the recursive behaviour of the VM example -
what if there is a VM inside the VM?

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Jan 2016 08:29:51 +0100

Hi,

> ...or something worded more intelligently by someone not minutes from sleep.

This is something I can happily live with and agree to.

I will continue to object to anything that claims it's a BCP to RECOMMEND
deployment of DHCPv6-PD to hosts, without at least explaining what the
host is supposed to do with it.

If you want a DHCPv6-PD-to-hosts-document, please write one, that explains
how this is supposed to work on both sides of the equation - with all the
examples that clearly explains to a network administrator why they want to
add the additional complexity to their network (assign a sufficiently-large
IPv6 subnet pool, monitor it, figure out how to solve first-hop security
with their vendor's gear, etc.), and how to make positive use of it, not
only pay the price.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jan 2016 16:42:00 +0900

> grab?  10, 100, 1000, with associated DAD?

The recommendation is that the network provide them, not that the host do
something with them. SLAAC provides a /64 prefix with A=1, which allows the
host to form an unspecified number of addresses at any time in the future.

The question of a host forming unreasonable number of addresses is
discussed in section 9.3.

> what if there is a VM inside the VM?

Possible ways the host can choose to make that space available to
downstream hosts are provided in the DHCPv6 PD bullet in section 6. As
explained in section 1, exact behaviour is out of scope.

---

From: Erik Kline <[email-masked]>
Date: Wed, 13 Jan 2016 16:45:22 +0900

> with their vendor's gear, etc.), and how to make positive use of it, not

Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD.  At
best it says at one point "e.g., via DHCPv6 PD" and certainly never
elevates PD above any other solution.

At the risk of sounding like a Scarfolk Council poster
(http://scarfolk.blogspot.jp/), "for more information please reread".

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Jan 2016 08:56:56 +0100

Hi,

> elevates PD above any other solution.

"it is RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD)."

since there is no other mechanism that could do this, argueing that this
would *not* be recommending DHCPv6-PD is a bit weird.

But if this is not about recommending DHCPv6-PD, and it's just an example,
I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away,
and also remove all references to "DHCPv6 PD" in 9.3 - keeping the 
discussion about the routing model as alternative to burdening the ND
layer is fine, but if you don't want to recommend DHCPv6 PD, then don't 
mention it as a particular technology.

Gert Doering
        -- NetMaster

---

From: Erik Kline <[email-masked]>
Date: Wed, 13 Jan 2016 17:28:54 +0900

> mention it as a particular technology.

I think we need to keep text about the universe of currently available
solutions.  All of those listed are workable.

It should be easy for
us as a group to recommend that network operators choose (at least)
one solution out of the currently available universe of solutions.

That's the meat of what's being said here, with a side salad of
motivation and considerations[*].

I continue to not see a controversy here.
-ek

[*] apologies to vegetarians

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2016 20:01:28 +1100

On 13 Jan 2016 18:30, "Gert Doering" <[email-masked]> wrote:
> If you want a DHCPv6-PD-to-hosts-document, please write one,

"Delegating a Prefix to a Host for Multi-addressing Purposes"
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

that explains

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jan 2016 10:02:25 +0100

Le 13/01/2016 08:56, Gert Doering a écrit :
> since there is no other mechanism that could do this,

Right, there is no other Stds Track RFC that could do this (other than 
DHCP-PD), but there is Prefix Delegation extension to ND protocol - an 
individual Internet Draft:
https://tools.ietf.org/html/draft-kaiser-nd-pd-02

Alex

> argueing that this

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2016 20:36:18 +1100

> https://tools.ietf.org/html/draft-kaiser-nd-pd-02

There is no need for a standards track RFC, the protocol is already
defined, and there is nothing in the protocol that demands that the
delegated prefix MUST be used as a routed prefix on a router.

RFC7084 says that the receiving CPE is to use one of the delegated /64s for
its own host traffic if there is no global prefix on the WAN interface in
WAA-7, so there is already an RFC describing the use of a DHCPV6-PD
delegated prefix for host traffic to/from a device.

(This apparent obsession with classifying protocols as "can be run on a
router" or "can only run on a host" is getting tiring. How do people
explain BGP looking glasses if BGP MUST be run on a device that forwards
packets? How do people explain Cisco routers that accept the "no ip
forwarding" command, stopping them forwarding packets, and can act as
terminal servers, originating telnet sessions a host "only" protocol.

They're all just computers, the only thing special about high end "routers"
is that they're optimised to perform packet forwarding using hardware and
do that by default.)

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jan 2016 18:58:27 +0900

> host is supposed to do with it.

Not sure what your point is. Are you saying that a host is so different
from a router that it can't reasonably implement RFC 3633?

> with their vendor's gear, etc.), and how to make positive use of it, not

Gert, please don't mischaracterize things. This is not a DHCPv6-PD-to-hosts
document. This is a document that recommends that networks assign multiple
addresses to hosts.

DHCPv6 PD is only one of the options. On a network that has decided to use
DHCPv6 as the only address provisioning protocol, there are two
alternatives: multiple IA_NA and PD. The document cites reasons why PD is
more extensible and more future-proof than IA_NA and as such recommends
that. Please do note that in terms of number of devices, such networks are
a small minority - they are dwarfed by residential and mobile networks,
which use other provisioning protocols either instead of or in addition to
DHCPv6, and which assign multiple addresses to hosts as a matter of course.

In any case, nobody says that anyone must follow that recommendation. As
with all IETF recommendations, operators are free to ignore it as long as
they weigh the implications of doing so. In your network, you're still free
to disable SLAAC, use DHCPv6 only, and assign one address per device, if
that's what you want. Is it?

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jan 2016 13:30:21 +0100

> desk area network behind it (or has a complex VM/container configuration)

Not only sub-optimal - it's worse - it's hardly working at all.

> it and then publish a BCP based on that experience.

I agree, it's a good step.  Some 'host' platform includes 'M2M' 
platforms of some popular manufacturer of chips for cellular UEs.

> properly support DHCPv6 or not.

Good point.  At the last IETF there was initiative to go towards DHCP-PD 
test on the IETF WiFi network - not sure where it stands now.

Additionally, some cellular network operators in v6ops may be able to 
offer DHCP-PD to UEs.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jan 2016 13:30:28 +0100 (CET)

On Wed, 13 Jan 2016, Lorenzo Colitti wrote:

> The recommendation is that the network provide them, not that the host 
> do something with them. SLAAC provides a /64 prefix with A=1, which 
> allows the host to form an unspecified number of addresses at any time 
> in the future.

I have come to form the opinion that there should be some kind of BCP on 
how many IPv6 addresses the host can expect to form (that works) using 
A=1. There should have been some kind of option for the network to 
advertise the per-MAC maximum supported by the network, because I'd 
venture to say that the host using 1B addresses would never have worked, 
neither on new or old hardware.

Looking at some deployments in the Wifi space, it looks like at least one 
vendor has chosen a default to support a max of 8 addresses per MAC, which 
is a value that I can understand why they came to considering a lot of 
different parameters (one can always discuss if it should be 8 non-LL and 
1 LL, or if it should be 7 non-LL and 1 LL address, but... oh well.

So while I really would like to see PD supported by hosts, I also think 
that giving hints to the host how much working A=1 based addresses it can 
form would be good as well.

Anyone else think this would be a good idea? In that case I guess we'd 
need to communicate this to 6man.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jan 2016 13:34:10 +0100

Le 12/01/2016 20:33, Mark Smith a écrit :
>
> On 13 Jan 2016 02:39, "Philip Homburg" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>>> Practices statement about ensuring that the bounty of IPv6
>>> addresses be shared far and wide, avoiding incentives for NAT66.
>>> As such, I favour some document with BCP status.
>>
>> I fully agree that it would be absurd if address shortage would
>> cause
> people
>> if deploy NAT66.
>>
>  conservatism mentality is not only unnecessary but also will be
> limiting in an IPv6 context.
>
> I'm not sure what motivated the authors to start writing this,
> however it feels like the right time to me for a variety of reasons -
> VMs and containers, IoT and RIRs running out of IPv4 addresses

... and cellular networks to which vehicular networks connect.

> are all going to be bringing the need for more addresses to the
> forefronts of peoples' minds. I think the need to deploy IPv6 will
> become more obvious to those people if it isn't already.

Using IPv4 in vehicular networks is straighforward.  Using IPv6 needs 
DHCPv6-PD, or otherwise NAT66 which is a real risk.

Alex

> To some extent this is more of a BCP on what not to do (artificially
> and unnecessarily limit addresses) rather than what to do, as, as you
>  observe, there probably isn't much address limiting going on right
> now (although I wouldn't be all that surprised if some mobile
> carriers try it on given their tethering history,).
>
>> By and large we don't have a problem in networks that use SLAAC.
>> And
> I'm not
>> aware of any developments that suggest that it will be a problem in
>> the near future. Of course SLAAC is sub-optimal if the device has a
>> complex desk area network behind it (or has a complex VM/container
>> configuration)
>>
>> We may have a problem in networks that use DHCPv6 IA_NA. But that
>> is exactly the configuration where we cannot give any advice based
>> on
> experience.
>>
>> So why not add some DHCPv6 IA_NA (that requests multiple address)
>> or
> IA_PD
>> support to a popular host platform, encourage a big DHCPv6 site to
>>
> support
>> Maybe have DHCP-only networks at IETF (or RIR) meetings to see if
>> devices properly support DHCPv6 or not.
>>
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] <mailto:[email-masked]>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Jan 2016 17:31:07 +0000

Hi Gert,

Did this answer your question (from last week)? If so, can we agree that routing
scaling should not be an issue for delegating lots of prefixes to lots of hosts?

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Thursday, January 07, 2016 8:45 AM
> To: Gert Doering
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Jan 2016 17:52:58 +0000

Hi Alex,

> Sent: Wednesday, January 13, 2016 1:02 AM
> To: [email-masked]

What would be the operational advantage for an ND-based prefix delegation
extension? AFAICT, it would require either new messages or extensions to
existing messages, and would still need to manage some sort of lease
database and the routing system. The draft indicated that it could provide
a "faster and less resource consuming way", but I don't see how it could
get around managing the same sort of state as for DHCPv6 nor how the
message exchanges could be made more efficient?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jan 2016 08:04:01 +1300

>> would *not* be recommending DHCPv6-PD is a bit weird.

If you want to be clear about the normative intent, this sentence should be:

"It is RECOMMENDED that the network assign a /64 prefix to every host.
This MAY be done via DHCPv6 PD."

I happen to be a co-author of draft-ietf-anima-prefix-management,
which is as far from current practice as you can get, but does prove
the point that there will be various ways to meet the recommendation.
Mentioning one of them as an actual or implied MAY doesn't dilute the
recommendation.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Jan 2016 06:54:06 +1100

On 13 January 2016 at 23:30, Mikael Abrahamsson <[email-masked]> wrote:
> I have come to form the opinion that there should be some kind of BCP on how
> many IPv6 addresses the host can expect to form (that works) using A=1.
> There should have been some kind of option for the network to advertise the
> per-MAC maximum supported by the network, because I'd venture to say that
> the host using 1B addresses would never have worked, neither on new or old
> hardware.
>
> different parameters (one can always discuss if it should be 8 non-LL and 1
> LL, or if it should be 7 non-LL and 1 LL address, but... oh well.
>
> So while I really would like to see PD supported by hosts, I also think that
> giving hints to the host how much working A=1 based addresses it can form
> would be good as well.
>
> Anyone else think this would be a good idea? In that case I guess we'd need
> to communicate this to 6man.
>

A couple of brief points (because I need to have breakfast!).

What is or are the motivations for limiting numbers of addresses? I
think enumerating them would be useful.

"Security" is probably one of them, however, as with DHCP DUIDs, and
likely easier, the people who you want to secure excess address
consumption against are the same sort of people who are very likely to
know how to create and use multiple MAC addresses to overcome those
limits (the first thing that comes to my mind on how to do this is the
'macvlan' interfaces under Linux).

Regarding the max of 8 addresses example you mentioned, it would be
interesting to know how that interacts with Windows, because (from
memory), I think they generate in the order of 16 addresses related to
a form of privacy addressing, although I can't remember if they're all
preferred/valid.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Wed, 13 Jan 2016 19:20:42 -0600

On 1/12/16 22:39 , Lorenzo Colitti wrote:
> On Wed, Jan 13, 2016 at 12:47 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     And, not so clearly and concisely I think it says that already.  So
>     yes, I support that language or something very much like it.
>
>

Erik characterized things as "little experience" with both PD and 
multiple IA_NA.  Where as you characterize things as "little experience" 
with PD and "little or no experience" with multiple IA_NA.  I'm probably 
being overly sensitive here, but that is the kind of thing I was 
referring too, there seems to be an implication there.

My suggestion, characterize things as "little experience" for both PD 
and multiple IA_NA to avoid any bias or implication.

>     Additionally, I think DHCPv6 with multiple IA_NA is a viable
>     solution to the issue and if the authors do not, they need to more
>     clearly explain why not.  Personally, I'm OK with recommending
>     DHCPv6 IA_PD over multiple IA_NA, I think there are definite
>     advantages to DHCPv6 IA_PD. However, without a stronger explanation
>     why DHCPv6 with multiple IA_NA is not a viable solution, it should
>     not be implied that multiple IA_NA is not a viable solution.  I
>     think it needs to be more clearly stated that DHCPv6 with multiple
>     IA_NA is a viable solution, even if it is not the recommended
>     solution.  Further, I think it should be clearly stated that DHCPv6
>     with a single IA_NA does not meet the requirements of the draft.
>
>
> does not say or imply that multiple IA_NA is not viable, it just
> recommends IA_PD over IA_NA for the reason that it is more future-proof
> and more extensible. Also, I think it is already pretty clear that a
> single IA_NA does not meet the requirements, because the text says "it
> is RECOMMENDED that IPv6 network deployments provide multiple IPv6
> addresses [...]", and "multiple" obviously cannot mean one.

Months ago, I initially read this as saying "don't use multiple IA_NA", 
and that concerned me.  I convinced myself that it only intended to 
recommend IA_PD over multiple IA_NA as you say.  But then your comments 
from the following thread, flipped me back around to thinking it really 
intends to say "don't use multiple IA_NA", and without more rationale 
I'm not OK with that.

https://mailarchive.ietf.org/arch/msg/v6ops/8gsFMoSzZsYGLwBoVZkNyA3RGeM

> fragmentation (and it seems like a pretty bad idea to rely on
> fragmentation for DHCPv6 packets), the practical limit to the number of
> addresses that can be assigned is about 30, less if lengthy options such
> as long domain search lists are used. So, what do you do downstream?
> Because the draft recommends that addresses be provided to hosts "when
> they connect to the network", what is a host supposed to do if it gets
> 20 IA_NA and the user starts a VM? How many should it provide to that
> VM? 10? What if the user starts two more VMs, does the third one start
> IPv4-only? At what point is the host - which to its VMs acts as the
> "network" be forced to violate the spirit of this draft because it
> simply didn't get enough space from the upstream to provide enough
> addresses to the VMs?
>
> This is a very important consideration, but it does not really belong
> here because host behaviour is out of scope for this draft. I think that
> the current text recommending DHCPv6 PD is a reasonable compromise. As
> the draft says, /64 has none of these problems because it provides 17
> orders of magnitude more space.

This was helpful context to rationalize the recommendation to do DHCPv6 
PD over multiple IA_NA.  I would feel much better about the current 
recommendation text if these issues were added as an appendix or something.

Without it, I feel there there is a little too much of "you'll be better 
off if you just do what we tell you to do" going on.

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jan 2016 11:10:43 +0900

On Thu, Jan 14, 2016 at 10:20 AM, David Farmer <[email-masked]> wrote:

> Erik characterized things as "little experience" with both PD and multiple
> IA_NA.  Where as you characterize things as "little experience" with PD and
> "little or no experience" with multiple IA_NA.  I'm probably being overly
> sensitive here, but that is the kind of thing I was referring too, there
> seems to be an implication there.
>
> My suggestion, characterize things as "little experience" for both PD and
> multiple IA_NA to avoid any bias or implication.
>

The text was only intended to reflect my understanding of reality. I am not
aware of any DHCPv6 client that requests multiple IA_NA options, but I am
aware of several popular DHCPv6 PD implementations that run on host
operating systems (at least the Windows implementation, plus dibbler, ISC
DHCP, and dhcpcd).

> intends to say "don't use multiple IA_NA", and without more rationale I'm
> not OK with that.
>
> This was helpful context to rationalize the recommendation to do DHCPv6 PD
> over multiple IA_NA.  I would feel much better about the current

I think most of those considerations are already in the draft where it
talks about multiple IA_NA as an option for providing multiple addresses.
The ones that are not are the MTU issue and the behaviour with respect to
downstream clients / functions. Can we just add those to the text that
talks about multiple IA_NA?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Jan 2016 07:11:16 +0100 (CET)

> think enumerating them would be useful.

Mostly it has to do with hardware resources, for instance TCAM or similar 
tables. Devices might have a few (tens of) thousands of these entries. So 
it makes sense to stop a device from using a lot of addresses.

> memory), I think they generate in the order of 16 addresses related to a 
> form of privacy addressing, although I can't remember if they're all 
> preferred/valid.

>From what I've seen in the wild, a device will (over a week) for a 
standard SLAAC A=1 deployment, have 1 LL address, 1 EUI-64 address, and up 
to 7 privacy extension addresses (lifetime a week, an changed daily). Then 
of course it might allocate itself other addresses, but this is what I 
have seen in Windows and Linux with no special applications running. With 
wifi clients that typically come and go, you seldom get these many privacy 
addresses of course, but instead the network might suffer more because 
some OSes allocate new privacy address every time it connects to the wifi 
network.

In the specific deployment that I heard a talk about, when you try to use 
your 9th address, this address will not work, if I remember correctly. 
Silently, no error message from the network.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 14 Jan 2016 07:56:02 +0100

* Lorenzo Colitti <[email-masked]>

> I am not aware of any DHCPv6 client that requests multiple IA_NA
> options

Try using dibbler-client with the following config file:

iface "foo" {
  ia
  ia
  ia
  ia
  # [...]
}

Key log excerpts from when doing so on my Homenet with OpenWrt 15.05:

[...]
2016.01.14 07:51:23 Client Info      Creating SOLICIT message with 4 IA(s), no TA and 0 PD(s) on p17p1/2 interface.
[...]
2016.01.14 07:51:24 Client Info      Received REPLY on p17p1/2,trans-id=0xfef1b, 10 opts: 2 1 23 24 20 11 3 3 3 3
[...]
2016.01.14 07:51:24 Client Notice    Address 2a02:fe0:c410:4835::32d/128 added to p17p1/2 interface.
2016.01.14 07:51:24 Client Debug     RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds.
2016.01.14 07:51:24 Client Notice    Address 2a02:fe0:c410:4835::385/128 added to p17p1/2 interface.
2016.01.14 07:51:24 Client Debug     RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds.
2016.01.14 07:51:24 Client Notice    Address 2a02:fe0:c410:4835::8c4/128 added to p17p1/2 interface.
2016.01.14 07:51:24 Client Debug     RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds.
2016.01.14 07:51:24 Client Notice    Address 2a02:fe0:c410:4835::6f0/128 added to p17p1/2 interface.
2016.01.14 07:51:24 Client Debug     RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds.
[...]

Just Works.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jan 2016 16:02:04 +0900

> Try using dibbler-client with the following config file:

True. It's likely that dibbler is almost (?) never configured like this by
default, wheres it's configured to do pd by default very often (on CPEs),
but point taken.

iface "foo" {
>   ia

Unfortunately I can't test dibbler because the version packaged on my
system segfaults on startup. :-( How many "ia" can you get this way? If you
specify more than 30, does it fragment?

---

From: Tore Anderson <[email-masked]>
Date: Thu, 14 Jan 2016 08:27:03 +0100

> default, wheres it's configured to do pd by default very often (on CPEs),

On my Fedora node the default client config file requests a single
IA_NA plus DNS server and search list, no PD. It uses this exact file
by default:

https://github.com/tomaszmrugalski/dibbler/blob/master/doc/examples/client.conf

So while both the the multi-IA_NA and IA_PD approaches work in a
Homenet, both would require manual config (at least in the Dibbler on
Fedora use case). Of course, SLAAC also works here so that point is
probably moot.

> specify more than 30, does it fragment?

I tried with 64. It got all addresses it wanted and configured them
fine, but it seems it had to split the request into multiple packets.
The client did that itself, at least I don't see any IPv6 fragments in
the PCAP at least.

In case you're insterested in having a closer look, I uploaded the
client log and a PCAP file here:

http://filebin.redpill-linpro.com/57mxq4hsfs

(Note: This is just meant to help the discussion with some neutral
facts, not take it as an opinion about whether your draft should say
this or that.)

Tore

---

From: Gert Doering <[email-masked]>
Date: Thu, 14 Jan 2016 13:47:27 +0100

Hi,

> Mentioning one of them as an actual or implied MAY doesn't dilute the

Now the remaining question is, of course, why the recommendation is for 
a /64 per host.   Why not a /60, or a /96?

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jan 2016 23:01:09 +0900

> a /64 per host.   Why not a /60, or a /96?

This is discussed in section 6. A /64 is recommended because prefixes
longer than /64 are outside the IPv6 specifications [RFC 7421], and because
a /64 can be easily extended via L2 bridging, ND proxying or /64 sharing
without impacting the network. This makes it possible for the host to
provide "unlimited" addressing to internal and subtended functions and
devices.

The address space requirements are discussed in section 9.2, which shows
that with a /64 per host, a /40 can address enough devices as an IPv4 /8
with one IPv4 address per host. The draft states that networks that are big
enough to use substantial parts of a /8 can easily get an IPv6 /40. You
disputed that assertion, but several others disagree with you. My reading
of RIPE-655 section 5.4.2 says that a site can get more than a /48 if it
justifies it.

The cost in terms of routing slots is the same as IPv4. Just as you don't
put the IPv4 /32s of individual hosts in your IGP, but instead route
aggregates (/24, /21, whatever), you wouldn't put the IPv6 /64s of
individual hosts in the IGP, but would instead route aggregates of
corresponding size.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jan 2016 23:02:47 +0900

On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti <[email-masked]>
wrote:

> A /64 is recommended because prefixes longer than /64 are outside the IPv6
> specifications
>

Forgot to mention: yes, the draft could be updated to say "at least a /64"
instead of "a /64". We did not see any need to do so, however.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2016 15:07:01 +0100

Hi Fred,

Le 13/01/2016 18:52, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: v6ops
>> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
>> Sent: Wednesday, January 13, 2016 1:02 AM To: [email-masked]
>> Subject: Re: [v6ops] I-D Action:
>>>> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD.
>>>> At best it says at one point "e.g., via DHCPv6 PD" and
>>>> certainly never elevates PD above any other solution.
>>>
>>> "it is RECOMMENDED that the network assign a /64 prefix to every
>>> host (e.g., via DHCPv6 PD)."
>>>
>> Right, there is no other Stds Track RFC that could do this (other
>> than DHCP-PD), but there is Prefix Delegation extension to ND
>> protocol - an individual Internet Draft:
> What would be the operational advantage for an ND-based prefix
> delegation extension?

The operational advantage would be related to performing software
implementations.

> AFAICT, it would require either new messages or extensions to
> database and the routing system. The draft indicated that it could
> provide a "faster and less resource consuming way", but I don't see
> how it could get around managing the same sort of state as for DHCPv6
> nor how the message exchanges could be made more efficient?

Less resource consuming on the UE mainly (the "Host")- because it would
be small extensions of existing software (ND parts in kernel and
userspace), rather than adding new software suite (DHCPv6 daemon in
userspace).  This is relevant in some UE chipsets allowing only 150mb
free ram after the ND parts are already there.

Indeed state must be managed at ND server (DHCP Server equivalent).  But
that is a large computer in the network - it can afford much memory and
fast clock.

The message exchange can be more efficient because ND typically involves
2 messages (Solicitation/Advertisement) whereas DHCP typically involves
4 messages (Solicit/Advertize/Request/Response) although exceptions exist.

Yours,

Alex

>
> Thanks - Fred [email-masked]
>
>> Alex
>>
>>
>>> argueing that this would *not* be recommending DHCPv6-PD is a bit
>>> weird.
>>>
>>> But if this is not about recommending DHCPv6-PD, and it's just an
>>> example, I would be happy to see that "(e.g. via DHCPv6 PD)"
>>> clause go away, and also remove all references to "DHCPv6 PD" in
>>> 9.3 - keeping the discussion about the routing model as
>>> alternative to burdening the ND layer is fine, but if you don't
>>> want to recommend DHCPv6 PD, then don't mention it as a
>>> particular technology.
>>>
>>> Gert Doering -- NetMaster
>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2016 15:08:07 +0100

> free ram after the ND parts are already there.

I meant 92mb free after ND is already there in a total of 150mb ram.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2016 15:28:38 +0100

Hi,

Le 14/01/2016 15:01, Lorenzo Colitti a écrit :
> On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> longer than /64 are outside the IPv6 specifications [RFC 7421],

Ok for no prefixes longer than /64 because some IPv6 spec [RFC7421].

But why not a prefix _shorter_ than /64, like a /60?  (it's not clear to 
me whether the explanation you provide below, or section 9.2, answers 
this question).

Alex
[*] note that other IPv6 specs (RFC4862, RFC7608) say that any prefix
     lengths are ok for SLAAC and for forwarding.

  and
> because a /64 can be easily extended via L2 bridging, ND proxying or /64
> sharing without impacting the network. This makes it possible for the
> host to provide "unlimited" addressing to internal and subtended
> functions and devices.
>
> with one IPv4 address per host. The draft states that networks that are
> big enough to use substantial parts of a /8 can easily get an IPv6 /40.
> You disputed that assertion, but several others disagree with you. My
> reading of RIPE-655 section 5.4.2 says that a site can get more than a
> /48 if it justifies it.
>
> The cost in terms of routing slots is the same as IPv4. Just as you
> don't put the IPv4 /32s of individual hosts in your IGP, but instead
> route aggregates (/24, /21, whatever), you wouldn't put the IPv6 /64s of

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2016 15:30:13 +0100

at least _one_ /64? (i.e. better would _two_ distinct /64s)

or plen value at least 64? (i.e. better would be 63)

Alex

Le 14/01/2016 15:02, Lorenzo Colitti a écrit :
> On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     A /64 is recommended because prefixes longer than /64 are outside
>     the IPv6 specifications
>
>
> Forgot to mention: yes, the draft could be updated to say "at least a
> /64" instead of "a /64". We did not see any need to do so, however.
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Jan 2016 15:44:45 +0000

Hi Lorenzo,

> The cost in terms of routing slots is the same as IPv4. Just as you don't put the IPv4 /32s of individual hosts in your IGP, but instead route aggregates (/24, /21, > whatever), you wouldn't put the IPv6 /64s of individual hosts in the IGP, but would instead route aggregates of corresponding size.

That is per my reply to Gert and also as documented in AERO. Call it "scalable de-aggregation",
and it should be OK, e.g., to service 4B /64s taken from a /32. Managing routing for 4B mobile
nodes need not impact the IGP, where only the /32 or a few slightly longer prefixes need to
be advertised.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Jan 2016 15:46:26 +0000

Hi Lorenzo,

I would like to see it say “at least a /64”. For example, hosts with very complex
internal virtual networks might want to procure a /60, /56, etc.

Thanks – Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, January 14, 2016 6:03 AM
To: Gert Doering
Cc: [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:
Now the remaining question is, of course, why the recommendation is for
a /64 per host.   Why not a /60, or a /96?

A /64 is recommended because prefixes longer than /64 are outside the IPv6 specifications

Forgot to mention: yes, the draft could be updated to say "at least a /64" instead of "a /64". We did not see any need to do so, however.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Jan 2016 15:54:10 +0000

Hi Alex,

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Thursday, January 14, 2016 6:07 AM
> To: Templin, Fred L; [email-masked]

I'm not sure what you mean by that but, taking the AERO implementation
for example, the code to do DHCPv6 PD is no more performance-intensive
than that to do IPv6 ND messaging. In fact, the DHCPv6 PD client can be
written in about 1k lines of code.

> free ram after the ND parts are already there.

If you open up the kernel to hack it, you might just as well insert DHCPv6 PD
messaging - there is no law that says the client has to be implemented as a
user level daemon.

> that is a large computer in the network - it can afford much memory and

Right; same as for DHCPv6 server.

> 4 messages (Solicit/Advertize/Request/Response) although exceptions exist.

AERo uses the 2-message exchange option for DHCPv6 PD.

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Jan 2016 16:29:24 -0600

I agree a prefix length shorter than /64 can sometimes be useful, but it is not always necessary, and it is probably not necessary even most of the time for the situation under consideration in this draft.  Specifying that a /63 should always be assigned would be wasteful in many, if not most situations, and is therefore not acceptable to me. 

Furthermore, while IIDs shorter 64 bits or prefixes longer than /64 are allowed by the IPv6 architecture and therefore theoretically possible, there is no current specification providing for such prefixes, other than RFC6164 for /127 point to point router links.  Making a new exception and specifying prefixes longer than /64 is not within the scope of this document.

So, the current recommendation of "a /64 prefix" is the proper recommendation in my opinion, adding "or a shorter prefix if requested" would be a small improvement.  Assigning more than a /64 without an explicit request seems wasteful to me for an individual host.  An actual site, even a home, is another thing, but that not the situation considered in this draft.

> On Jan 14, 2016, at 08:30, Alexandre Petrescu <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jan 2016 08:37:11 +1100

On 16 Jan 2016 09:29, "David Farmer" <[email-masked]> wrote:
>
> I agree a prefix length shorter than /64 can sometimes be useful, but it
is not always necessary, and it is probably not necessary even most of the
time for the situation under consideration in this draft.  Specifying that
a /63 should always be assigned would be wasteful in many, if not most
situations, and is therefore not acceptable to me.
>
> Furthermore, while IIDs shorter 64 bits or prefixes longer than /64 are
allowed by the IPv6 architecture and therefore theoretically possible,
there is no current specification providing for such prefixes, other than
RFC6164 for /127 point to point router links.  Making a new exception and
specifying prefixes longer than /64 is not within the scope of this
document.
>
> So, the current recommendation of "a /64 prefix" is the proper
recommendation in my opinion, adding "or a shorter prefix if requested"
would be a small improvement.  Assigning more than a /64 without an
explicit request seems wasteful to me for an individual host.  An actual
site, even a home, is another thing, but that not the situation considered
in this draft.

+1

We don't need to constantly demonstrate that prefix lengths other than /64s
are supported by constantly not using /64s.

We try to provide flexibility but we also try to provide default parameter
values that work for most cases. Not providing common case defaults would
create too many decisions to make for the operators of these protocols.
Most would use what others are using, so conventions would arise over time.
Providing reasonable defaults is providing automated expected conventions.

I can't think of anything close to a common case where a host would need
more than a /64 of addresses for its own application use. If there are any
obscure ones, it can be facilitated with a multiple /64 delegated prefix
using DHCPv6-PD, which the host would then turn into flat space for its own
use.