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

From: [email-masked]
Date: Thu, 10 Dec 2015 07:18:47 -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-03.txt
	Pages           : 13
	Date            : 2015-12-10

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-03

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

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: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Dec 2015 16:36:35 +0000

Hi, this is a good start at addressing my point on DAD avoidance, but it is silent on
strong vs weak end system models. The document now says that addresses from
a delegated prefix can be assigned to an internal interface such as a loopback which
would be an example of a weak end system as I had stated earlier. But, addresses
could also be assigned to the interface over which the prefix is received as long as
the prefix itself is not added to the prefix list for that interface, which would be a
strong end system example. This may be important for any hosted applications
that care one way or the other about strong vs. weak end system.

Please also see Sections 3 and 4 of my draft that was announced here on
11/06/2015:

https://mailarchive.ietf.org/arch/msg/v6ops/bJibVSFoCLd_SFbYfnSf9hRlXIA

I wrote this draft as a backup in case the subject would not be fully covered
in your document, but it appears that you are now willing to provide coverage.
Please consider including a discussion of strong vs. weak end system models,
as well as the option of assigning addresses taken from a delegated prefix
to the interface over which the prefix delegation was received.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, December 10, 2015 7:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 11 Dec 2015 01:46:34 +0900

On Fri, Dec 11, 2015 at 1:36 AM, Templin, Fred L <[email-masked]>
wrote:

> But, addresses
> could also be assigned to the interface over which the prefix is received
> as long as the prefix itself is not added to the prefix list for that
> interface

No, that's a violation of section 1 of RFC 4862, which says:

   To ensure that all configured addresses are likely to be unique on a
   given link, nodes run a "duplicate address detection" algorithm on
   addresses before assigning them to an interface.  The Duplicate
   Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

The text in the address availability draft is careful not to violate the
text above; it does so by saying that DAD can be avoided if the address is
not assigned to the physical interface.

> in your document, but it appears that you are now willing to provide

I think it's fine to mention in passing (as we now do), but I think a more
detailed description is out of scope. This document is about
recommendations on assigning multiple addresses to to hosts, not how the
hosts configure the addresses that they get.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Dec 2015 17:04:23 +0000

Hi Lorenzo,

RFC4862 says that DAD does not need to be performed on interfaces that have
DupAddrDetectTransmits set to 0. The document therefore shows flexibility for
determining when DAD is needed. An interface that receives a delegated prefix
*but no on-link prefixes* may still need to do DAD for the link local address
(some interfaces don’t even need to do DAD for link-local) but can avoid DAD
for addresses taken from the delegated prefix since the prefix itself is guaranteed
to not be delegated to any other node.

If there were the possibility that the same prefix could be delegated to more than
one node, then there would be much bigger issues that could not be resolved by
DAD anyway. It would constitute a major routing issue and, again, DAD would not
be able to resolve it. So, again, there is no need for DAD.

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 8:47 AM
To: Templin, Fred L
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Fri, Dec 11, 2015 at 1:36 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
But, addresses
could also be assigned to the interface over which the prefix is received as long as the prefix itself is not added to the prefix list for that interface

The text in the address availability draft is careful not to violate the text above; it does so by saying that DAD can be avoided if the address is not assigned to the physical interface.

I think it's fine to mention in passing (as we now do), but I think a more detailed description is out of scope. This document is about recommendations on assigning multiple addresses to to hosts, not how the hosts configure the addresses that they get.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 11 Dec 2015 14:38:53 +0900

On Fri, Dec 11, 2015 at 2:04 AM, Templin, Fred L <[email-masked]>
wrote:

> determining when DAD is needed.
>

Perhaps, but DupAddrDetectTransmits is an "autoconfiguration-related
variable to be configured by system management for each multicast-capable
interface". That statement does not allow an implementation to autonomously
decide to set it to 0, nor does it allow anyone (implementation or system
manager) to set it to 0 for a particular prefix, bot not other prefixes, on
an interface.

You could argue that it's within the remit of v6ops to publish an
operational guidance document that says that implementations could or
should do this, though some might argue that that's a call that only 6man
can make.

If there were the possibility that the same prefix could be delegated to
> more than

FWIW I do agree with you. There is no technical need for DAD in such a
situation. But just because there is no technical need to do DAD doesn't
mean that we can state that a host can skip doing DAD, because that
violates the letter of RFC4862.

In other words, my objection is not technical, but procedural. If we want
to make it possible for hosts to avoid DAD in this situation, we can't just
bury that statement in this draft. We need a more targeted document and
perhaps 6man involvement.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 11 Dec 2015 07:21:37 +0000

Fred, to be honest, this is getting pretty marginal with respect to the scope of the draft. Lorenzo has stated that he considers it out of scope, and at first blush I would agree – the scope is about the number of addresses that get assigned when at least one gets assigned (whether to an interface or a system), not an update to RFC 4862 on the use of DAD.

If you think the scope needs to include DAD and the strong and weak host models, I think you need to support the argument.

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 10, 2015 at 8:46 AM
To: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[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-03.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 16:44:43 +0000

Hi Fred,

I think I need the community’s help in understanding the tradeoffs for strong vs. weak
end system models in terms of the behavior hosted applications will observe before I
can comment further. As I understand it, when a PD prefix is received over a common
interface type such as multicast-capable (call it “eth0”), but addresses from the PD
prefix are assigned to an internal virtual interface (call it “lo0”) applications will observe
packets arriving with a destination address other than the ones assigned to the
interface the packet arrived on. That is the weak end system model. If we could
somehow assign the addresses to “eth0”, it then becomes strong end system.

But, the question is whether weak end system is a bad thing, and is it worth taking
measures to present the application with a strong end system model? This is where
I think we need the help of community – especially app developers – to understand
the tradeoffs. What is it that apps expect to see?

Thanks – Fred

From: Fred Baker (fred) [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 11:22 PM
To: Templin, Fred L
Cc: [email-masked]; Lorenzo Colitti
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Dec 2015 08:45:10 -0800

At Fri, 11 Dec 2015 14:38:53 +0900,

> perhaps 6man involvement.

+1.  That's what I suggest about a month ago, too:
https://mailarchive.ietf.org/arch/msg/v6ops/Qe-0t0g0bFWlYseZUo0yMeFDAmo

BTW, in that sense I'm not even sure if we can safely add this
paragraph to the 03 version of the draft:

   Also, a DHCPv6 PD model with a dedicated /64 per host makes it
   possible for the host not to assign global IPv6 addresses directly to
   its physical network interface, but instead to assign them to an
   internal interface such as a loopback interface.  This obviates the
   need to perform Neighbour Discovery and Duplicate Address Detection
   for anything other than the link-local address on its physical
   network interface, reducing network traffic.

As far as I can see/remember, RFC4862 (or other standard documents)
doesn't explicitly obviate the need for DAD on a loopback interface.
Such a DAD doesn't make sense?  Maybe.  But especially if we are going
to publish a separate document describing cases for skipping DAD with
clearly updating RFC4862, it would be better to discuss the loopback
matter there, too, rather than quietly put the special case to
host-addr-availability.

--
JINMEI, Tatuya

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 11 Dec 2015 17:49:10 +0000

In the following, I am speaking as a member of the community. I expect other members of the community to chime in.

The "Strong" and "Weak" host models are defined in section 3.3.4.2  "Multihoming Requirements", and not in the part which is normative, but the "discussion" presented to assist in understanding. The requirements stated have to do with the choice of a source address, and consist of:

            The following general rules apply to the selection of an IP
            source address for sending a datagram from a multihomed
            host.

            (1)  If the datagram is sent in response to a received
                 datagram, the source address for the response SHOULD be
                 the specific-destination address of the request.  See
                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
                 section of [INTRO:1] for more specific requirements on
                 higher layers.

                 Otherwise, a source address must be selected.

            (2)  An application MUST be able to explicitly specify the
                 source address for initiating a connection or a
                 request.

            (3)  In the absence of such a specification, the networking
                 software MUST choose a source address.  Rules for this
                 choice are described below.

            There are two key requirement issues related to multihoming:

            (A)  A host MAY silently discard an incoming datagram whose
                 destination address does not correspond to the physical
                 interface through which it is received.

            (B)  A host MAY restrict itself to sending (non-source-
                 routed) IP datagrams only through the physical
                 interface that corresponds to the IP source address of
                 the datagrams.

Personally, I will note that the socket library doesn't provide for the application to select the source address it will use. There are ways around that, but generally speaking, the source address is chosen by the underlying communication layers.

The Strong and Weak models, there called "ES" or End System models, have to do with the interpretation of "MAY" in requirements A and B. In the Strong ES Model, MAY becomes MUST, and in the Weak ES Model, and MAY becomes MUST NOT. In the words of the RFC, A Strong ES emphasizes the distinction between a host and a router, and a Weak ES de-emphasizes that distinction. A Strong ES, in selecting a router (which it alternately calls an "IS" or a "gateway") the host performs a function

                         route(src IP addr, dest IP addr, TOS)
                                                        -> gateway

And a weak ES performs a function

                         route(dest IP addr, TOS) -> gateway, interface

The scope of this draft has to do with the number of addresses assigned or potentially assigned to the host. There are two obvious examples of the implications here.

One a fairly standard behavior of Windows, Mac, FreeBSD and Linux systems today, which is that when a router announced a SLAAC prefix in an RA, the host creates one "permanent" address, and in a rolling manner, creates and destroys a "temporary" address every day, with up to seven valid at any given time. It expects to announce the "permanent" address in DNS for the benefit of other systems desiring to communicate with it, and to originate sessions using its various "temporary" addresses. If it has ten interfaces and receives three separate RAs on each, it potentially has 30=10*3 prefixes announced to it, and it might have 240=30*8 active addresses at any given time.

The assumption made in draft-ietf-6man-multi-homed-host is that the host acts as a "strongish" host with respect to each of those prefixes. The difference between its model and RFC 1122's Strong Host model is, in a word, MIF; in selecting a first hop gateway, it might find that gateway on multiple interfaces.

The other is something we know some industry leaders to be experimenting with (draft-herbert-nvo3-ila), which is that DHCP-PD is used to allocate a prefix to a physical or virtual host. The implication of having done so is that the host has 2^64 addresses, which it may use in any way it chooses. If the host is multihomed (e.g., has more than one L2 interface), one has to assume that the routing system somehow knows to route traffic to that prefix to any of its interfaces, and one can expect the host itself to operate as a weak host – it will pump packets out whatever interface it chooses, and they will all be in that prefix. And BTW, there is no architectural reason it has to be exactly one prefix.

As someone noted to me yesterday in FB messaging, the question there becomes at what point we re-introduce the address exhaustion problem into IPv6. When do we find ourselves dealing out inefficiently used large blocks of addresses in such a willy-nilly manner that we actually start running out of prefixes to allocate? We have, nominally, 2^64 /64 prefixes we can allocate. When does that become a small number?

When I consider the implications of the Strong and Weak ES Models for this draft, I am forced to choose words that apply in both of these cases. From my perspective, speaking not as chair (which is a procedural role) but as an individual contributor (which is a technical role), my question becomes how to to further the scope of the draft without adding undue complexity or making the statement be about one paradigm or the other.

You're thinking, at this point, "Fred, this is one !@#$ of a long email! TL;DR!". Yes, and we can do that to this draft as well. I don't think that is a useful direction.

So, speaking as an individual contributor, I think the direction to go is simplicity. In both of the cases, what the draft targets is "when allocating addresses using DHCP/DHCPv6, please don't limit me to a single /128". The statement applies in both cases equally well. Introducing the Strong vs Weak ES Model discussion adds text to the draft, but I'm not sure it adds understanding to a BCP. Hence, I personally would leave the model discussion to another draft, and focus on the stated objective of the proposed Best Current Practice.

From: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 11, 2015 at 8:44 AM
To: Fred Baker <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

Hi Fred,

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

From: Fred Baker (fred) [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 11:22 PM
To: Templin, Fred L
Cc: [email-masked]<mailto:[email-masked]>; Lorenzo Colitti
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 11 Dec 2015 17:58:37 +0000

My apologies. I managed to miss the words "of RFC 1122".

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Fred Baker <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 11, 2015 at 9:49 AM
To: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Dec 2015 07:50:08 +1300

I agree with Jinmei-san. Also, it seems to me that performing DAD when
it isn't needed is much less risky than not performing DAD when it is
needed. So the default should always be DAD.

Regards
   Brian

On 12/12/2015 05:45, 神明達哉 wrote:
> .

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 19:01:26 +0000

Hi Jinmei-san,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Friday, December 11, 2015 8:45 AM
> To: Lorenzo Colitti
> Cc: Templin, Fred L; [email-masked]; [email-masked]; [email-masked]

Host-addr-availability speaks only about non-use of DAD on the physical
interface. It is silent on the use/non-use of DAD on the loopback interface,
and IMHO that is the way it should be. AFAICT, RFC4862 is also silent on
loopback interfaces. (Note: RFC4862, Appendix A talks about "Loopback
Suppression", but it is talking about something different and not to be
confused with a loopback interface.)

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 16:32:19 +0000

Hi Lorenzo,

I agree that “it gets messy” if you try to avoid DAD for PD prefixes while at the
same time honoring DAD for on-link prefixes (including link-local). I confess
that my angle is coming from the use case of the AERO interface, where there
are guaranteed to be no on-link prefixes other than link-local, all link-local
addresses are administratively assigned in a way that ensures uniqueness,
and everything is driven by DHCP6-PD so setting DupAddrDetectTransmits
to 0 is tenable. So assigning addresses taken from a PD prefix to the interface
while avoiding DAD and ND works fine. But in reality, the AERO interface is
an example of “an internal interface”, so using the text in your document
the AERO use case still flies (sorry for that) and hosted applications will still
observe a strong end system model.

But, it might be worth asking whether there are other interface types (such
as NBMA), or use cases for common interface types (such as multicast-capable)
where you can get away with turning off DAD and MLD. If you can do that,
you can assign addresses from a PD prefix to the interface it arrived on.

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 9:39 PM
To: Templin, Fred L
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Fri, Dec 11, 2015 at 2:04 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
RFC4862 says that DAD does not need to be performed on interfaces that have
DupAddrDetectTransmits set to 0. The document therefore shows flexibility for
determining when DAD is needed.

Perhaps, but DupAddrDetectTransmits is an "autoconfiguration-related variable to be configured by system management for each multicast-capable interface". That statement does not allow an implementation to autonomously decide to set it to 0, nor does it allow anyone (implementation or system manager) to set it to 0 for a particular prefix, bot not other prefixes, on an interface.

You could argue that it's within the remit of v6ops to publish an operational guidance document that says that implementations could or should do this, though some might argue that that's a call that only 6man can make.

FWIW I do agree with you. There is no technical need for DAD in such a situation. But just because there is no technical need to do DAD doesn't mean that we can state that a host can skip doing DAD, because that violates the letter of RFC4862.

In other words, my objection is not technical, but procedural. If we want to make it possible for hosts to avoid DAD in this situation, we can't just bury that statement in this draft. We need a more targeted document and perhaps 6man involvement.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 16:51:57 +0000

Did this get through?

From: Templin, Fred L
Sent: Friday, December 11, 2015 8:32 AM
To: 'Lorenzo Colitti'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

Hi Lorenzo,

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 9:39 PM
To: Templin, Fred L
Cc: [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-03.txt

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 12 Dec 2015 10:05:12 +0900

> matter there, too, rather than quietly put the special case to

How about making a slight tweak in the ordering and changing the text to
this:

   This obviates the need to perform Neighbour Discovery and
   Duplicate Address Detection on its physical network interface
   for anything other than the link-local address, reducing network traffic.

I think that's a statement that does not conflict in any way with RFC 4862.
Because the global addresses are not assigned to the physical interface,
the node does not need to do ND or DAD on the physical interface for
anything except the link-local address.

Whether such a node would do DAD internally over "an internal interface
such as a loopback interface" then becomes a separate question. Optionally,
we could also change "loopback interface" to "loopback interface or bridge
interface" which is likely what is going to happen in reality.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 12 Dec 2015 10:07:12 +0900

> you can assign addresses from a PD prefix to the interface it arrived on.

Maybe, but not in this document. :-)

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Dec 2015 12:20:49 +1100

> On Sat, Dec 12, 2015 at 1:45 AM, 神明達哉 <[email-masked]> wrote:
<snip>
> Because the global addresses are not assigned to the physical interface, the
> node does not need to do ND or DAD on the physical interface for anything
> except the link-local address.
>

+1 in my opinion.

> Whether such a node would do DAD internally over "an internal interface such
> as a loopback interface" then becomes a separate question. Optionally, we
> could also change "loopback interface" to "loopback interface or bridge

Also +1 in my opinion.

Regards,
Mark.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Dec 2015 18:25:53 -0800

At Sat, 12 Dec 2015 10:05:12 +0900,

> > doesn't explicitly obviate the need for DAD on a loopback interface.

[...]

>    for anything other than the link-local address, reducing network traffic.

Ah, okay, I realized I misunderstood the intent of the original text.
I'm not sure if it was only me who were confused about this, but the
"tweaked" version is certainly better to avoid such confusion.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 12 Dec 2015 13:23:38 +0900

> "tweaked" version is certainly better to avoid such confusion.

I think you didn't misunderstand. I didn't realize that the text had that
corner case. :-) Fixed in my local tree.

---

From: Joe Touch <[email-masked]>
Date: Sat, 12 Dec 2015 06:36:42 -0800

On 12/11/2015 9:49 AM, Fred Baker (fred) wrote:
...
> The "Strong" and "Weak" host models are defined in section 3.3.4.2
>  "Multihoming Requirements", and not in the part which is normative, but
> the "discussion" presented to assist in understanding. The
> requirements stated have to do with the choice of a source address, and
> consist of:
...
>                  choice are described below.
...
> Personally, I will note that the socket library doesn't provide for the
> application to select the source address it will use. 

In the most common libraries, "bind" does exactly this. Most people set
the host address as "0", which - in the implementation, typically
indicates "let the networking software choose" ((3) above), but setting
it to one of the host's IP addresses accomplishes exactly (2) above.

> There are ways
> around that, but generally speaking, the source address is chosen by the
> underlying communication layers.

This is true only because this is the choice most applications make, not
because of a lack of API.

---

Getting back to the ES model:

>                  the datagrams
...
> The Strong and Weak models, there called "ES" or End System models, have
> to do with the interpretation of "MAY" in requirements A and B. In the
> Strong ES Model, MAY becomes MUST, and in the Weak ES Model, and MAY
> becomes MUST NOT. In the words of the RFC, A Strong ES emphasizes the
> distinction between a host and a router, and a Weak ES de-emphasizes
> that distinction.

Internet hosts and routers both support BOTH the strong and weak model -
strong at the link layer and weak at the network layer.

Forwarding *requires* that the link layer be strong, but makes no
requirement on the network layer being strong vs. weak. However, some
routing protocols seem to assume more of a weak ES model, but others
assume a strong one (esp. those that assume bidirectionality of
connectivity announcements).

...
> So, speaking as an individual contributor, I think the direction to go
> is simplicity. In both of the cases, what the draft targets is "when
> allocating addresses using DHCP/DHCPv6, please don't limit me to a
> single /128". The statement applies in both cases equally well.
> Introducing the Strong vs Weak ES Model discussion adds text to the
> draft, but I'm not sure it adds understanding to a BCP. Hence, I
> personally would leave the model discussion to another draft, and focus
> on the stated objective of the proposed Best Current Practice.

+1

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Dec 2015 12:53:30 +1300

> it to one of the host's IP addresses accomplishes exactly (2) above.

sockaddr_in6 also allows you to set the flow label and the interface (Zone)
ID. The latter is essential if binding to a link-local address.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Dec 2015 09:44:55 +0900

>    for anything other than the link-local address, reducing network

Fred, would this text address your concerns on DAD?

As I said, I think discussion on strong vs. weak host model is out of scope
for this document.

---

From: David Farmer <[email-masked]>
Date: Mon, 14 Dec 2015 19:34:21 -0600

I'm beginning to wonder if document shouldn't explicitly say the details 
of assigning a /64 prefix to every host, such as via DHCPv6 PD, are 
beyond the scope of this document and the subject of work in progress 
and possible future work, with an informational reference to 
draft-ietf-v6ops-unique-ipv6-prefix-per-host and any other similar work.

On 12/11/15 01:21 , Fred Baker (fred) wrote:
> Fred, to be honest, this is getting pretty marginal with respect to the
> scope of the draft. Lorenzo has stated that he considers it out of
> scope, and at first blush I would agree – the scope is about the number
> of addresses that get assigned when at least one gets assigned (whether
> to an interface or a system), not an update to RFC 4862 on the use of DAD.
>
> If you think the scope needs to include DAD and the strong and weak host
> models, I think you need to support the argument.
>
> From: v6ops <[email-masked] <mailto:[email-masked]>> on
> behalf of Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[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-03.txt
>
> On Fri, Dec 11, 2015 at 1:36 AM, Templin, Fred L
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     But, addresses
>     could also be assigned to the interface over which the prefix is
>     received as long as the prefix itself is not added to the prefix
>     list for that interface
>
>
> text above; it does so by saying that DAD can be avoided if the address
> is not assigned to the physical interface.
>
> I think it's fine to mention in passing (as we now do), but I think a
> more detailed description is out of scope. This document is about

-- 
================================================
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, 15 Dec 2015 12:02:01 +0900

I don't think we should declare that out of scope.

I think it has always been clear what the scope of this draft was:
recommendations around how much address space networks should provide to
hosts, and the mechanisms by which they should provide it. The "how" is not
just about SLAAC and DHCPv6 NA, DHCPv6 PD: for example, the one point the
draft makes on "how" is that that address space should be provided up front
rather than on demand, etc. All that material has essentially been in the
draft since the beginning, I think we have mostly been in agreement on it
all the way back to -00.

On the other hand, I think it's also pretty clear that documenting host
behaviour is out of scope; there are no host requirements in the document
now, and attempting to add them would require a whole lot more text, and a
whole lot more time. That should be done in other documents, if necessary.

I'd argue it's also fairly clear that things like /64-per-host are also out
of scope. Again, this draft focuses on is how much space the network
provides, and what mechanisms it uses to do so. From that perspective,
there's no difference at all between /64-per-host and a shared /64 with
only one host on it at any given time. The mechanisms are exactly the same.

So I think say we should should advance the document it as is, modulo the
DAD tweak I suggested.

On Tue, Dec 15, 2015 at 10:34 AM, David Farmer <[email-masked]> wrote:

> of assigning a /64 prefix to every host, such as via DHCPv6 PD, are beyond
> the scope of this document and the subject of work in progress and possible
> future work, with an informational reference to
>> behalf of Lorenzo Colitti <[email-masked] <mailto:[email-masked]
>> >>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Dec 2015 03:58:48 +0000

> On Dec 14, 2015, at 5:34 PM, David Farmer <[email-masked]> wrote:
> 
> I'm beginning to wonder if document shouldn't explicitly say the details of assigning a /64 prefix to every host, such as via DHCPv6 PD, are beyond the scope of this document and the subject of work in progress and possible future work, with an informational reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host and any other similar work.

I think there may be value. There is enough to understand about the use of DHCP-PD that hasn't been discussed or documented that trying to make detailed remarks on it in this draft seems premature.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Dec 2015 04:03:10 +0000

> On Dec 14, 2015, at 7:02 PM, Lorenzo Colitti <[email-masked]> wrote:
> 

> I'd argue it's also fairly clear that things like /64-per-host are also out of scope.

> So I think say we should should advance the document it as is, modulo the DAD tweak I suggested.
> 
> On Tue, Dec 15, 2015 at 10:34 AM, David Farmer <[email-masked] <mailto:[email-masked]>> wrote:

As I just said to David, I do think the mechanism is out of scope, and a lot of the details of it implementation are therefore out of scope. Your statement leaves me confused; "the details of assigning a /64 per host" should not be out of scope, but "/64 per host" should be out of scope.

Personally, I'll agree with the third statement I quoted above. Let's tweak DAD, if you agree it's important, but leave mechanisms, prefixes, and the sizes of prefixes to another draft.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Dec 2015 04:08:50 +0000

Hi Lorenzo,

I see what you are getting at, but one thing that has been gnawing at me
regarding this and the previous sentence is the use of the term “physical
network interface”. For example, the interface the DHCPv6 PD was received
on could be a virtual interface. I think I know what you are trying to say,
but is there a different term that could be used instead of “physical”?

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, December 14, 2015 4:45 PM
To: 神明達哉
Cc: Templin, Fred L; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Sat, Dec 12, 2015 at 10:05 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
How about making a slight tweak in the ordering and changing the text to this:

As I said, I think discussion on strong vs. weak host model is out of scope for this document.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Dec 2015 13:24:54 +0900

On Tue, Dec 15, 2015 at 1:03 PM, Fred Baker (fred) <[email-masked]> wrote:
>
> Personally, I'll agree with the third statement I quoted above. Let's
> tweak DAD, if you agree it's important, but leave mechanisms, prefixes, and
> the sizes of prefixes to another draft.
>

But wait... it seems to me that we've had pretty good consensus on the
current text for most of its lifetime. The draft most definitely does
include prefix sizes and discussions of mechanisms. For example, it says
that if explicit assigment of addresses are necessary, the network should
assign a /64 per host using DHCPv6 PD. So it mentions prefixes, sizes and
mechanisms. That text has been there from the beginning, and went through
WG last call. Are you saying we should now pull that text out?

It doesn't seem that anyone currently disagrees with those statements per
se. Yes, there are some doubts about DAD, but to my mind that's mostly a
procedural issue: I think everybody here agrees that DAD is not useful in a
scenario where a /64 is dedicated to the host, but RFC 4862 requires it, so
we have to be careful about the wording.

If we were to take out text about prefix sizes and mechanisms, then a
substantial part of the recommendations (i.e., where we recommend a /64,
and where we recommend DHCPv6 PD) would be struck. That seems like
substantial enough changes to the document as to have to declare a new last
call. Is it your read that that is necessary? Those recommendations have
been in there since the beginning, and it has always seemed to me that we
all agreed on them. Why reopen those discussions now?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Dec 2015 13:32:01 +0900

> but is there a different term that could be used instead of “physical”?

What if we just removed  the word "physical", like so?

   Also, a DHCPv6 PD model with a dedicated /64 per host makes it
   possible for the host not to assign global IPv6 addresses directly to
   its network interface, but instead to assign them to an internal
   interface such as a loopback interface.  This obviates the need to
   perform Neighbour Discovery and Duplicate Address Detection
   on its network interface for anything other than the link-local address
   network interface, reducing network traffic.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Dec 2015 13:52:21 +0900

On Tue, Dec 15, 2015 at 1:03 PM, Fred Baker (fred) <[email-masked]> wrote:

> As I just said to David, I do think the mechanism is out of scope, and a
> lot of the details of it implementation are therefore out of scope. Your
> statement leaves me confused; "the details of assigning a /64 per host"
> should not be out of scope, but "/64 per host" should be out of scope.
>

What I meant was that the network architecture required to assign a /64 per
host should not be in scope. draft-ietf-v6ops-unique-ipv6-prefix-per-host
is about how you build a network where each user has their own /64. That is
great work, and I believe it is the best approach we have for deploying
networks shared across multiple untrusted users such as a public wifi
network, but it is a separate topic from this document, even though what it
does is follow the recommendations in this document.

What should be (and, I think, has always been) in scope for this document
is what the network provides the host (multiple addresses) and how it
conveys that information to the host (RA, DHCPv6 PD with a /64). From that
perspective, a network that sends an RA with A=1 to a link which will only
ever have one host on it, and a network that sends an RA with A=1 to a link
which might have 10, 100, or 1000 hosts are the same. In both cases the
network sends an RA with A=1, and in both cases the host behaves as per the
IPv6 specifications.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 14 Dec 2015 21:11:16 -0800

> but is there a different term that could be used instead of “physical”?

It seems likely that if you have something on a loopback or sufficently
similar interface you're not guarding it with dad.

> *From:*Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Monday, December 14, 2015 4:45 PM
> *To:* 神明達哉
> *Cc:* Templin, Fred L; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [v6ops] I-D Action:

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 14 Dec 2015 22:21:20 -0800

> Personally, I'll agree with the third statement I quoted above. Let's tweak DAD, if you agree it's important, but leave mechanisms, prefixes, and the sizes of prefixes to another draft.

I agree with Lorenzo’s sentiments on this.

As IETF drafts go, this one is not saying anything especially controversial. It seems to have broad community support. One of the benefits of IPv6 is that it offers enough addresses to obviate the need for awkward and fragile address sharing technologies. It is significant that after Apple’s move to require IPv6 support for iOS 9 apps, the handful of apps that have trouble with this are largely the peer-to-peer apps that embed brittle IPv4 NAT traversal techniques. This draft warns that unnecessarily parsimonious allocation of IPv6 addresses may inadvertently lead us back to the same problems that we were trying to escape with the move away from IPv4. The community seems to agree about that.

A main benefit of IPv6 is that it lets us shed much of the baggage that IPv4 accumulated over the years. The more of that baggage with bring to IPv6, the more we erode the benefit of IPv6. There seems to be broad agreement on that. In the Working Group Last Call the comments were mostly minor, not disagreeing with the basic premise of the draft, and the authors worked to update the draft to address those comments. Then the document was opened up to a further round of comments, and the authors worked to update the draft to address those comments too.

Fred, it sounds like you’re asking us to declare the bulk of the document to be out-of-scope and saying that it should be deferred to some unspecified future document. I agree that the discussion points regarding DAD and that strong/weak host model should be deferred but the draft seems to have reached rough consensus in its current form.

Stuart Cheshire

---

From: Erik Kline <[email-masked]>
Date: Tue, 15 Dec 2015 15:53:36 +0900

> Fred, it sounds like you’re asking us to declare the bulk of the document to be out-of-scope and saying that it should be deferred to some unspecified future document. I agree that the discussion p…

Agreed.

+1 also to the proposed clarification for the last paragraph of section 9.3.

I think this document *already* leaves the details of address
assignment out.  Section 6 is really just a survey of currently
available protocol mechanisms for obtaining multiple addresses.  The
proposed change to 9.3 makes that paragraph appear to be appropriately
less prescriptive.

IMHO

---

From: [email-masked]
Date: Tue, 15 Dec 2015 09:07:25 +0100

> proposed change to 9.3 makes that paragraph appear to be appropriately

I also think the document (with last paragraph of 9.3 changed/deleted) strikes the right balance.

Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Dec 2015 15:16:51 +0000

Hi Lorenzo,

Almost. What would make me happier is if we could drop the phrase
beginning: “not to assign global IPv6 addresses” in the first sentence
so that we would have:

  “Also, a DHCPv6 PD model with a dedicated /64 per host makes it
   possible for the host to assign them to an internal interface such as
   a loopback interface.  This obviates the need to  perform Neighbour
   Discovery and Duplicate Address Detection on its network interface
   for anything other than the link-local address  network interface,
   reducing network traffic.”

Does this work for you?

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, December 14, 2015 8:32 PM
To: Templin, Fred L
Cc: 神明達哉; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Tue, Dec 15, 2015 at 1:08 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Dec 2015 00:36:02 +0900

Fred,

the problem is as follows.

If the host assigns the addresses to its external network interface and
does not do DAD, then it is a violation of RFC 4862, period. The text is
very clear:

   nodes run a "duplicate address detection" algorithm on
   addresses before assigning them to an interface.  The Duplicate
   Address Detection algorithm is performed on all addresses

Therefore, in order to say that DAD is not necessary on the external
network interface, our document must say that the addresses are not
assigned to that interface. Otherwise we are recommending a violation of,
or a change to, RFC 4862, and that is beyond the remit of this working
group.

Let me suggest (almost identical) text again:

   Also, a DHCPv6 PD model with a dedicated /64 per host makes it
   possible for the host not to assign addresses directly to its network
   interface, but instead to assign them to an internal interface such as
   a loopback interface.  This obviates the need to perform Neighbour
   Discovery and Duplicate Address Detection on its network interface
   for anything other than the link-local address, reducing network traffic.

Are you saying that you don't want this text to say that the addresses are
not assigned to the network interface? But if the addresses *are* assigned
to the network interface, that's a violation of RFC 4862. Is that what
you're recommending?

Cheers,
Lorenzo

On Wed, Dec 16, 2015 at 12:16 AM, Templin, Fred L <[email-masked]

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Monday, December 14, 2015 8:32 PM
> *To:* Templin, Fred L
> *Cc:* 神明達哉; [email-masked]; [email-masked];
> [email-masked]
> On Tue, Dec 15, 2015 at 1:08 PM, Templin, Fred L <
> [email-masked]> wrote:
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Dec 2015 16:47:57 +0000

I have just seen several comments basically affirming Lorenzo's proposed clarifications and otherwise limiting the scope of this draft. I have stated my personal opinions, and have hopefully been clear that I don't consider my opinion normative. But following the conversation, my perception is that Fred has been trying to drive into the draft something that nobody else is calling for or sees as required, and in fact belongs in a separate draft. I'd like a sense of the list on that.

I'll give you four options: (1) the draft is fine as it stands, (2) Lorenzo's proposed clarifications make the draft represent your view, (3) the DHCP-PD consideration Fred is driving needs to be more thoroughly addressed, or (4) there is a fourth outcome that needs to happen. In the fourth case, please tell me what that would be. Please comment to [email-masked], and I'll report the outcome as it is in my inbox ~24 hours hence.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Dec 2015 02:13:52 +0900

On Wed, Dec 16, 2015 at 1:47 AM, Fred Baker (fred) <[email-masked]> wrote:

> But following the conversation, my perception is that Fred has been trying
> to drive into the draft something that nobody else is calling for or sees
> as required, and in fact belongs in a separate draft. I'd like a sense of
> the list on that.
>

One thing that's worth mentioning, I think: as I recall (I may be wrong, of
course), Fred's main concern was/is not so much that the draft should make
a general statement on how hosts should behave when acquiring a prefix via
DHCPv6 PD. I think his concern was/is that the draft should to make a
statement that it was possible to avoid DAD when using DHCPv6 PD.

If the above is accurate, then we should also ask ourselves to what degree
that is even possible in any v6ops document. RFC 4862 is very clear on the
matter: if you assign an IPv6 address to an interface, you do DAD, unless
the applicable IPv6 over-foo RFC says that DAD is disabled by default. In
this draft and subsequent iterations we've tried to wordsmith the text to
say that DAD can be avoided by not assigning the address to the network
interface. I don't see a way to make a stronger statement than that without
stepping on RFC 4862.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Dec 2015 17:17:46 +0000

> On Dec 15, 2015, at 9:13 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
> 
> If the above is accurate, then we should also ask ourselves to what degree that is even possible in any v6ops document. RFC 4862 is very clear on the matter: if you assign an IPv6 address to an interface, you do DAD, unless the applicable IPv6 over-foo RFC says that DAD is disabled by default. In this draft and subsequent iterations we've tried to wordsmith the text to say that DAD can be avoided by not assigning the address to the network interface. I don't see a way to make a stronger statement than that without stepping on RFC 4862.

and I would agree that we are not scoped to update RFC 4862; that would be 6man's job.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Dec 2015 18:33:02 +0100

>(4) there is a fourth outcome that needs to 
>happen. In the fourth case, please tell me what that would be. 

Re-reading the draft, my first thought was to cut out the operational
experience as it relates to DHCPv6 PD. I.e., it is a good idea to
have multiple addresses, one way of doing that is using DHCPv6 PD, but
we don't really know how.

Then I noticed (and somehow I didn't notice before) that this is a BCP.

So now I wonder, do we have large scale experience with all 3 proposed
mechanisms? I know PD is used a lot for CPEs but for hosts I have never seen
it. Samething goes for hosts requesting multiple addresses using DHCPv6 IA_NA.

If there is no experience, maybe re-classify as informational?

---

From: David Farmer <[email-masked]>
Date: Tue, 15 Dec 2015 11:35:58 -0600

On 12/15/15 11:17 , Fred Baker (fred) wrote:
>> If the above is accurate, then we should also ask ourselves to what
>> degree that is even possible in any v6ops document. RFC 4862 is very
>> clear on the matter: if you assign an IPv6 address to an interface,
>> you do DAD, unless the applicable IPv6 over-foo RFC says that DAD is
>> disabled by default. In this draft and subsequent iterations we've
>> tried to wordsmith the text to say that DAD can be avoided by not
>> assigning the address to the network interface. I don't see a way to
>> make a stronger statement than that without stepping on RFC 4862.
>

And even if an update to RFC 4862 were in v6ops preview it's not the 
intent of this document.

---

From: David Farmer <[email-masked]>
Date: Tue, 15 Dec 2015 11:57:35 -0600

On 12/15/15 11:13 , Lorenzo Colitti wrote:
> On Wed, Dec 16, 2015 at 1:47 AM, Fred Baker (fred) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     But following the conversation, my perception is that Fred has been
>     trying to drive into the draft something that nobody else is calling
>     for or sees as required, and in fact belongs in a separate draft.
>     I'd like a sense of the list on that.
>
>
> One thing that's worth mentioning, I think: as I recall (I may be wrong,
> of course), Fred's main concern was/is not so much that the draft should
> make a general statement on how hosts should behave when acquiring a
> prefix via DHCPv6 PD. I think his concern was/is that the draft should
> to make a statement that it was possible to avoid DAD when using DHCPv6 PD.

This has been my impression too.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Dec 2015 08:33:45 +1300

(2) Lorenzo's proposed clarifications make the draft represent [my] view

And I am very comfortable with it as a BCP.

Regards
   Brian Carpenter

---

From: 神明達哉 <[email-masked]>
Date: Tue, 15 Dec 2015 11:40:40 -0800

At Tue, 15 Dec 2015 16:47:57 +0000,
"Fred Baker (fred)" <[email-masked]> wrote:

> I'll give you four options: (1) the draft is fine as it stands, (2)
> Lorenzo's proposed clarifications make the draft represent your

There were several revisions of "clarifications", and the difference
might matter in answering your question.  Specifically which revision
of the clarification(s) are you referring to?

> view, (3) the DHCP-PD consideration Fred is driving needs to be more
> thoroughly addressed, or (4) there is a fourth outcome that needs to
> happen. In the fourth case, please tell me what that would
> be. Please comment to [email-masked], and I'll report
> the outcome as it is in my inbox ~24 hours hence.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Dec 2015 22:24:11 +0000

Hi Lorenzo,

Let me present my proposed re-word again:

Where in this text does it say that addresses from the PD could be
assigned to the network interface? Nowhere that I can see. And,
from the discussions it seems clear that we don’t fully understand
the conditions under which an address could be assigned to the
network interface for all varieties of network interfaces. In cases
where something is not fully understood IETF documents typically
remain silent, and I think this document should do the same.

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, December 15, 2015 7:36 AM
To: Templin, Fred L
Cc: 神明達哉; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

Fred,

If the host assigns the addresses to its external network interface and does not do DAD, then it is a violation of RFC 4862, period. The text is very clear:

Therefore, in order to say that DAD is not necessary on the external network interface, our document must say that the addresses are not assigned to that interface. Otherwise we are recommending a violation of, or a change to, RFC 4862, and that is beyond the remit of this working group.

Are you saying that you don't want this text to say that the addresses are not assigned to the network interface? But if the addresses *are* assigned to the network interface, that's a violation of RFC 4862. Is that what you're recommending?

Cheers,
Lorenzo

On Wed, Dec 16, 2015 at 12:16 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lorenzo,

Does this work for you?

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, December 14, 2015 8:32 PM
To: Templin, Fred L
Cc: 神明達哉; [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-03.txt

Cheers,
Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Wed, 16 Dec 2015 08:34:21 +0900

I'm not sure I can tell the substantive difference between these last
two versions (save the strangling "network interface" phrase toward
the end of the last sentence).

Lorenzo's version reads to me as being a bit more of an example, and
Fred's last version as ever so slightly prescriptive by comparison,
but I could easily put that down to some weirdness of my own brain.

However, both those paragraphs assume the network interface /only/ has
link-local addresses, which need not be true.  I really hate to
perpetuate this bikeshed, but here goes.

   Also, a DHCPv6 PD model with a dedicated /64 per host makes it
   possible for the host to assign addresses from this prefix not to its
   network interface directly but instead to an internal interface,
   such as a loopback interface.  This obviates the need to perform Neighbour
   Discovery and Duplicate Address Detection on its network interface for
   these addresses, reducing network traffic.

Apologies,
-ek

On 16 December 2015 at 07:24, Templin, Fred L <[email-masked]> wrote:
> If the host assigns the addresses to its external network interface and does
> not do DAD, then it is a violation of RFC 4862, period. The text is very
> clear:
>
>
>
> Therefore, in order to say that DAD is not necessary on the external network
> interface, our document must say that the addresses are not assigned to that
> interface. Otherwise we are recommending a violation of, or a change to, RFC
> 4862, and that is beyond the remit of this working group.
>
>
>
> On Wed, Dec 16, 2015 at 12:16 AM, Templin, Fred L
> <[email-masked]> wrote:
>
> Hi Lorenzo,
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Dec 2015 10:25:11 +0900

>    these addresses, reducing network traffic.

That text works for me. Fred, does it work for you? If not, can you explain
why it does not work?

If you have a problem with the words "not to its network interface directly
but instead", then can you explain why those words are a problem? It seems
to me that *any* behaviour that is compliant with RFC 4862 must comply with
those words as well, and thus, there should not be a problem including
those words unless we want to prescribe/condone behaviour that violates RFC
4862.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Dec 2015 10:57:06 +0900

> we don't really know how.

Actually, I think we do know how. Remember that what is in scope for this
draft is what networks provide to hosts, and how. There is plenty of
operational experience on using DHCPv6 PD to assign address space - every
IPv6 CPE router on the planet does it.

You may be correct that there are doubts on what *hosts* should do when
delegated a block of addresses via DHCPv6 PD, but host behaviour is not
really in scope for this draft.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 16 Dec 2015 05:57:39 +0000

The latest

> On Dec 15, 2015, at 11:40 AM, 神明達哉 <[email-masked]> wrote:
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Dec 2015 13:43:46 +0100

>IPv6 CPE router on the planet does it.

In my opinion having a relatively static collection of CPEs (that are often
provided by the ISP) is very different from roaming mobile devices 
providing tethering or a collection of VMs, etc.

If you want to write that PD is best current practice for CPEs, then yes,
that's true. But for anything else, there is essentially no experience. It
is just hoping that experience with CPEs translates well to mobile devices.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Dec 2015 22:09:35 +0900

> is just hoping that experience with CPEs translates well to mobile devices.

Again, let's make sure we're agree on the scope of this document. What
we're talking about is how the network provides addresses, not how the
recipient of such addresses behaves. Yes?

If we agree that that is the scope of the document, then I don't think
there's a problem here. Since we're talking about how the network provides
addresses, then the question is "what's the best current practice for how
to assign a large number of IPv6 addresses to a client in response to an
explicit request for address space". (Recall that the draft recommends
DHCPv6 PD only in the case of for networks that require explicit requests
from the client, not for networks in general.)

For that use case, DHCPv6 PD is not just the best current practice. As far
as I can see, it's the *only* current practice: it is the only protocol we
have today that's seen any sort of use that allows us to do this. The only
other stateful protocol we have is DHCPv6 address assignment, but I think
it's pretty clear that that doesn't scale well. You can't even fit that
many IA_NA options in a 1280-byte sized packet. (Recall that section 7 says
that 32 addresses might not be enough to allow unconstrained development of
future applications.)

If that argument doesn't convince you, then bear in mind that your
statement that "only CPEs do PD, not hosts". For example, Windows has
supported DHCPv6 PD since Vista in 2007 -
https://blogs.technet.microsoft.com/teamdhcp/2007/02/09/dhcpv6-prefix-delegation-in-windows-vista/
.

Given the above, I think it's reasonable to say that DHCPv6 PD is the best
current practice for networks to assign blocks of IPv6 space to devices
that request it.

Of course, in the future operational experience might reveal that DHCPv6 PD
is in fact not the best way to do this, and that something else is actually
better. Personally I think that's really unlikely, because the use case
we're talking about (assign a block of addresses to a client) is really not
so different from how we assign IPv6 blocks to CPE routers or assign IPv4
addresses to hosts, and I really don't see any other suitable protocol on
the horizon. But even if something else comes along that's better, then,
well, that's where the C in BCP comes in. DHCPv6 PD is the *current* best
practice today, but it might not be tomorrow.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Dec 2015 18:42:49 +0000

Hi Lorenzo,

The reason I have a problem with the words “not to its network interface directly but
instead” is that, first, the phrase is unnecessary and, second, it gets in the way of
interface types that can set DupAddrDetectTransmits to zero being able to assign
addresses directly to the network interface. AERO is an example interface type
where this is possible.  Without these unnecessary words, you still get the BCP
recommendation you are after without getting in the way of other works that
need to go forward.

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, December 15, 2015 5:25 PM
To: Erik Kline
Cc: Templin, Fred L; [email-masked]; 神明達哉
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Wed, Dec 16, 2015 at 8:34 AM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
However, both those paragraphs assume the network interface /only/ has
link-local addresses, which need not be true.  I really hate to
perpetuate this bikeshed, but here goes.

That text works for me. Fred, does it work for you? If not, can you explain why it does not work?

If you have a problem with the words "not to its network interface directly but instead", then can you explain why those words are a problem? It seems to me that *any* behaviour that is compliant with RFC 4862 must comply with those words as well, and thus, there should not be a problem including those words unless we want to prescribe/condone behaviour that violates RFC 4862.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Dec 2015 19:10:14 +0000

Hi Philip,

> From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Wednesday, December 16, 2015 4:44 AM
> To: [email-masked]
> Subject: Re: [v6ops] Calling the question: draft-ietf-v6ops-host-addr-availability-03.txt
> 

AERO is exactly about roaming mobile devices providing tethering or a
collection of VMs, etc.

> is just hoping that experience with CPEs translates well to mobile devices.

I have released an initial implementation of AERO that demonstrates
mobility based on DHCPv6 PD and IPv6 ND. Here is the link:

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

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Dec 2015 09:57:05 +0900

On Thu, Dec 17, 2015 at 3:42 AM, Templin, Fred L <[email-masked]>
wrote:

> it gets in the way of interface types that can set DupAddrDetectTransmits
> to zero being able to assign
>
> addresses directly to the network interface.
>

Fair enough. You're saying that if you define your own link layer, you can
specify that DupAddrDetectTransmits defaults to 0, and on such a link
layer, the text I proposed could be seen as unnecessarily restrictive.
Let's take your text and merge it with Erik's, then:

   Also, a DHCPv6 PD model with a dedicated /64 per host makes it
   possible for the host to assign addresses from this prefix to an
   internal interface such as a loopback interface.  This obviates the
   need to perform Neighbour Discovery and Duplicate Address
   Detection on its network interface for these addresses, reducing
   network traffic

Better?

Cheers,
Lorenzo

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Dec 2015 00:37:42 -0600

> recipient of such addresses behaves. Yes?

Yes, I agree.  However, I think the subtly of that distinction is easily 
lost on casual readers of the document.  That is why earlier I was 
trying to suggest you should be more explicit about what is out-of 
scope.  Instead of what I suggested last time, maybe add something like 
the following "It does not specify any changes to protocols or end host 
behavior" to the end of the Introduction;

    This document describes the benefits of providing multiple addresses
    per host and the problems with not doing so.  It recommends that
    networks provide general-purpose end hosts with multiple global
    addresses when they attach, and lists current options for doing so.
    It does not specify any changes to protocols or end host behavior.

I think that reinforces and clarifies the scope by being explicit about 
what is out-of scope.

Also you seem to frequently stray into talking about things from a host 
perspective, instead of clearly a network perspective, this is probably 
confusing this issue a bit.

Generally, hosts "obtain" addresses, networks "provide" addresses, 
"assigning" while correct, might be a little passive, I think 
"providing" more clearly communicating a network perspective.  So, a few 
specific suggestions for combating this host vs. network confusion;

1. Section 1, "Introduction", the last paragraph starts with "This 
document describes the benefits of assigning multiple addresses per 
host..." I think "This document describes the benefits of providing 
multiple addresses per host..." would be more strongly focused on the 
network perspective.

2. Section 3 is is titled "Benefits of multiple addresses". "Benefits of 
providing multiple addresses" is more clearly projects a network 
perspective.

3. Section 4 is is titled "Problems with assigning a restricted number 
of addresses per host", I think "Problems with restricting the number of 
addresses per host" is stronger, but this one is a bit of a coin flip.

4. Section 6 is titled "Options for obtaining more than one address", 
and starts with "Multiple IPv6 addresses can be obtained in...".  This 
is clearly confusing the perspective and should be changed to "Options 
for providing more than one address", and start with "Multiple IPv6 
addresses can be provided in..."

5. Section 9.3 in the middle paragraph; "...However, switching to a 
DHCPv6 PD model with one /64 prefix per host resolves these scaling 
limitations..." And the last paragraph starts with; "Also, a DHCPv6 PD 
model with a dedicated /64 per host makes...". Again these is a little 
passive, how about "... However, switching to a DHCPv6 PD model 
providing one /64 prefix per host resolves these scaling limitations.." 
and "Also, a DHCPv6 PD model providing a dedicated /64 per host 
makes..." is more actively about the network.

....

> https://blogs.technet.microsoft.com/teamdhcp/2007/02/09/dhcpv6-prefix-delegation-in-windows-vista/.
>
> Given the above, I think it's reasonable to say that DHCPv6 PD is the
> best current practice for networks to assign blocks of IPv6 space to
> devices that request it.
>
> Of course, in the future operational experience might reveal that DHCPv6
> PD is in fact not the best way to do this, and that something else is
> actually better. Personally I think that's really unlikely, because the
> use case we're talking about (assign a block of addresses to a client)
> is really not so different from how we assign IPv6 blocks to CPE routers
> or assign IPv4 addresses to hosts, and I really don't see any other
> suitable protocol on the horizon. But even if something else comes along
> that's better, then, well, that's where the C in BCP comes in. DHCPv6 PD
> is the *current* best practice today, but it might not be tomorrow.

Yes, this is all true, but most people still have the impression that 
DHCPv6 PD is primarily intended for configuring routers or CPE and not 
hosts. If you read the introduction RFC 3633, it is easy to see why 
people have that impression.  Even the example you site is related to 
Internet Connection Sharing (ICS) where Windows is basically acting like 
a CPE router. I'm not sure what to do about it though, but it probably 
shouldn't be ignored.

Thanks

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Dec 2015 18:18:30 +0000

Works for me.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, December 16, 2015 4:57 PM
To: Templin, Fred L
Cc: Erik Kline; [email-masked]; 神明達哉
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Thu, Dec 17, 2015 at 3:42 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
it gets in the way of interface types that can set DupAddrDetectTransmits to zero being able to assign
addresses directly to the network interface.

Fair enough. You're saying that if you define your own link layer, you can specify that DupAddrDetectTransmits defaults to 0, and on such a link layer, the text I proposed could be seen as unnecessarily restrictive. Let's take your text and merge it with Erik's, then:

Better?

Cheers,
Lorenzo

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Dec 2015 08:29:48 +1100

On 17 Dec 2015 11:57 AM, "Lorenzo Colitti" <[email-masked]> wrote:
>
> On Thu, Dec 17, 2015 at 3:42 AM, Templin, Fred L <
[email-masked]> wrote:
>>
>> it gets in the way of interface types that can set
DupAddrDetectTransmits to zero being able to assign
> Fair enough. You're saying that if you define your own link layer, you
can specify that DupAddrDetectTransmits defaults to 0, and on such a link
layer, the text I proposed could be seen as unnecessarily restrictive.
>    Detection on its network interface for these addresses, reducing

Perhaps a little extra (somewhere),

", as the host can ensure duplicate addresses do not occur."

---

From: Gert Doering <[email-masked]>
Date: Mon, 21 Dec 2015 15:15:54 +0100

Hi,

> IPv6 CPE router on the planet does it.

Actually, most IPv6 CPEs are fine *receiving* DHCPv6 PD, but claiming
"every IPv6 CPE router.. does it" is just not correct - and, actually, 
not even relevant here as people might not connect their enterprise wifi 
networks to a typical *CPE* device.

So we do not really have experience with "running DHCPv6 PD on the
server side in a non-CPE environment that is not built for client access"
(like, a cable headend or DSL LNS) either.

> really in scope for this draft.

I see this as not really acceptable for a document has such a strong
recommendation (section 8) for DHCPv6 PD.

(In short, I think the whole idea of using DHCPv6 PD for hosts brings
a shitload of problems with it - but if you want to go there, spell it
out so it can actually work)

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: Gert Doering <[email-masked]>
Date: Mon, 21 Dec 2015 15:18:11 +0100

Hi,

> practice today, but it might not be tomorrow.

BC*P* also means "*p*ractice". Nobody is doing this today in the environments
that this draft talks about, so where does "current practice" come from?

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Dec 2015 23:59:32 +0900

> networks to a typical *CPE* device.

Sorry, that was misworded. What I meant is that networks assign IPv6
addresses to every CPE on the planet via DHCPv6 PD. Not that every CPE on
the planet is a DHCPv6 PD server.

> out so it can actually work)

I feel very strongly that we should not do document what hosts need to do
in this document. That is out of scope - what we're saying here is
providing recommendations on how networks should act, not how hosts should
act. If we start talking about hosts in this document, then we will spend a
very long time as quibbling on what is and is not in scope, and how exactly
hosts should behave. Look at how long we spent talking about DAD: that took
three weeks, even though we were basically all in agreement.

Like I said: on networks that require explicit requests for address space,
we simply have no other way to assign anything that's not a handful of
addresses. By definition, on those networks SLAAC is not supported, so all
we have is IA_NA. So that's the B in BCP, though it's not really so much
"Best" as "Only". We could say in the draft that requiring DHCPv6 is not
recommended and that networks should consider SLAAC instead, but that's
bound to cause disagreement, so there's no point attempting that.

We do have plenty of experience with using DHCPv6 PD to assign addresses to
things, and yes, those things include hosts (e.g., Windows, which has
supported DHCPv6 PD for close to a decade). It's true that not all hosts
and networks support this, just like not all networks support DHCPv6 or
SLAAC or whatever else. But some enterprise networks do. Our enterprise
network has places on it that do PD, and as you might expect, the servers
that hand out the prefixes neither know nor care if it's a host or a router
that requested them. And there are DHCPv6 PD implementations for host OSes
such as ISC DHCP and dibbler.

If your concern is that using DHCPv6 PD on a host will cause lots of
problems - what problems are you talking about? From the host perspective
it's simple. You get a prefix. You form a random address from that prefix
and assign it to a loopback. You use the weak host model to use that
address to send packets on your physical interface. You deal with source
address selection as if that address was assigned to the physical
interface. If your network stack is not smart enough to do that, you can
assign the random address to your interface with DAD disabled. You can even
respond to neighbour discovery if you want, but nobody will ever ask. If
you want another address, you do the same again.

Cheers,
Lorenzo

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 17:46:04 +0000

Hi Gert,

> out so it can actually work)

It is spelled "A-E-R-O".

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 17:48:00 +0000

Hi Lorenzo,

Based on these past several messages asking for details on how DHCPv6 PD
“hosts” should behave, I suggest that you add an informative reference to
AERO.

Thanks – Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, December 21, 2015 7:00 AM
To: Gert Doering
Cc: [email-masked] WG; [email-masked]
Subject: Re: [v6ops] Calling the question: draft-ietf-v6ops-host-addr-availability-03.txt

On Mon, Dec 21, 2015 at 11:15 PM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:

Sorry, that was misworded. What I meant is that networks assign IPv6 addresses to every CPE on the planet via DHCPv6 PD. Not that every CPE on the planet is a DHCPv6 PD server.

I feel very strongly that we should not do document what hosts need to do in this document. That is out of scope - what we're saying here is providing recommendations on how networks should act, not how hosts should act. If we start talking about hosts in this document, then we will spend a very long time as quibbling on what is and is not in scope, and how exactly hosts should behave. Look at how long we spent talking about DAD: that took three weeks, even though we were basically all in agreement.

Like I said: on networks that require explicit requests for address space, we simply have no other way to assign anything that's not a handful of addresses. By definition, on those networks SLAAC is not supported, so all we have is IA_NA. So that's the B in BCP, though it's not really so much "Best" as "Only". We could say in the draft that requiring DHCPv6 is not recommended and that networks should consider SLAAC instead, but that's bound to cause disagreement, so there's no point attempting that.

We do have plenty of experience with using DHCPv6 PD to assign addresses to things, and yes, those things include hosts (e.g., Windows, which has supported DHCPv6 PD for close to a decade). It's true that not all hosts and networks support this, just like not all networks support DHCPv6 or SLAAC or whatever else. But some enterprise networks do. Our enterprise network has places on it that do PD, and as you might expect, the servers that hand out the prefixes neither know nor care if it's a host or a router that requested them. And there are DHCPv6 PD implementations for host OSes such as ISC DHCP and dibbler.

If your concern is that using DHCPv6 PD on a host will cause lots of problems - what problems are you talking about? From the host perspective it's simple. You get a prefix. You form a random address from that prefix and assign it to a loopback. You use the weak host model to use that address to send packets on your physical interface. You deal with source address selection as if that address was assigned to the physical interface. If your network stack is not smart enough to do that, you can assign the random address to your interface with DAD disabled. You can even respond to neighbour discovery if you want, but nobody will ever ask. If you want another address, you do the same again.

Cheers,
Lorenzo

---

From: Gert Doering <[email-masked]>
Date: Mon, 21 Dec 2015 19:03:51 +0100

Hi,

> > out so it can actually work)

Yes, we understand.

Like, this is totally working out of the box on all clients that attach
to my wifi, and the extra tunnels will magically not cause circumvention
of wifi firewall policy, etc.

There's enough layers of shit going on here that we are not really 
interested in stacking yet another overlay network on top of it, no matter
how good its marketing might be.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 18:13:14 +0000

Hi Gert,

> From: Gert Doering [mailto:[email-masked]]
> Sent: Monday, December 21, 2015 10:04 AM
> To: Templin, Fred L
> Cc: Gert Doering; Lorenzo Colitti; [email-masked] WG; [email-masked]

No; not "another" overlay. Speaking from the OpenVPN model, it is one and
the same overlay that OpenVPN introduces. The AERO functions (DHCPv6
PD, IPv6 ND, router discovery, etc.) could be incorporated into the existing
OpenVPN tunnel - not set up as an additional layer of encapsulation layer.

Looking at it another way, the existing OpenVPN model is uni-addressing
using the standard IPv6 "subnet" model - i.e., tunneling makes it look as if
each host is attached to a shared IPv6 link and gets an address assignment
from the IPv6 prefix assigned to that link. AERO is offering a different model
that could be adopted by OpenVPN as an alternate mode of operation. In
this mode, the "link" is link-local-only, and DHCPv6 PD delivers prefixes to
the client over the link.

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Mon, 21 Dec 2015 19:34:41 +0100

Hi,

> OpenVPN tunnel - not set up as an additional layer of encapsulation layer.

OpenVPN (and VPN in general) is totally not what *this* is talking about
"attach to a network and get more than one address *from the network you
are attaching to*".

VPN (and, generalized, tunnels) is about "attach to some other network 
to get addresses from that *remote* network" (and/or "get access to some
resource that would not be accessible directly").

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 19:35:01 +0000

Hi Gert,

> Sent: Monday, December 21, 2015 10:35 AM
> To: Templin, Fred L

The AERO client is exactly a VPN client, only using a different subnet model.
Extending VPN systems to accommodate this alternate subnet model gives
a secure, mobile and multi-addressing client. The addition  being that the
VPN server also acts as a DHCPv6 server and the VPN client also acts as a
DHCPv6 client. I should think you would like that?

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Mon, 21 Dec 2015 21:07:54 +0100

>act. 

Maybe should you take it one step further and cut out all text on how to 
assign multiple addresses.

For me there is no doubt that networks should provide hosts with 
multiple addresses. That is clearly BCP.

>"Best" as "Only". 

So, we don't know. It might work. Nobody seems to have any experience.
So cut the speculation and say that we don't know.

(Alternatively, reclassify and informational and the current text is fine)

>such as ISC DHCP and dibbler.

If people have been doing PD for Windows hosts for close to a decade,
find somebody who has that kind of experience and describe how it
works in practice. (Maybe in an informational draft)

>it's simple. You get a prefix. 

I described it earlier:
- A host gets a prefix from DHCPv6 relay. The relay reboots, does the
  relay have a persistent store of the PD leases or is the host expected
  to poll?

  As far as I know, there is no text in RFC 3633 that requires persistent state
  in a DHCPv6 relay. Maybe I missed something. 

  If the host is expect to poll, how does that work. You mention Windows,
  how do they deal with this problem.

- And to spice it up, how do redundant routers, acting as DHCPv6 relays and
  one of them is shutdown. Again is this something the network has
  to handle, or is this the resposibility of the host. It is just not
  documented. If PD for hosts is used in practice, then somebody must have
  dealt with this problem.

I don't see how this is 'simple'.

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Dec 2015 09:48:02 +1100

On 22 December 2015 at 07:07, Philip Homburg <[email-masked]> wrote:

<snip>
>   how do they deal with this problem.

How do CPE using DHCPv6-PD deal with this problem (because they do)?

>   documented. If PD for hosts is used in practice, then somebody must have

How do CPE using DHCPv6-PD deal with this problem (because they do)?

I think you and others might be making this problem harder than it is.
These "hosts" using DHCPv6-PD are really no more than routers that are
only forwarding packets they originate from an internal interface,
such as NTP, DNS or SIP for a POTS port.

RFC6204 ("Basic Requirements for IPv6 Customer Edge Routers") from
2011 described how the CPE was to use some of its delegated space to
for its own purposes, assigned to an internal virtual network:

WAA-8:  If the IPv6 CE router does not acquire global IPv6
           address(es) from either SLAAC or DHCPv6, then it MUST create
           global IPv6 address(es) from its delegated prefix(es) and
           configure those on one of its internal virtual network
           interfaces.

So take that spec, disconnect the LAN interface, and you have a "host"
using DHCPv6-PD that is only sending and receiving traffic for its own
locally running applications.

The only gap I can see is in the multicast domain because ISPs don't
provide multicast routing services to routers that aren't running a
fully fledged multicast routing protocol. So if we want to solve that
without requiring the <strike>CPE</strike>hosts to run PIM, we either
need to send MLD messages for the internal network group membership on
the <strike>WAN</strike>physical LAN interface of the
<strike>CPE</strike> host, or have a mechanism in DHCPv6 performs the
equivalent multicast function.

I agree that detail like that probably shouldn't be in this draft,
however I don't think this is such an unknown and un-understood
scenario that mentioning DHCPv6-PD as a possible method to facilitate
it is a problem.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Dec 2015 00:25:19 +0100

>How do CPE using DHCPv6-PD deal with this problem (because they do)?

In some cases it is easy. For example, with ppp(oe), any reboot of the
router will trigger a link failure and then after the link is up again
an DHCP rebind.

No idea how it works for ethernet-like links.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Dec 2015 08:27:52 +0900

> multiple addresses. That is clearly BCP.

I don't think that would work. How can we have a BCP that say "networks
should provide more than 32 addresses" without specifying how to do that?
Are you expecting the readers to figure out for themselves that this means
"use SLAAC or DHCPv6 PD, but not DHCPv6 NA"? Even if that is the conclusion
they come to, won't they ask themselves why that isn't in the document?

>   relay have a persistent store of the PD leases or is the host expected

That question is not specific to DHCPv6 PD or even to DHCPv6. It is a
general question about DHCP.

Remove "PD" from the sentence and replace "prefix" with "address" and you
have a question about DHCPv6 address assignment. Or even, for extra fun,
replace "DHCPv6" with "DHCP" and now you have a question about DHCPv4.

Because the question applies equally well to DHCPv6 address assignment and
DHCPv6 PD, it is out of scope for a document whose only recommendation
about DHCPv6 is "if you are using DHCPv6, use it to provide prefixes, not
addresses".

> I don't see how this is 'simple'.

Again, that problem applies just as well to DHCPv6 address assignment as
DHCPv6 PD.

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Dec 2015 10:46:44 +1100

> router will trigger a link failure and then after the link is up again

So on PPPoE links, as there is (usually) no direct physical link
between the CPE and the BRAS/BNG, they both monitor each others'
presence using LCP Echo Requests/Replies i.e., keep alives, with
intervals that are usually measured in seconds e.g., 10 through 60.

> No idea how it works for ethernet-like links.

I don't have experience in this area, although being close to it, I
was aware that they were doing something to monitor liveness, and I
would have guessed ARP or NUD because they can't be firewalled without
things completely stopping working. Some searching has turned up this
Broadband Forum Technical Report, which says Ethernet OAM, ARP, NUD or
BFD are methods.

"TR-146 Subscriber Sessions"
https://www.broadband-forum.org/technical/download/TR-146.pdf

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Dec 2015 13:00:26 +0100

>https://www.broadband-forum.org/technical/download/TR-146.pdf

It would be nice if we actually had RFCs for this stuff.

But the using BFD (see Section 6.2.2) looks like an interesting approach.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Dec 2015 16:38:03 +0100

>they come to, won't they ask themselves why that isn't in the document?

Given that we never actually defined how DHCPv6 PD for hosts is supposed
to work, let alone have any experience, readers will have to figure that out
for themselves anyhow.

In some sense, the broadband forum TR-146 provides a nice gap analysis.

>replace "DHCPv6" with "DHCP" and now you have a question about DHCPv4.

Not at all. In DHCPv4, you only have dynamic state at the DHCPv4 server
if you dynamically allocate addresses. And the only goal of the dynamic
state is to avoid handing out the same address twice. In addition, DHCPv4
relays have no state.

In contrast, in general a DHCPv6 PD delegating router has to have 
dynamic state even if the prefix allocation is static (on a multi-access
link you need to know the link local address of the recipient). In 
addition the role in DHCP may be that of a relay. And in the case of
multiple relays you would have to synchronise the state between relays
(for which we don't have any protocol at the moment).

So from my point of view, this is completely different.

Note that the broadband forum requires (for PD) the client to refresh the
state.  So their model is completely different from the traditional DHCP
where the DHCP server has to keep track of leases.

So that's a first high level choice we haven't made yet: is the network
responsible for PD leases and associated state, or does the client have
to refresh the lease when something seems broken (but the lease is otherwise
not expired).

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Dec 2015 16:43:28 +0100

Hi,

> How do CPE using DHCPv6-PD deal with this problem (because they do)?

For PPP based developments, this is fairly easy - if the upstream router
(which has to be relay or server, given that PPP is a point-to-point link) 
dies, their PPP session dies, and on re-establishment of the PPP session,
everything is refreshed.

I have no idea how this is done in cable or "plain IP over ethernet" style
attachments.  Maybe short lease times, or "the headend is only ever
rebooted in maintenance windows"?

> How do CPE using DHCPv6-PD deal with this problem (because they do)?

Not really.

Can you back the "because they do" statement by a description *how* it 
is done?  That would certainly help those here that have no idea how
to do it, like, me.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Tue, 22 Dec 2015 17:57:08 +0100

Hi,

> Op 22 dec. 2015, om 16:43 heeft Gert Doering <[email-masked]> het volgende geschreven:
> 
> Hi,
> 

The way we do it is:
- two routers at the ISP side, both sending RAs
- the CPE decides which gateway to use based on RA priority and NUD (might switch to HSRP/VRRP/etc for unpredictable CPEs)
- both routers are DHCPv6 relays listening on multicast
- so the DHCPv6 server gets every client request twice: once through each relay
- the DHCPv6 server replies through both relays so both can update their routing table
- store the DHCPv6 database on persistent storage in the router for faster recovery after reboot
- redistribute the prefix-to-CPE routes between the routers so if one loses the route the traffic can go through the other router
- a router that lost the route will get it at the next DHCPv6 bind/renew/rebind (which is unrelated to lease time as DHCPv6 replies can explicitly specify renew/rebind timers)

And in the ethernet stuff between our router and the CPE you probably want switches that can do DHCPv6 snooping and enforcement. And/or a router that can match the source MAC address of packets sent by a CPE against the DHCPv6-PD and ND tables to make sure that customers don't spoof each others prefixes/addresses. These last bits aren't easy to solve with current equipment.

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 23 Dec 2015 01:59:02 +0900

On Wed, Dec 23, 2015 at 12:38 AM, Philip Homburg <[email-masked]

> to work, let alone have any experience, readers will have to figure that

Have we defined how it's supposed to work for routers? If so, why can't we
just say that it will work in the same way for hosts? The reason I ask is
that if you go and look at the RFCs I think you'll find that this is much
less specified than you seem to think it is.

> (for which we don't have any protocol at the moment).

Can you find where all that is documented in an RFC? It's certainly not
specified in RFC 3633. If not, why do we need to document it here?

I think your "in general, X has to be Y" statement is based on a large
number of assumptions about the use case that you may not even be aware of.
Here are some assumptions that you are making that are not at all required
by RFC 3633:

   - That relays route general data traffic and not just DHCPv6 requests.
   - That DHCPv6 relays snoop packets, keep state, and inject routing.
   - That if there is more than one relay, that exactly one (as opposed to
   none, or more than one) will snoop the reply, and that only that one is
   going to be the only router to send traffic to the delegated prefix.
   - That the clients are always connected via multi-access links and not
   point-to-point.
   - ...

You're also assuming that DHCPv6 address assignment always uses
directly-connected shared subnets which implicitly provides the routing
information you say is lacking in DHCPv6 PD. But that might not be the case
- it's certainly not required by the protocol.. For example clients could
get random unaggregated /128s on point-to-point interfaces, where there is
no implicit routing. And so on.

So I think you're narrowly focusing on the way you think DHCPv6 PD should
work and assuming that that is what the standards say, but it's not. The
RFCs only define the protocol. I don't think they even talk about reply
snooping, which I think you're not just assuming but taking for granted.

> to refresh the lease when something seems broken (but the lease is

That's a client behaviour decision, which should be out of scope of this
document. We have to draw the line somewhere, and this draft is about the
behaviour of networks, not of clients.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 23 Dec 2015 02:02:26 +0900

What Sander said.

Before someone says that this should be documented somewhere. I agree, it
should. But not in this document :-)

On Wed, Dec 23, 2015 at 1:57 AM, Sander Steffann <[email-masked]> wrote:

> - the CPE decides which gateway to use based on RA priority and NUD (might
> switch to HSRP/VRRP/etc for unpredictable CPEs)
> - redistribute the prefix-to-CPE routes between the routers so if one
> loses the route the traffic can go through the other router
> - a router that lost the route will get it at the next DHCPv6
> bind/renew/rebind (which is unrelated to lease time as DHCPv6 replies can
> explicitly specify renew/rebind timers)
>
> And in the ethernet stuff between our router and the CPE you probably want
> switches that can do DHCPv6 snooping and enforcement. And/or a router that
> can match the source MAC address of packets sent by a CPE against the
> DHCPv6-PD and ND tables to make sure that customers don't spoof each others
> prefixes/addresses. These last bits aren't easy to solve with current
> equipment.
>
> Cheers,
> Sander
>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 22 Dec 2015 18:05:07 +0100

> What Sander said.
> 
> Before someone says that this should be documented somewhere. I agree, it should. But not in this document :-)

Oh damn. /me waits to be volunteered by someone for writing that document...

Cheers :)
Sander

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Dec 2015 18:05:34 +0100

Hi,

> > rebooted in maintenance windows"?

Thanks, this was useful.

> - store the DHCPv6 database on persistent storage in the router for faster recovery after reboot

This is not something every gear can do today...

> - redistribute the prefix-to-CPE routes between the routers so if one loses the route the traffic can go through the other router

... and this is important to implement (like, using iBGP and keeping the
next-hop in place - though this might pose interesting challenges for
link-local next-hops if router B doesn't know that this is the same 
network router A is talking about).

[..]
> And in the ethernet stuff between our router and the CPE you
> probably want switches that can do DHCPv6 snooping and enforcement.
> And/or a router that can match the source MAC address of packets
> sent by a CPE against the DHCPv6-PD and ND tables to make sure that
> customers don't spoof each others prefixes/addresses. These last
> bits aren't easy to solve with current equipment.

Indeed... "classic" uRPF fails that ("it's going out via that interface, 
good!")...

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Tue, 22 Dec 2015 18:10:46 +0100

Hi,

> network router A is talking about).

In our case the traffic is just routed to the second router. We use link-local next hops, and sending those over IGP or EGP would get interesting... Slightly less efficient routing is accepted when the persistent storage doesn't contain the route until the next DHCPv6 renew is done by the CPE. IIRC we currently let the CPEs renew every hour, so the bit less efficient routing is limited to max 1 hour.

Cheers,
Sander

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Dec 2015 22:08:11 +0000

Hi Philip,

> Sent: Monday, December 21, 2015 12:08 PM
> To: [email-masked]
> Cc: [email-masked]

I thought I had already answered this, but for AERO there may be many routers on
the link. The client discovers the unicast addresses of routers via a name service
lookup and maps the multicast group "All_DHCP_Relay_Agents_and_Servers"
to the unicast addresses discovered in the name service. By this, I mean that 
through encapsulation the inner destination address is multicast and the outer
destination address is the unicast address of a router.

The client then does a DHCPv6 PD Solicit/Request through each router it wants to
associate with. Each router in turn configures both a DHCPv6 Relay (via RFC6221
Lightweight DHCPv6 Relay Agent) and a DHCPv6 Server. When the client requests
a DHCPv6 Prefix Delegation, it will get the *same* prefix(es) from all routers it
associates with. Meaning that all routers have access to the same database of
prefix-to-client mappings, and all routers will provide an identical service.

When one or more routers go down, the network will notice this and withdraw
the prefixes they are advertising from the routing system. The client will also
notice that the router has gone down and associate with a different router
or routers. The routing system will then direct traffic destined to the client
via one of the new routers.

This works fine even if the client is mobile and continuously moving from
access network to access network. And, the client gets the same prefix(es)
every time it attaches to the network so there is no renumbering. But,
most importantly, it gets the same service from whichever router(s)
it chooses to associate with, so it can even move from router to router
if needs be to reduce path stretch.

This is all in the AERO spec. I think an informative reference in this document
would be in order.

Thanks - Fred