Subject: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 18:13:50 -0300

Folks,

These past few days I ended up reviewing the aforementioned document, as
a result of a thread on this document on the v6ops mailing-list.

I had reviewed an early version of the document, in which the benefits
of not having and on-link prefix were discussed -- which was certainly
fine (and I supported).

While reviewing this document a few days ago, I found that Section 4
(page 5) contains what is a protocol spec, rather than an operational
BCP. It contains rules regarding how to set the link-layer address (to a
unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
now remember which prefix has been "leased" to which node -- something
that seems to be way outside of the v6ops charter, and that should have
been done in 6man, instead.

Looking at diffs, it seems this additional text was incorporated very
recently, in version -09 of the I-D, published in mid September
(<https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt>).
It seems to be that this change is way beyond what the authors
originally proposed
(a bcp saying that it's great to give each host a unique prefix, without
providing details on specific mechanisms or doing protocol specs --
which was obviously within v6ops' charter), and what the wg shipped, and
also seems to be in conflict of the v6ops and 6man charters (v6ops
doesn't do protocol specs, but this document certainly contains one).

Besides what seems to be a conflict in the aforementioned charter, there
are a number of issues associated with the specified protocol:

1) The protocol spec specified in this document requires the SLAAC
router to keep state of the "leased" prefixes -- what seems a major
change to SLAAC, which now would be kind of as stateful as DHCPv6.

2) There are scenarios in which multiple nodes might receive the same
packet -- say a NIC let's the packet through because it is in
promiscuous mode -- wich could possibly lead to two nodes configuring
the same prefix.

3) What happens if the SLAAC router crashes and reboots, loosing state
of the "leased" prefixes?

4) How are prefixes selected? And, what's the minimum size of the pool
of prefixes for the selection algorithm not to break due two "prefix
collisions"? Does the selection algorithm have any specific properties?

In summary, revision -09 (most likely done to address some DISCUSS)
turned the original BCP document into a protocol spec, with a major
change to SLAAC, which should have happened in 6man, rather than in
v6ops (which is not allowed to do protocol specs). Looking at the
current document (to be published), Section 4 (page 5) looks more like a
Std Track document than a BCP.

It was suggested to me that I discuss this on the mailing-list... hence
this post.

Thoughts?

P.S.: I wished I had caught this earlier. I just didn't.

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

---

From: DY Kim <[email-masked]>
Date: Thu, 9 Nov 2017 09:16:12 +0900

Hi Fernando,

If I’m not wrong, SLAAC in this document is one supposed to run on hosts not on the router…

---
DY

> On 7 Nov 2017, at 06:13, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Nov 2017 11:58:12 +0900

> been done in 6man, instead.

I don't see how this is a protocol change. Sending RAs unicast is already
allowed by RFC 4861, so this is just an operational practice.

> It seems to be that this change is way beyond what the authors

The additional text did not actually change this practice at all. It simply
clarified what has always been a fundamental premise of this operational
practice: if you want to give each host its own prefix, you need to ensure
that the RA with that prefix is only received by that host.

> change to SLAAC, which now would be kind of as stateful as DHCPv6.

This is a bizarre claim. The first-hop router must always have fully
up-to-date state on all the prefixes it is sending RAs for, otherwise it
cannot fulfill its fundamental purpose of forwarding traffic to those
prefixes. The word "stateless" in SLAAC applies to addresses configured to
the host, not how routers route traffic.

> promiscuous mode -- wich could possibly lead to two nodes configuring

Why do you say promiscuous mode is a problem? Even in promiscuous mode,
network stacks already understand which packets are being send to the host
network stack and which are not. For example, in the linux networking
stack, well before the packet ever gets to the ICMPv6 protocol handlers
that would process incoming RAs, ipv6_rcv does:

if (skb->pkt_type == PACKET_OTHERHOST) {
kfree_skb(skb);
return NET_RX_DROP;
}

> of the "leased" prefixes?

You seem to be assuming that the router does not store the prefixes in
stable storage. It's certainly the case that if you want this scheme to
work across router crashes, then you need to ensure that the prefixes are
stored somewhere. That sort of seems self-evident, but we could add it to
the text.

> collisions"? Does the selection algorithm have any specific properties?

I see no reason why this should be in scope for this document.

---

From: Erik Kline <[email-masked]>
Date: Thu, 9 Nov 2017 12:02:46 +0900

I don't think we should be recommending unique RAs per device where
the devices are all on a shared link.

My understanding was that in the original motivating wifi deployment
every node is effectively isolated in its own (pseudo)VLAN, and
node-to-node traffic must be routed through the infrastructure (to the
extent such a thing can actually be enforced in a medium like wifi).

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Nov 2017 05:05:23 -0300

> the devices are all on a shared link.

Agreed.

And if we were to do it, we should be recommending this in a 6man
document, not v6ops.

> extent such a thing can actually be enforced in a medium like wifi).

Describing the virtues of one prefix per node, or how isolating nodes
(no "on link prefix") or the like are all fine for an informational
document, or even as a BCP (if that's how the wg feels).

Specifying hacks to SLAAC which require modification to the SLAAC router
code (you certainly need to hack e.g. radvd quite a lot to implement
this) or add additional requirements to SLAAC (like the requirement of a
data structure that contains mappings of Prefix_leased -> MAC_address)
is std track work that should be done in 6man, and with a document
flagged as "std track", not bcp.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Nov 2017 14:48:55 -0300

On 11/08/2017 11:58 PM, Lorenzo Colitti wrote:
> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I don't see how this is a protocol change. Sending RAs unicast is
> already allowed by RFC 4861, so this is just an operational practice.

That's incorrect. We are talking about sending multicasted internetlayer
packets to a unicast link-layer address. There's nothing in RFC4861 that
suggests you should do that. RFC6085 says "you shouldn't drop packets if
they are internet-layer multicast but link-layer unicast". But
certainly, unless a protocol spec says otherwise, the normal mapping
applies.

There's nothing in RFC4862 that may suggest "leasing one prefix per
node". In fact, all nodes share all the prefixes being announced. And
when you don't want multiple nodes to share them, you just segment the
network one way or another. From the point of view of SLAAC, there's no
"one prefix per node". If it happens, it's because you segmented the
network, not because SLAAC is meant for that.

>     (<https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt
>     <https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt>>).
> The additional text did not actually change this practice at all.> It
> simply clarified what has always been a fundamental premise of this
> operational practice: if you want to give each host its own prefix, you
> need to ensure that the RA with that prefix is only received by that host.

If you want to give each host it's own prefix, you do prefix delegation.
So far, SLAAC doesn't do prefix delegation. If you want to do prefix
delegation in slaac, write a std track document in 6man, not a BCP in
v6ops.

> prefixes. The word "stateless" in SLAAC applies to addresses configured
> to the host, not how routers route traffic.

A SLAAC router need not maintain any sort of dynamic mapping. It's
static configuration information of the sort "I'm announcing this prefix
on this interface".. If you think otherwise, please point me the section
in RFC4862 where this conceptual data structure is mentioned. (Note:
Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).

> network stacks already understand which packets are being send to the
> host network stack and which are not. For example, in the linux
> networking stack, well before the packet ever gets to the ICMPv6
> protocol handlers that would process incoming RAs, ipv6_rcv does:
> 

Great that Linux double-checks this. But it need not. Linux is just one
implementation. A very popular one. But one implementation.

> stable storage.

Routers store configuration info, not dynamic mappings.

Simple scenario:

With slaac, the network is 100% resilient if a rotuer crashes and
reboots (because, as the name implies, it is stateless). With this
protocol you are specifying in this document, if the router crashes and
reboots, the network may just break -- same prefix may be reassigned to
different nodes, etc.

> It's certainly the case that if you want this scheme to
> work across router crashes, then you need to ensure that the prefixes
> are stored somewhere. That sort of seems self-evident, but we could add
> it to the text.

SLAAC stores *configuration information*. This protocol that you are
specifying requires SLAAC to store the *dynamic mappings* of which
prefix was "leased" to which host. And the fact that you need this for
this mechanism to work is an indication that you are specifying a
protocol. (Call it Stateful SLAAC, or AAC ;-) )

An operational practice is when you fiddle with the knobs that a
protocol gives you. Here you are introducing a state machine into SLAAC.
That's certainly not an operational practice, but rather a fundamental
change to SLAAC that makes it a stateful protocol

> I see no reason why this should be in scope for this document.

Actually, what's not in the scope of this document, and not within v6ops
charter, is the protocol you are specifying to handle prefixes with SLAAC.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Nov 2017 18:19:33 +0000

> certainly, unless a protocol spec says otherwise, the normal mapping

On this point, I agree with Fernando. RFC4861 says that RAs can be unicast but
that means unicast at both L2 and L3 (i.e., and not multicasted at L3). RFC5214
is an example of where both L2/L3 unicast are used in RAs in the spirit of RFC4861 .

Is there some reason why the requirements of this draft cannot be satisfied
by L3 unicast?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2017 08:42:00 +1300

On 10/11/2017 06:48, Fernando Gont wrote:
> packets to a unicast link-layer address. 

No. It's more subtle than that. We are talking about sending packets with
a LL multicast destination address to a unicast LL address. The packets
are not in fact multicasted, although the recipient will in fact receive
them on a multicast socket.

Again I ask, so what? It may be different from what we thought of in 1998,
but I simply don't see why it's problematic.

> There's nothing in RFC4861 that

Actually RFC6085 also says: " This document
   extends this mapping to explicitly allow for a mapping of an IPv6
   packet with a multicast destination address into an Ethernet link-
   layer unicast address, when it is clear that only one address is
   relevant."

That seems to apply perfectly here.
 
> node". 

No. That is the operational innovation in the present draft.

> In fact, all nodes share all the prefixes being announced. 

All nodes that receive the announcement share it. In this operational
mode, only one node receives it. Again, what's the problem?

> And

Yes, effectively this draft does segment the LAN from a logical
viewpoint. Why is that a problem?

> delegation in slaac, write a std track document in 6man, not a BCP in

That would be a more complicated way of getting the same result.
 
> Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).

Sure. The implementation will need a data structure per host, not per
interface. Any way of handing out prefixes needs that. Why should I care?

> Routers store configuration info, not dynamic mappings.

I think that depends on the router. Configs are not static in the general
case anyway.

> change to SLAAC that makes it a stateful protocol

It's not in SLAAC. It's almost certainly a layer above SLAAC.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2017 09:36:13 +1300

On 10/11/2017 07:19, Templin, Fred L wrote:
> that means unicast at both L2 and L3 (i.e., and not multicasted at L3). 

Who says that? As Fernando reminded us, RFC6085 says otherwise.

> RFC5214

Hosts listen for L3 multicast RAs.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Nov 2017 08:13:58 +1100

> certainly, unless a protocol spec says otherwise, the normal mapping

On this point, I agree with Fernando. RFC4861 says that RAs can be unicast
but
that means unicast at both L2 and L3 (i.e., and not multicasted at L3).
RFC5214
is an example of where both L2/L3 unicast are used in RAs in the spirit of
RFC4861 .

I think it would be better to do it that way and suggested it because of
the principle of least suprise. Ole said that for an implementation he
works on, it is easier to do link layer unicast of multicast RAs rather
than RA unicast (perhaps because the implementation isn't performing NUD
and therefore isn't performing discovery of IPv6 neighbours, so knowledge
of their Link-Local addresses isn't available).

I'm comfortable with both options (as a contributor to RFC6085), although I
think unicast RAs should be the recommendation.

(I've thought there can also be security benefits of link-layer unicasting
for IPv6 multicasts when possible.

"MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6"

https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt

)

Regards,
Mark.

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Nov 2017 15:01:25 -0800

> Hosts listen for L3 multicast RAs.

My answer to Fernando’s concern about this late addition to section 4 possibly moving this draft into the ambit of 6MAN. I don’t think it does.

Here’s why. I don’t see the intent of RFC 6085 as to change the operational semantics of IPv6 multicast in the way that this draft sees it. When an IPv6 forwarding node sends a multicast packet with an Ethernet unicast address because the router knows that its group membership on the link comprises exactly one node… however, the RECEIVING node cannot be expected to share that knowledge. Therefore, when a host receives a multicast RA message in a unicast Ethernet frame, it cannot be expected to recognize that as a signal to indicate there are no other hosts on the link. Fortunately, this draft doesn’t violate that assumption of the protocol. The last paragraph of section 4 goes to this point:

   After the subscriber received the RA, and the associated flags, it
   will assign itself a 128 bit IPv6 address using SLAAC.  Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.  The
   subscriber will for that purpose, perform Duplicate Address Detection
   algorithm.  This will occur for each address the UE attempts to
   utilize on the shared provider managed network.

If the unicast address on the multicast RA message were to signal that the subscriber really is the only member of the all-hosts group on the link, then it would not be necessary for the host to perform Duplicate Address Detection (DAD), now would it? Of course, it has to perform DAD— how could it not do that? Imagine all the things that could break if it didn’t.

Not mentioned in this draft (more is the pity) is that the provider router may send ND Redirect messages with a Target Address not in use by the subscriber host but still having the per-host unique prefix. Of course, in this scenario, the subscriber host cannot know that the prefix advertised in the RA message is a per-host unique prefix, so of course it’s then expected to process any ND Redirect messages it receives, and to update its Destination Cache according to RFC 4861 How could it not do that? Imagine all the things that could break if it didn’t. (I can imagine quite a lot, actually— I’m thinking of applications for this even now.)

I was critical of this draft in V6OPS because I thought it didn’t make all of this sufficiently clear to the reader, but it was all pointed out to me on the list in subsequent discussions, and I seemed to be out of the rough consensus that it was necessary to clarify any of this stuff in the text, i.e. the fact that I initially misunderstood how this BCP is not actually a protocol specification should be no reason to believe that any ordinary reader might make the same mistake. Accordingly, because all of the protocol requirements about DAD and ND Redirect still hold despite all the diversionary text in the introduction about link-layer isolation, I’ve dropped my procedural objections to this draft.

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

---

From: DY Kim <[email-masked]>
Date: Fri, 10 Nov 2017 09:25:01 +0900

Curious.

What does LL here stand for, link-layer or link-local?

---
DY

> On 10 Nov 2017, at 04:42, Brian E Carpenter <[email-masked]> wrote:
> 
> We are talking about sending packets with
> a LL multicast destination address to a unicast LL address.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Nov 2017 09:35:10 +0900

> certainly, unless a protocol spec says otherwise, the normal mapping

The intent of 6085 is clearly to allow this. The introduction says that the
purpose of the document is to allows mapping a multicast group to a
link-layer address "when it is clear that only one address is relevant".

> delegation in slaac, write a std track document in 6man, not a BCP in

That statement does not match reality. All IPv6-capable phones (well over
100 million at this point) have a /64 prefix that is dedicated to them by
the network, and the mechanisms used for that are RAs and SLAAC. See RFC
6459.

> Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).
:
In many cases that's not correct. Consider DHCPv6 PD, which you cite as an
example above. IIRC there is nothing in any RFC that says that the
first-hop router of a requesting router needs to maintain a mapping between
delegating prefix and requesting router, but that mapping is 100% required
for DHCPv6 PD to work.

> Routers store configuration info, not dynamic mappings.

Again, see the DHCPv6 PD example above.

> charter, is the protocol you are specifying to handle prefixes with SLAAC.

Protocols are out of the v6ops charter, and that's fine because there is no
protocol in this document. :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2017 14:20:08 +1300

> What does LL here stand for, link-layer or link-local?

I was thinking "link-layer", but I'm sorry about the ambiguity.

   Brian

> .

---

From: Dae Young Kim <[email-masked]>
Date: Fri, 10 Nov 2017 10:22:16 +0900

For this usual ambiguity, I thought like, use

   L2 for link-layer
   LL for link-local

… :-)

——
DY

> On 10 Nov 2017, at 10:20 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2017 06:48:25 +0530

> On Nov 9, 2017, at 8:28 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> I don't see how this is a protocol change. Sending RAs unicast is already allowed by RFC 4861, so this is just an operational practice.

I understand the concern to be sending to a multicast address at the network layer and a unicast address at the link layer. If 4861 allows the RA to be sent unicast, it is probably unicast at both layers. I suspect that if we change to doing what 4861 describes we'll be fine.

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2017 09:42:31 +0530

---

From: Joe Touch <[email-masked]>
Date: Thu, 9 Nov 2017 20:35:15 -0800

On 11/9/2017 3:01 PM, james woodyatt wrote:
> i.e. the fact that I initially misunderstood how this BCP is not
> actually a protocol specification should be no reason to believe that
> any ordinary reader might make the same mistake. 

Given the time it has taken the discussion to come around to this claim,
it seems prudent to add text to the document to explain this reasoning.

Joe

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Nov 2017 13:45:14 +0900

On Fri, Nov 10, 2017 at 10:18 AM, Fred Baker <[email-masked]>
wrote:

> I understand the concern to be sending to a multicast address at the
> network layer and a unicast address at the link layer. If 4861 allows the
> RA to be sent unicast, it is probably unicast at both layers. I suspect
> that if we change to doing what 4861 describes we'll be fine.
>

That's already allowed by RFC 6085, which states:

   "Transmission of IPv6 Packets over Ethernet Networks" ([RFC2464],
   Section 7) specifies how an IPv6 packet with a multicast destination
   address is mapped into an Ethernet link-layer address.  This document
   extends this mapping to explicitly allow for a mapping of an IPv6
   packet with a multicast destination address into an Ethernet link-
   layer unicast address, when it is clear that only one address is
   relevant.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Nov 2017 13:57:28 +0800

> document, or even as a BCP (if that's how the wg feels).

there is an available recourse to an onlink prefix in form of the
link-local address for a deligated prefix.

   Or, optionally in some cases, a
   solicited RA response could be sent unicast to the link-local address
   of the subscriber as detailed in RFC4861

https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#section-4

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Nov 2017 23:35:21 -0300

Hi, Brian,

Please let me top-post to try to focus the discussion here:

1) My comment to the list was essentially arguing that this document
contains a protocol specification, and such part is not suitable. I
think it should be easy to converge on something regarding this one:

Can anyone (you, for instance), provide a definition of what is a
protocol, and the run this document through such definition and figure
out if it fits or it doesn't?

It would seem to me that many folks seems to be assuming that the only
thing that can be said to be a "protocol spec" is something that
specifies a new packet format -- a definition with which I disagree.

2) The rest of the conversation has been about details (or lack of) of
what I believe is the protocol being specified in this document. Such
discussion can be interesting. But I believe at this point the item to
be discussed is #1 above.

Thanks,
Fernando

On 11/09/2017 04:42 PM, Brian E Carpenter wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Nov 2017 17:23:29 -0300

Hi, Fred,

> I understand the concern to be sending to a multicast address at the network layer and a unicast address at the link layer. If 4861 allows the RA to be sent unicast, it is probably unicast at both…

At which point you realize that know you have to no implement the
graituous  all-nodes RAs, and it becomes evident that you are changing
the spec.

THe main issue is not this but, as the subject implies, this document
making SLAAC stateful.

But, anyway, it should be easy to have all of us converge on something:
the whole discussion boils down to whether this is or is not a protocol
spec.

So, my request would be. For folks arguing that this document is not a
protocol spec, could you please provide a definition of what a protocol
is, and subsequently explain why/how such definition does not encompass
this document?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Nov 2017 17:34:59 -0300

>> On 11/09/2017 12:02 AM, Erik Kline wrote:
[....]
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#section-4

Fine with that. Then one would need to specify that a different prefix
should be announced to each node (based on the source addr of the RS?).
And also specify when you stop doing that. Or when you consider that
such prefix is no longer in use. And what you do if you run out of
available/free prefixes.

Isn't that a protocol? I wonder how folks define what a protocol is...

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Sat, 11 Nov 2017 04:42:31 +0800

> out if it fits or it doesn't?

A protocol is a system of rules that allow _two_ or more nodes to communicate.
The protocol specifies the syntax, semantics and so on (1).

A protocol specification does not specify only the wire format.

'unique-ipv6-prefix' does not specify changes in the wire-format, nor its semantics.
It only requires implementation change on one 'side' of the protocol, namely on the routers.
From that perspective I think you can argue that this is not a protocol specification.

I think you also make a point that there are further considerations here, than just the wire-format. Especially around additional state in the routers. In the early days of IPv6 design a lot of time and effort was made in avoiding state in the network. If this mechanism made address allocation inherently less robust, I think a case could be made for why the IETF should specify this in more detail.
I am not convinced of that though. (In my implementation per host prefix adds configured state, but dramatically lessens dynamic state (ND)).

Interesting question.

Cheers,
Ole

PS: This draft also raises some interesting IETF process issues around change control, oversight and how involved the working group should be in changes happening after the document is handed over to the IESG.

1:Freely borrowed from wikipedia.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Nov 2017 18:04:39 -0300

On 11/10/2017 05:42 PM, Ole Troan wrote:
>> 1) My comment to the list was essentially arguing that this
>> document contains a protocol specification, and such part is not
>> suitable. I think it should be easy to converge on something
>> regarding this one:
>> 
>> protocol, and the run this document through such definition and
>> figure out if it fits or it doesn't?
> 
> 
> A protocol is a system of rules that allow _two_ or more nodes to
> communicate. The protocol specifies the syntax, semantics and so on
> (1).
> 
> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor
> its semantics. It only requires implementation change on one 'side'
> of the protocol, namely on the routers. From that perspective I think
> you can argue that this is not a protocol specification.

How do you get from this: "it only requires implementation change on one
'side' of the protocol" to this: "From that perspective I think you can
argue that this is not a protocol specification". (First sentence
acknowledges it *is* a protocol)

> I think you also make a point that there are further considerations
> here, than just the wire-format. Especially around additional state
> in the routers. In the early days of IPv6 design a lot of time and
> effort was made in avoiding state in the network. If this mechanism
> made address allocation inherently less robust, I think a case could
> be made for why the IETF should specify this in more detail.

Indeed it does:

Current SLAAC: Router crashed and reboots -> network doesn't break

This document: Router carshes and reboots -> who knows what happens.
(Not only this protocol requires state that wasn't required for SLAAC,
but now you also need the mappings to be maintained on stable storage.
Otherwise, if the router crashes and reboots, the netwoks will most
likely break).

> I am not convinced of that though. (In my implementation per host
> prefix adds configured state, but dramatically lessens dynamic state
> (ND)).

What do you mean by "configured state"?

> Interesting question.
> 
> Cheers, Ole
> 
> PS: This draft also raises some interesting IETF process issues
> around change control, oversight and how involved the working group
> should be in changes happening after the document is handed over to
> the IESG.

Indeed.

Thanks,

---

From: David Farmer <[email-masked]>
Date: Fri, 10 Nov 2017 15:25:24 -0600

> think it should be easy to converge on something regarding this one:

I can see how you might have come to that conclusion.  However, I don't
believe the document defines a new protocol or actually changes the old
one. As I see it, the document merely points out an interaction between two
existing protocol specifications, that allows for a desired implementation
outcome of providing a unique prefixes per host using SLAAC. Those being
primarily RFC4861 section 6.2.4, "Sending Unsolicited Router
Advertisements" and RFC6085 "Address Mapping of IPv6 Multicast Packets on
Ethernet".  The desired result is consistent with the protocols as they are
currently defined, the document doesn't change anything, it only points out
facts of the current specifications that may not be entirely obvious to
everyone implementing the specifications and that are critical to the
desired outcome of the draft.  Or put another way, the document specifies
how to implement to the current protocols consistent the desired outcome of
providing a unique prefixes per host.

What track IETF document is needed to accomplish that, is a judgment call
for the IESG, as I see it there are valid arguments for this to be a
standards track, BCP, or an informational document.

However, I'm fine with the current status of BCP personally.

Thanks.

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

---

From: Ole Troan <[email-masked]>
Date: Sat, 11 Nov 2017 05:45:37 +0800

Fernando,

> On 11 Nov 2017, at 05:04, Fernando Gont <[email-masked]> wrote:
> 

For it to be a new protocol (or protocol change, it requires _two_ or more communicating entities to be updated.
(The reference above was to the ND/SLAAC protocol.)
Proven by the fact that the host does not change, it doesn't change the ND protocol.
(With the set of reservations outlines in previous email).

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Sat, 11 Nov 2017 05:52:37 +0800

> Otherwise, if the router crashes and reboots, the netwoks will most

If you read this document as an operational document, describing one potential deployment scenario, then those considerations are left as an exercise to the operator. I.e. don't deploy this in cases where this can happen.

If this has been a protocol specification, I agree that would not be acceptable.

> What do you mean by "configured state"?

In SLAAC, routers require that the IPv6 prefix is configured on the interface.
You can also implement this mechanism in that way.
It is still state, but different dynamically discovered state like the ND cache, or dynamic and non-recoverable state like what you get with middleboxes.

Best regards,
Ole

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Nov 2017 13:58:37 -0800

> is, and subsequently explain why/how such definition does not encompass

I think the definition of “protocol” in the New Oxford Dictionary is adequate. Its entry includes a specialization for “Computing” that reads as follows:

	Computing a set of rules governing the exchange or transmission of data between devices.

This document does not introduce any new rules governing the exchange of data between a provider router and its subscriber hosts. It merely describes a strategy that providers may use under those rules for their routers to provide a set of unique prefixes to each subscriber host. The rules of the existing protocol specified by 6MAN remain unchanged, and one imagines that if 6MAN doesn’t approve of the strategy that V6OPS describes here, then it’s on 6MAN to revise the protocol accordingly.

One might think to counter that the strategy described here does include some explicit and implied requirements on provider routers to perform correctly the existing, already described, protocol for the indicated purpose, but those new requirements do not change the set of rules that govern the exchange, i.e. the protocol. In other words, this draft identifies only a set of further constraints on the behavior of one party in the protocol and describes those constraints as a Best Current Practice. Which is perfectly in line with the V6OPS charter.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Nov 2017 11:26:40 +1300

> From that perspective I think you can argue that this is not a protocol specification.

I agree with that, and other versions of the same argument. (That also
answers Fernando's message directed at me, so I won't waste more bits.)

More on the philosophy side of the argument, WG Charters are a tool to
allow the chairs and AD to control mission creep. They aren't sacred
texts. So IMHO the real question is not whether this is strictly speaking
a protocol extension, but whether it's a useful thing for the IETF to
publish.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Nov 2017 16:36:34 -0800

On 11/10/2017 1:58 PM, james woodyatt wrote:
>
> I think the definition of “protocol” in the New Oxford Dictionary is
> adequate.

The definition there is certainly true, but not adequate except for an
English paper. "rules" are too vague.

In networking, a protocol is:

    a set of rules
    a set of states
    a set of messages that are exchanged (often called the "on the wire"
part)
    a set of events/messages/actions that represent the behavior of each
endpoint (i.e., to upper layers)
    a set of time events
    a set of rules that relate incoming
messages/timer-events/user-actions and state to yield outgoing
messages/timer-sets/user-reports and new states

(the simplest way to express this is as a FSM, which is the most generic
form of computation where a machine cannot revoke its output - which is
why it accurately represents the ends of a protocol)

If you take away any of these (except state and, in limited cases,
time), you cease to have a useful protocol.

If you change any of these, you have a new protocol.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Nov 2017 16:38:31 -0800

> acknowledges it *is* a protocol)
FWIW, from my definition, if you change the rules of either side of a
communication system, you have changed the protocol. The protocol
describes the rules of ALL parties of the system as a set, not in isolation.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Nov 2017 16:41:19 -0800

> a protocol extension, but whether it's a useful thing for the IETF to
FWIW, I would agree with that if this were an issue of WG focus creep. 
AFAICT, the issue appears to go much deeper, which means it's an Area
boundary issue if it is indeed a protocol extension.

IMO, OPS stays in the lane of suggesting sets of *existing* protocol
parameters and features, or indicates where MAYs and SHOULDs can be
relaxed (or not) - all of this remains compliant with the protocol.
Changes to the protocol should not be considered operational decisions,
again IMO.

Joe

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 11:29:26 +0900

I don’t get it when you say this doc makes SLAAC stateful.

‘Staleless’ in SLAAC applies to hosts, not necessarily to routers.

Your argument might be based on the text of the draft, 2nd last para of Sec. 5:

  "IPv6 SLAAC requires the router to maintain neighbor state, which implies costs in terms of memory, power, message exchanges, and message processing."

For routers to keep (address) information about the hosts does not make SLAAC stateful. In order to manage (keep track of) the hosts that use SLAAC, routers need to store some information about the host. This action of the router is natural and has nothing to to with the ‘stateless’ property of SLAAC, AFAIU.

See also, for example, the beginning of the 2nd para of Sec. 1, RFC 4862:

  "The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers.”

I don’t think the text in Sec. 5 of the doc, as repeated above, does not make SLAAC stateful.

---
DY

> On 11 Nov 2017, at 05:23, Fernando Gont <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 11:35:54 +0900

typo. >> 

   I DON'T THINK the text in Sec. 5 of the doc, as repeated above, MAKES SLAAC stateful.

---
DY

> On 11 Nov 2017, at 11:29, DY Kim <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Nov 2017 10:45:10 +0800

The issue is that if you have allocated a prefix for a host and then you reboot the router, either you retain the allocation in stable storage, or you don't.   If you don't, how do you make sure that the host doesn't get renumbered?

That's the sense in which this is stateful, whereas SLAAC by itself is not.   It's not really SLAAC that's stateful—it's the mapping between the link-local SLAAC address and the prefix that's assigned to the host.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Nov 2017 23:51:04 -0300

> (The reference above was to the ND/SLAAC protocol.)

Who said you need to change both sides for it to be a protocol update?

You have a sate machine for each endpoint. As soon as you change one,
you have changed the protocol.

Thanks,

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 12:02:12 +0900

The issue is about the router crash and recovery, not SLAAC itself; not particular about SLAAC.

Even with the legacy operation wherein the router is assigned a link prefix (from the site server by some means) to be advertised to the hosts on the shared link and the hosts run SLAAC for address assignment to their interfaces, what happens if the router crashes?

Either the router has kept that link prefix in a stable storage, or if not, the router might have to acquire a new link prefix from the site server, and not even knowing whether the refreshed prefix should be the same as or different from the previous one, the router and the hosts on the link might go through a painful renumbering anyhow.

Hence, the issue, if any, should be raised against the router spec, not against this draft or even SLAAC, I’d think.

---
DY

> On 11 Nov 2017, at 11:45, Ted Lemon <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Nov 2017 00:05:13 -0300

> That's the sense in which this is stateful, whereas SLAAC by itself is not.   It's not really SLAAC that's stateful—it's the mapping between the link-local SLAAC address and the prefix that's assig…

If the SLAAC router needs to keep that state, why do you say that it is
not SLAAC that is stateful? Whose state is that, then?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Nov 2017 00:10:09 -0300

FWIW, I agree with everything that Joe said below.

Now, consider the FSM of router side of SLAAC, and compare it with the
FSM of the mechanism being proposed. The difference should be evident.

Thanks,
Fernando

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 12:13:00 +0900

The host’s state.

RFC 4862:

  "This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6).”

  "The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers."

---
DY

> On 11 Nov 2017, at 12:05, Fernando Gont <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Nov 2017 00:16:39 -0300

>   "The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers."

Host state, maintained at the router?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Nov 2017 11:18:01 +0800

> Hence, the issue, if any, should be raised against the router spec, not against this draft or even SLAAC, I’d think.

There's clearly an issue.   The router has to preserve the prefix assigned to the host across reboots, or else the host will have to flash renumber.   This would be quite a bit worse than current behavior with SLAAC, and I think is unacceptable.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Nov 2017 11:19:11 +0800

> not SLAAC that is stateful? Whose state is that, then?

SLAAC is stateless.   The host can freely change its SLAAC address at any time.   However, when it does so, it will get a new prefix.   It's the binding between the SLAAC address and the prefix that is stateful.   So the address itself isn't what's stateful.

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 12:54:57 +0900

The ‘state’ in the wording SLAAC means that of the host, I mean.

SLAAC don’t need to require the router to do anything special, other than the router’s usual prefix advertisement through an RA.

The same is true of the case wherein DHCP is used to assign addresses to hosts by the router.

How the router keeps the link prefix info in its system is an interest neither to DHCP or SLAAC, since the link prefix itself is not about address assignment in which DHCP and SLAAC are interested.

How the router keeps the link prefix(es), whether shared or unique to each hosts, is an issue of the router system implementation, not of the protocols DHCP or SLAAC.

Hence, the question about how the prefix(es) are stored or recovered should be addressed to the router spec, neither to DHCP, nor to SLAAC, nor to this draft, I’d think.

---
DY

> On 11 Nov 2017, at 12:16, Fernando Gont <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 12:57:45 +0900

That the router has to preserve the prefix(es) applies the same to both SLAAC and DHCP. The draft has not brought anything new/strange to the usual behavior of the router in association with SLAAC.

---
DY

> On 11 Nov 2017, at 12:18, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Nov 2017 12:00:09 +0800

> That the router has to preserve the prefix(es) applies the same to both SLAAC and DHCP. The draft has not brought anything new/strange to the usual behavior of the router in association with SLAAC.

Not correct.   In the case where we are not doing unique prefix per host, the prefix is static.   In a sense it's stateful, in that it is configured on the router, but there is no binding between the host and the prefix.   With unique prefix per host, the router has to have a bunch of prefixes, each of which is allocated to a specific host.   These allocations are dynamic, have lifetimes, and need to be managed.   It is simply not the case that the default behavior and the new behavior are analogous.

---

From: DY Kim <[email-masked]>
Date: Sat, 11 Nov 2017 13:14:48 +0900

Points taken.

---
DY

> On 11 Nov 2017, at 13:00, Ted Lemon <[email-masked]> wrote:
>

---

From: Warren Kumari <[email-masked]>
Date: Sat, 11 Nov 2017 17:34:15 +0800

> PS: This draft also raises some interesting IETF process issues around change control, oversight and how involved the working group should be in changes happening after the document is handed over…

Yup, that is always a tension.

In this particular case, there was an IETF LC on May 23rd, completing
June 6. There were a number of comments addressed and it went through
IESG review / telechat on Aug 17 telechat (as version -07).

There were enough issues raised during the IESG eval (and continuing
discussion on the V6OPS list exposing lack of clarity) that I decided
to return it to the WG on Sept 9th
(https://www.ietf.org/mail-archive/web/v6ops/current/msg27681.html)

The text under discussion was added in version -09 (Sept 14th).
There was a second WGLC (on version -12) on Oct 1st
(https://www.ietf.org/mail-archive/web/v6ops/current/msg28048.html)
which completed Oct 9th
(https://www.ietf.org/mail-archive/web/v6ops/current/msg28062.html).

I decided that the changes were sufficently small that it did not need
a second IETF LC (this may have been a mistake), and it had a second
IESG review / was on the October 12th telechat (as version -12).

How involved the WG should be after handing it to the IESG is always
tricky, but in this particular case the document was with the WG when
this text was added (which I think is fine).

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Nov 2017 22:49:23 -0300

On 11/10/2017 07:26 PM, Brian E Carpenter wrote:
> I agree with that, and other versions of the same argument.

That certainly does not agree with my conception of what a protocol is,
which falls well under what was expressed on-list by Joe Touch.

If any of the FSMs that you can employ to model the protocol has
changed, you have changed the protocol.

> (That also

The "philosophy" of my comment is as follows:

* What is the document changes the SLAAC protocol, and maes SLAAC more
brittle: SLAAC is generaly resilient to a router rebooting, whereas,
with this protocol, it likely won't.

* There are a bunch of other aspects, from interoperability to security,
that have been ignored. The document just mentions "oh, we send the
multicasted RAs to unicast link-layer addresses" and essentially omits
way more cucial stuff, including: how do you time-out prefixes? How do
you generate them? What do you do when you don't have any more prefixes
to give away? And many others. Even if this same document/text was being
done in 6man, the protocol spec part is a half-baked protocol
specification. Even more, claiming that this *mechanism* a bcp, is quite
a bold statement when, as noted, there's *lots* that has been omitted.

* I would expect that the "beef" in a document is in what the wg ships
-- the rest is improvements. So, given that the protocol spec part of
this document was added after IETF LC, in a group that is not meant to
do Std Track documents, and given the issues mentioned above, I think
the protocol spec part in Section 4 is out of place.

* As a *side* comment/note: IPv6 automatic configuration is quite a mess
in a number of aspects (including
<https://www.ietf.org/archive/id/draft-gont-6man-slaac-dns-config-issues-01.txt>,
and
<https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-07>).
Publishing mechanism that is not even fully-specified and, even more,
flagging it as "bcp" just adds on top to that. I'd really also like to
see what's the criteria for specifying features in SLAAC and DHCPv6. For
instance... is the plan to duplicate in both as much functionality as
possible?  Or... do we just love SLAAC and will incorporate into SLAAC
everything that would make us otherwise use DHCPv6?  If there's
something available in one protocol (slaac or dhcv6) but not in the
other, and the feature is deemed as needed... should we use such
protocol or just figure out what to do to somehow implement such feature
in our belove one?  e.g. in this case, if what you want is a prefix, why
don't you use prefix delegation? And if the goal is just to isolate
nodes, set L=0 in the RAs, and so be it.

Thanks,

---

From: DY Kim <[email-masked]>
Date: Sun, 12 Nov 2017 11:25:12 +0900

I’m not sure whether setting L=0 guarantees node isolation:

  https://tools.ietf.org/html/rfc4861#section-4.6.2

 “L    … When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not set a host MUST NOT conclude that an address derived from the prefix is off-link.  That is, it MUST NOT update a previous indication that the address is on-link.”

That is, with refreshing L=0 for the same prefix, the previous on-link property of the prefix continues to be valid.

---
DY

> On 12 Nov 2017, at 10:49, Fernando Gont <[email-masked]> wrote:
> 
> And if the goal is just to isolate

---

From: Bob Hinden <[email-masked]>
Date: Sun, 12 Nov 2017 15:42:02 +0800

Ted,

> On Nov 11, 2017, at 11:18 AM, Ted Lemon <[email-masked]> wrote:
> 

I agree.  I think this document needs to address this topic.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 12 Nov 2017 12:56:36 +0000

> FSM of the mechanism being proposed. The difference should be evident.

The ID also omits any discussion about how this state is managed in the
context of source address validation by edge devices.

This would be important from an operational point of view, as it
introduces a substantial degree of state management into the network
infrastructure, not just the next-hop router.

Nick

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Nov 2017 10:07:37 +0800

> The ‘state’ in the wording SLAAC means that of the host, I mean.

DY,

The history of why SLAAC has "stateless" in its name in its name doesn't 
match your statement.
When SLAAC was created there was BOOTP/DHCP for IPv4, but not work had 
started on what would later become DHCPv6, but such work was 
anticipated. The use of "stateless" was to distinguish SLAAC from the 
case where there is a network service (akin to DHCP) which retains state 
about the allocations made for hosts. At that time the use of DHCPv4 for 
IPv4 address allocation was quite new and not very robust and there was 
concerns about IPv6 having a hard dependency on such a service.

Also, further back in time, at the Big10 meeting of the IPng directorate 
was the first time I heard the 128 bit address format be discussed with 
the idea than an IPv6 address could be formed using (a) prefix(es) 
advertised by the router and a 48 byte mac address of the host following 
an approach which had been used in other protocols (IPX I believe).

The fact that as IPv6 then evolved that evolved from 48 byte MAC to 64 
bit IID and the IID's later became more friendly to privacy 
considerations doesn't change the fact that we have never added a 
requirement that routers speaking SLAAC maintain per-host allocation 
information; they do maintain per-link configuration information.

Whether the split in to stateless and stateful (aka DHCPv6) address 
allocation was a wise choice is something I leave as an exercise to the 
reader. I merely offer the observation that we keep on muddling any 
boundaries between stateless and stateful address allocation and also 
between address allocation and host configuration.
The resulting larger number of possible implementation and configuration 
choices on the host and network/router side doesn't seem helpful in 
facilitating interoperable protocols.

Regards,
    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Nov 2017 11:14:13 +0900

> Changes to the protocol should not be considered operational decisions,

Excuse me, but I really cannot fathom why we are saying that this draft
defines a new protocol when it is an explicit goal for all existing
implementations to continue to work. How can this be a new protocol when
all implementations implement this already?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Nov 2017 11:15:48 +0900

> infrastructure, not just the next-hop router.

Sure, but I don't think that issue is in scope for this document. DHCPv6 PD
has exactly the same issue, and AFAIK the solution(s) to that issue are not
documented in any RFC.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 10:17:15 +0800

On Nov 13, 2017, at 10:14 AM, Lorenzo Colitti <[email-masked]> wrote:
> Excuse me, but I really cannot fathom why we are saying that this draft defines a new protocol when it is an explicit goal for all existing implementations to continue to work. How can this be a new protocol when all implementations implement this already?

All host implementations have to work.   In order for them to work, new router behavior has to be specified.   That sounds like a protocol spec to me.  My question would be, why is this a problem?   I think that the document could be clearer about required behavior, but it already basically says what needs to happen.   Discussing this with Suresh on Saturday morning convinced me that more clarity would be useful, but that seems like a pretty easy problem to solve.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 13 Nov 2017 02:17:33 +0000

+1 with Lorenzo.. and this “is” working and “deployed” right now…

On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
FWIW, I would agree with that if this were an issue of WG focus creep.
AFAICT, the issue appears to go much deeper, which means it's an Area
boundary issue if it is indeed a protocol extension.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 10:27:59 +0800

On 11/13/2017 10:14 AM, Lorenzo Colitti wrote:
> defines a new protocol 

Model SLAAC with a FSM for the client, and a FSM for the server. Now
apply this document. And look at the SLAAC router FSM.

Did it change (and quite a lot, actually)?  If yes, then you ahve
changed the protocol. If not, you didn't do the FSM properly.

Hope this helps.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 10:42:54 +0800

Fernando,

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

Or do as I do in my implementation.
Model each host as being on it's own point to point interface.
Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 10:44:01 +0800

> +1 with Lorenzo.. and this “is” working and “deployed” right now…

And that always means that no spec is needed, since we have running code.   :)

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 10:50:04 +0800

On 11/13/2017 10:17 AM, Ted Lemon wrote:
> On Nov 13, 2017, at 10:14 AM, Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> wrote:
>> Excuse me, but I really cannot fathom why we are saying that this
>> draft defines a new protocol when it is an explicit goal for all
>> existing implementations to continue to work. How can this be a new
>> protocol when all implementations implement this already?
> 
> All host implementations have to work.   In order for them to work, new
> router behavior has to be specified.   That sounds like a protocol spec
> to me.  My question would be, why is this a problem?   I think that the
> document could be clearer about required behavior, but it already
> basically says what needs to happen. 

If it's a BCP, then it should state what it wants to achieve, and note
that there is a standardized way to do it (DHCPv6-PD), and there are
products width non-standard mechanisms based SLAAC. And that's fair enough.

If somebody is willing to specify PD for SLAAC, then they should write
an I-D targeting 6man -- one might also wonder if also name it SSLAAC,
or just AAC (if there's a lack of a better name :-) )

Putting state into SLAAC will likely trigger "WTH!?" moments,
particulaly in folks that are already having a hard figuring out how all
the IPv6 automatic configuration pieces fit together.

I also wonder what's the logic with which we'd be specifying PD for
SLAAC... and also wondering if we're also going to specify a route
option for DHCPv6, and the like. And, if we're essentially going to
disregard anything and everything that can already be done in a standard
way with DHCPv6 and hack it into slaac instead, why we don't we just
close dhc wg.

Doing a half-baked sateful SLAAC for PD, and telling the community that
that's our best current practice seems to be like sending the wrong
message...

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Mon, 13 Nov 2017 10:53:43 +0800

Ole,

> On Nov 13, 2017, at 10:42 AM, Ole Troan <[email-masked]> wrote:
> 
> Fernando,
> 

Good point.  If the document had described this as something like creating virtual interfaces, we might not be having this discussion.

Bob

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 13 Nov 2017 02:55:20 +0000

Same for the Nokia implementation. It is session based p-t-p model and the session state is build upon for example IPoE, EAP-SIM, etc.... 

WG decided to exclude how the session state is achieved on the first hop router. We as WG decided that creation and maintaining of state on that access router over reboots is outside of scope for the /64 allocation per connected EU. Nothing new from standards perspective to give /64 to a EU is needed, then beyond what is in the document. We are discussing scope creep.

G/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, November 13, 2017 10:43
To: Fernando Gont <[email-masked]>
Cc: [email-masked]; [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Fernando,

>> draft defines a new protocol
> 

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 10:56:23 +0800

> Good point.  If the document had described this as something like creating virtual interfaces, we might not be having this discussion.

The problem is that there is still required behavior around these "virtual interfaces" that needs to be documented.

E.g., Ole, what happens in your implementation if the router reboots?   What happens if a host chooses a new link-local address?   Etc.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 11:00:56 +0800

> Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.

The I assume that, in that case, you don't need to do anything fancy
with how you send the multicasted RAs, and the SLAAC router
implementation need not keep a table of bindings?

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Nov 2017 11:05:18 +0800

Ole,

did you figure out how to expire those allocated prefixes when the host 
is long gone from the network?

The draft seems to be silent on that issue and if the purpose is to 
document some current practice it would be good to capture that.

    Erik

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 13 Nov 2017 03:06:29 +0000

Ted, it depends upon how the router identifies what is a session to create the "virtual interface".
The session state mechanics is considered out of scope for this particular v6ops document. It can be done in many many ways... and the across reboots can be done in many ways also, depending on the capabilities of the router and the backend OSS system. Its out of scope.

G/

From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, November 13, 2017 10:56
To: Bob Hinden <[email-masked]>
Cc: Fernando Gont <[email-masked]>; [email-masked]; [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

On Nov 13, 2017, at 10:53 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
Good point.  If the document had described this as something like creating virtual interfaces, we might not be having this discussion.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 11:07:01 +0800

Fernando,

> implementation need not keep a table of bindings?

That's correct.
The interfaces look like:
interface P2P-Ethernet0 remote-mac aa:bb:cc:dd:ee:ff
 ipv6 address 2001:db8::1/64

Think of it as an interface with a fixed L2 address for the remote end.
L3 to L2 address mapping is then fixed, both for unicast and multicast.
Should that have it's own internet draft, very possibly?

In the vein of all problems in computer science can be solved with another layer of redirection.
How these interfaces are created and how they are maintained across reboots etc, can be considered out of scope for the SLAAC feature.
Although they have to be solved somewhere somehow of course.

Best regards,
Ole

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 13 Nov 2017 03:08:10 +0000

The session state management procedures out of scope of this document. This is scope creep.

G/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Monday, November 13, 2017 11:05
To: Ole Troan <[email-masked]>; Fernando Gont <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Ole,

did you figure out how to expire those allocated prefixes when the host is long gone from the network?

The draft seems to be silent on that issue and if the purpose is to document some current practice it would be good to capture that.

    Erik

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 11:14:29 +0800

Erik,

> The draft seems to be silent on that issue and if the purpose is to document some current practice it would be good to capture that.

Right, and it might be a case of "it depends".
Interesting question though, would be benefit from an L3 solution to this problem?

In my implementation, since I'm only doing a data-plane, it's not my problem. Let the control plane deal with that. ;-)

- in a wired network, where routing is done to the edge, with a physical interface to each host then data-link layer events would suffice.
- on 802.11 you could be tightly integrated with AP / WLC

If we were to do this at L3, we would need some sort of keepalive messages.
Thinking aloud here, any time where a host requires state to be maintained in the network, we are much better off if we put the burden of maintaining that state and ensuring the state is in the first-hop router on the host. E.g. like you did with the ARO option.

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 11:27:22 +0800

On Nov 13, 2017, at 11:06 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> The session state mechanics is considered out of scope for this particular v6ops document. It can be done in many many ways… and the across reboots can be done in many ways also, depending on the capabilities of the router and the backend OSS system. Its out of scope.

Sure, I get that, but the document doesn't say what the required behavior is.   I don't think that should be out of scope.   This is somewhat exacerbated by the proposed update to the privacy considerations section as a result of Alissa's DISCUSS.

---

From: DaeYoung KIM <[email-masked]>
Date: Mon, 13 Nov 2017 13:38:05 +0900

Thanks, Erik. Well taken.

Sent from my iPhone

> On 13 Nov 2017, at 11:07, Erik Nordmark <[email-masked]> wrote:
> 
> The history of why SLAAC has "stateless" in its name in its name doesn't match your statement.
> When SLAAC was created there was BOOTP/DHCP for IPv4, but not work had started on what would later become DHCPv6, but such work was anticipated. The use of "stateless" was to distinguish SLAAC from the case where there is a network service (akin to DHCP) which retains state about the allocations made for hosts. At that time the use of DHCPv4 for IPv4 address allocation was quite new and not very robust and there was concerns about IPv6 having a hard dependency on such a service.
> 
> Also, further back in time, at the Big10 meeting of the IPng directorate was the first time I heard the 128 bit address format be discussed with the idea than an IPv6 address could be formed using (a) prefix(es) advertised by the router and a 48 byte mac address of the host following an approach which had been used in other protocols (IPX I believe).
> 
> The fact that as IPv6 then evolved that evolved from 48 byte MAC to 64 bit IID and the IID's later became more friendly to privacy considerations doesn't change the fact that we have never added a requirement that routers speaking SLAAC maintain per-host allocation information; they do maintain per-link configuration information.
> 
> 
> Whether the split in to stateless and stateful (aka DHCPv6) address allocation was a wise choice is something I leave as an exercise to the reader. I merely offer the observation that we keep on muddling any boundaries between stateless and stateful address allocation and also between address allocation and host configuration.
> The resulting larger number of possible implementation and configuration choices on the host and network/router side doesn't seem helpful in facilitating interoperable protocols.
> 
> Regards,
>   Erik
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Nov 2017 18:49:58 +1300

On 13/11/2017 15:07, Erik Nordmark wrote:
> When SLAAC was created there was BOOTP/DHCP for IPv4, 

To be 100% historically accurate, DHCP was defined but definitely
unproven; the vast majority of sites were still configuring host
IP addresses by hand. The commercial alternatives such as Netware
were all better than IP in that respect, and SLAAC looked like
a great leap forward.

   Brian

> but not work had

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Nov 2017 14:24:47 +0800

Ole,

> In my implementation, since I'm only doing a data-plane, it's not my problem. Let the control plane deal with that. ;-)

Has this or is this being deployed?

Seems like some solution would be needed to avoid running out of prefixes.

> - on 802.11 you could be tightly integrated with AP / WLC

Yes, I can see how one can use loss of the link/association to trigger 
this in some cases. But even in those cases/topologies if the host 
looses the link and reconnects it isn't necessarily going to redo the RS 
hence you can't tell whether it is still there or not.

> Thinking aloud here, any time where a host requires state to be maintained in the network, we are much better off if we put the burden of maintaining that state and ensuring the state is in the fir…

Yeah that soft state approach has been shown to be useful in other 
protocols. In this particular case it would require the hosts to send 
some form of "refresh" packet, which could be a unicast RS or anything 
else we'd like.

    Erik

---

From: Mark Smith <[email-masked]>
Date: Mon, 13 Nov 2017 18:52:21 +1100

On 13 Nov. 2017 14:08, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <
[email-masked]> wrote:

The session state management procedures out of scope of this document. This
is scope creep.

I don't think it is.

It's a fantasy that routers don't fail, or that a single router on a link
is always enough.

Host connections are supposed to survive transient failures such router
reloads or switching to a different router that provides equivalent packet
forwarding service. If a host loses its prefix in this scenario because of
either of those events, then I don't think this method as currently
described is robust against a foreseeable failure.

I don't think it is a Best current practice if router redundancy hasn't
been considered or tested and deployed, and can therefore be documented. I
see value in the approach because of SLAAC compatibility with hosts however
I think it is currently half baked.

Regards,
Mark.

G/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Monday, November 13, 2017 11:05
To: Ole Troan <[email-masked]>; Fernando Gont <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-
prefix-per-host)

On 11/13/2017 10:42 AM, Ole Troan wrote:

> Configure the IPv6 prefix on that interface. That configured state is
exactly like what we have in classic SLAAC.

Ole,

did you figure out how to expire those allocated prefixes when the host is
long gone from the network?

    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Nov 2017 17:00:36 +0900

> I think it is currently half baked.

Let me state this again:

   - DHCPv6 PD has exactly the same problem.
   - As far as I am aware there is no RFC that documents the solutions that
   are in use for DHCPv6 PD.
   - This has not stopped the deployment of tens or hundreds of millions of
   networks that use DHCPv6 PD.

Why are we holding this document up on this?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 16:04:11 +0800

On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti <[email-masked]> wrote:
> DHCPv6 PD has exactly the same problem.

DHCPv6 PD specifies a stateful mechanism for managing prefixes.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 16:14:24 +0800

Mark,

> I don't think it is a Best current practice if router redundancy hasn't been considered or tested and deployed, and can therefore be documented. I see value in the approach because of SLAAC compatibility with hosts however I think it is currently half baked.

I don't understand either why the IESG thinks this should be a BCP.
But for different reasons.

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Nov 2017 17:17:12 +0900

> DHCPv6 PD specifies a stateful mechanism for managing prefixes.

And it does not specify how those prefixes are pushed to routers between
the requesting router and the DHCPv6 server. But in the real world, that is
a hard requirement for things to work, since in the real world, the DHCPv6
server is almost never in the client's first-hop router.

---

From: Enno Rey <[email-masked]>
Date: Mon, 13 Nov 2017 09:20:40 +0100

Hi,

> server is almost never in the client's first-hop router.

I didn't follow the full thread but wasn't it supposed to discuss SLAAC (somewhat becoming SFAAC) and not DHCPv6?

thanks

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Matthias Luft, Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 16:25:06 +0800

On Nov 13, 2017, at 4:17 PM, Lorenzo Colitti <[email-masked]> wrote:
> And it does not specify how those prefixes are pushed to routers between the requesting router and the DHCPv6 server. But in the real world, that is a hard requirement for things to work, since in the real world, the DHCPv6 server is almost never in the client's first-hop router.

That's the problem that leasequery solves.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 16:30:04 +0800

Ted,

> That's the problem that leasequery solves.

Well, we've really never specified how route injection should work on relays in PD.
RFC3633 does only specify the mechanism where the RR and DR are directly connected.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 17:21:26 +0800

>> implementation need not keep a table of bindings?

Then that's okay from the pov of slaac specification. The I-D in
question could focus on what it wants to achieve and, if anything, point
that this can be achieved with DHCPv6-PD, but there are also products
that achieve the same thing via "virtualization + slaac" (or something
along these lines). And the protocol-specific details from Section 4
(how you send the RAs, etc.) can and should be removed.

Question: is the motivation of this "mechanism" to stick to SLAAC,
because Android does not support DHCPv6?

> Should that have it's own internet draft, very possibly?

If this is somethings that is deemed as useful (I guess it is, if you
implemented it), then: definitely. The document could also discuss
details such as how you time out prefixes, etc. e.g., if a node
vanishes, for how long do you keep the lease/virtual-interface? If you
run out of prefixes, do you just ignore new RSes? Do you base the
generation of the prefix on the MAC address?  How does this work, given
n prefix bits to play with, in the presence of nodes that vanish, nodes
that randomize MAC addresses, etc. Is this expected to work across
crash&reboot events? What's expected to happen in the presence of such
events?

I'm sure you made decisions on all of these things when you implemented
this...and that's stuff is certainly useful. Not only to understand how
this works, but also for folks that might want to implement this on
their own.

> How these interfaces are created and how they are maintained across reboots etc, can be considered out of scope for the SLAAC feature.

If the implementation approach is as you've described, this is outside
of the SLAAC specification, indeed (nobody can prevent you from spawning
instances of SLAAC that behave according to the existing standards).
>From a operational point of view, one would wonder why pursue this path
as opposed to e.g. do DHCPv6 -- even if that means: we want to support
Android, and Android does not support DHCPv6. And also if this is a best
current practice, or just one possible deployment strategy ("you should
do this" vs "we have done this").

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 18:01:22 +0800

> RFC3633 does only specify the mechanism where the RR and DR are directly connected.

While true, this isn't the same sort of problem.   We have specified how state is retained, and the information is available both when the assignment occurs and thereafter, using leasequery.   It would be nice if it were explicitly said somewhere "snoop in the packet as it goes by, use leasequery to recover state," but routers do that anyway, and there isn't an interop problem because there aren't multiple ways to do it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Nov 2017 20:14:09 +0900

On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <[email-masked]>
wrote:

> as opposed to e.g. do DHCPv6
>

As for DHCPv6 specifically, one reason is that DHCPv6-only networks are not
recommended by the IETF. RFC 7934.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Nov 2017 12:55:49 +0000

Thanks to you as one of the authors.

- Bernie (from iPhone)

On Nov 13, 2017, at 7:14 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

As for DHCPv6 specifically, one reason is that DHCPv6-only networks are not recommended by the IETF. RFC 7934.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 13 Nov 2017 13:09:56 +0000

> not recommended by the IETF. RFC 7934.

reminder: there is no WG consensus that this is what RFC 7934 means.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 21:20:19 +0800

> not recommended by the IETF. RFC 7934.

Yes, sorry: I meant DHCPv6-PD.

RFC7934:

    Due to the drawbacks imposed by requiring explicit requests for
    address space (see Section 4), it is RECOMMENDED that the network
    give the host the ability to use new addresses without requiring
    explicit requests.  This can be achieved either by allowing the host
    to form new addresses autonomously (e.g., via SLAAC) or by providing
    the host with a dedicated /64 prefix.  The prefix MAY be provided
    using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

Therefore, why re-invent PD in SLAAC?

That aside, same RFC says:
    Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
    multiple addresses when the host connects (e.g., the approximately 30
    addresses that can fit into a single packet) would accommodate
    current clients, but it sets a limit on the number of addresses
    available to hosts when they attach and therefore limits the
    development of future applications.

I seem to recall many systems limit the number of addresses per
interface to 16. So the limit of "30 per request" aleady gives you more
than what you typically get, in practice, with SLAAC. Also... is issuing
multiple requests forbidden?

Thanks,

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 08:22:10 -0500

> Android, and Android does not support DHCPv6.

My understanding is one of the authors is an operator and the model
represents operational experience and input on this.

regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 08:35:15 -0500

> Therefore, why re-invent PD in SLAAC?

PD is quite vast, and this draft describes a specific set of use
cases.  It does not seem like a re-invention of PD in SLACC to me.

> interface to 16.

Current limitations are likely ephemeral and can change over time.

> So the limit of "30 per request" aleady gives you more

I think we also have enough history in computing and the Internet to
know that today's concept of "that is way more then we need, so why do
we need more" is not a good argument to limit capabilities.

regards,

Victor K

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 21:51:24 +0800

> cases.  It does not seem like a re-invention of PD in SLACC to me.

Again: Why not use DHCPv6-PD?

> Current limitations are likely ephemeral and can change over time.

Same could possibly be said about packet sizes.

In any case, I don't see any limits on the number of DHCPv6-requests. If
one is not enough, do more than one.

> we need more" is not a good argument to limit capabilities.

Apply this reasoning to your response above:

Rather than limit a node to request a /64, emply DHCPv6-PD, and allow
the node to get more than that. Otherwise, *this* mechanism is enforcing
an artificial limit.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 21:53:31 +0800

> represents operational experience and input on this.

This doesn't answer the question I made above.

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 09:17:09 -0500

> Again: Why not use DHCPv6-PD?

I would leave this up to the operators to decide. They are designing
their network and know their requirements best.  I don't want to be in
a position of ignoring what operators are saying they need by
suggesting we have it all figured out here at the IETF and are telling
them how to make design decisions.

There are many factors the weigh into why operators make certain
decisions.  There are circumstances were DHCPv6-PD would be quite
valid, and others, as described in the draft, where the methods
described are desirable.  I don't think there is any one way to build
a network (I am yet to have built two that look exactly the same given
different input requirements).

regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 09:23:56 -0500

> This doesn't answer the question I made above.

It was noted "From a operational point of view, one would wonder why
pursue this path as opposed to e.g. do DHCPv6".

What I am suggesting is the draft represents an actual operational
point of view from people in the field.

However, the methods described don't inhibit other choices to be made
in other networks, with perhaps other circumstances, to use DHCPv6.

regards,

Victor K

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 22:29:06 +0800

On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:
> I would leave this up to the operators to decide.

We are the ones trying to make SLAAC stateful, contributing to IPv6
automatic configuration complexity, and apparent lack of coherence with
respect to which protocol supports both, and why we e.g. disregard the
work of other WGs (e.g. dhc).

If you want to *partially* duplicate functionality in another protocol,
please provide a rationale, or don't.

> They are designing
> their network and know their requirements best.

Exactly: nobody specified the requirements, or said why DHCPv6-PD
doesn't fullfill them.

> different input requirements).

You still have not answered my question.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 22:31:17 +0800

Fernando, the document is in AUTH48. If there is a technical problem with
it that is sufficient to pull it out of the publication queue at this
point, I haven't heard it yet. I think it would be nice to add a little
advice on how to manage the state, but it's up to the authors to do this or
not. This discussion is getting a bit old.

On Nov 13, 2017 22:27, "Fernando Gont" <[email-masked]> wrote:

> >>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <
> [email-masked]
> >>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks
> are
> >>>>> not recommended by the IETF. RFC 7934.
> >>>>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 22:33:48 +0800

> in other networks, with perhaps other circumstances, to use DHCPv6.

A point of view doesn't become, automagically, a BCP.

And I don't think that the IETF should increase complexity for no
reason. IPv6 automatic configuration is, aleady, enough of a mess to add
more on top of it.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 22:50:07 +0800

Fernando,

> please provide a rationale, or don't.

repeating something enough times doesn't make it true.

> Exactly: nobody specified the requirements, or said why DHCPv6-PD

this is for public WIFI. hosts are unchanged. DHCPv6 PD is a non-starter deployment wise.

> You still have not answered my question.

with regards to complexity. from a ND/SLAAC perspective this is a lot simpler. not more complex. don't make things up.
no address resolution, no ND cache, no need to rewrite L2 multicast to unicast and maintain state in WLCs/APs... I could go on.

I think it is time to shelf this discussion now.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 22:57:24 +0800

Ted,

On 11/13/2017 10:31 PM, Ted Lemon wrote:
> Fernando, the document is in AUTH48. If there is a technical problem
> with it that is sufficient to pull it out of the publication queue at
> this point, I haven't heard it yet. I think it would be nice to add a
> little advice on how to manage the state, but it's up to the authors to
> do this or not. This discussion is getting a bit old. 

The technical problem is that this is a v6ops document making SLAAC
stateful. As discussed, making SLAAC stateful brings breakage scenarios
not present in SLAAC, and that is certainly not a minor change.

And having folks noted that they have implemented this sort of behavior
without changing SLAAC, the low-level protocol details in Section 4 are
even less unwarranted.

It is not my call what's the proper action. But I do note that this is
yet another BCP that rather that essentially disregards work of other wg
(dhc), unnecessarily. Are you are pushing a BCP with a mechanism that is
so underspecified, that folks meaning to implement this are likely to
introduce breakage.

That said, it is not my call what's the proper action to follow. My
intent (noted to e.g. Suresh off-line) is not to obstruct the document,
but to avoid breakage -- particularly when it's unwarranted.

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 09:56:12 -0500

> work of other WGs (e.g. dhc).

I don't see how this work has any impact on what was done in DHC and
disregards it.  We potentially conflating things here?

Much in the same way RFC8106 (DNS info in RAs) does not disregard
DHCPv6 since it too can offer DNS information.

> please provide a rationale, or don't.

Same point as above.  Some apparent duplication may exist, but these
are also two different deployment models. There are reasons why
operators choose one or the other model.  Telling them to use a
different model is not a valid rebuttal in my mind.

> Exactly: nobody specified the requirements, or said why DHCPv6-PD

What if operator does not have a DHCPv6 service for that access
network? (not saying this was driver for draft, but this is one
example).  Adding in a robust DHCPv6 service is not always trivial, so
if an operator is desiring to have this (/64 per host) capability,
while potentially keeping their service deployment framework SLACC,
why are we objecting to it?  SLAAC is a viable model to use, and the
draft describes the reasons for wanting a /64 per host.  So it seems
clear to me.

To exemplify, (maybe too far out of context),

If I asked for an extension to IS-IS for my deployment, and you told
me to use OSPF because that option was already there, my response
would be - "I am not using OSPF".

> You still have not answered my question.

The operator has chosen to use a SLACC model, they need/want the
robustness/capability from a /64 per host.  So, if that's the case,
what DHCPv6 has to offer is not relevant   to what the operator would
need in this case.  A direct quote form the draft seems to also show
one of the reasons (others reasons can exist or may exist in future)

"To not exclude any known IPv6
   implementations, IPv6 SLAAC based subscriber and address management
   is the recommended technology to reach highest percentage of
   connected IPv6 devices on a provider managed shared network service."

regards,

Victor K

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Nov 2017 22:57:50 +0800

It doesn't make slaac stateful.

---

From: Michael H Lambert <[email-masked]>
Date: Mon, 13 Nov 2017 10:04:09 -0500

> On 13 Nov 2017, at 09:31, Ted Lemon <[email-masked]> wrote:
> 
> Fernando, the document is in AUTH48. If there is a technical problem with it that is sufficient to pull it out of the publication queue at this point, I haven't heard it yet. I think it would be nice to add a little advice on how to manage the state, but it's up to the authors to do this or not. This discussion is getting a bit old. 

I do have a question which I don't see addressed (no pun intended) in the draft.  The text only refers to THE first-hop router on the network.  If there are multiple routers on the network which can respond to router solicitations, do they act independently in providing prefixes to the requesting hosts?  If so, how do they (or do they) guarantee uniqueness?  If not, do they need to share any additional state?

Michael

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Nov 2017 00:13:53 +0900

> reminder: there is no WG consensus that this is what RFC 7934 means.

Actually, IIRC the thread you started a couple of months ago reaffirmed
that consensus. (The document does not state that DHCPv6 address assignment
is not recommended, it only states that networks that *only* use DHCPv6
address assignment are not recommended.)

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Nov 2017 16:17:13 +0100

>DHCPv6 since it too can offer DNS information.

There is an interesting dynamics in that any new feature for RA that is a 
essentially a duplicate from what already exists in DHCPv6 gets accepted,
but a simple feature like a default router option in DHCPv6 gets rejected
time and time again because that feature is already provided by RA.

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Nov 2017 09:33:56 -0600

> but to avoid breakage -- particularly when it's unwarranted.

You claim this is making SLAAC stateful by adding state to the router.
However, if anything this reduces the state the router needs to track.
Currently the router has to track address state of  O(NxM).  Where N =
Number Hosts, and M = Average Number Addresses used per Host.  With Unique
Prefix per host, the router only has to track prefix state of O(N).
Allowing a host to use as many addresses as it sees fit without impacting
the amount of state the router has to track.

Further, it seems to me that if anything it's Neighbor Discovery that is
changed, and not SLAAC, and Neighbor Discovery has always been stateful.
Now I don't believe the Neighbor Discovery protocol is actually being
changed, it is merely being implemented differently within the variations
allowed by the protocol.

Finally, this discussion has relieved that there this draft is incomplete
in several ways.  However this document is not any more incomplete than
many other documents already approved by the IESG and implemented on
thousands or even millions of hosts.  That is why we revise documents, we
never get it right the first time.

Thanks.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 13 Nov 2017 15:36:30 +0000

> in other networks, with perhaps other circumstances, to use DHCPv6.

I'm in favour of publication of this document, but not as-is. The change
in the SLAAC protocol to being stateful needs to be explicitly
acknowledged in the document, because it has substantive operational
implications for the router issuing the RAs, for other edge devices
which are involved in the host device SAVI process and for the host
device itself.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Nov 2017 00:46:32 +0900

> the amount of state the router has to track.

+1. Couldn't agree more.

> never get it right the first time.

+1.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 13 Nov 2017 15:48:15 +0000

Lorenzo Colitti wrote:
> that consensus. (The document does not state that DHCPv6 address
> assignment is not recommended, it only states that networks that *only*
> use DHCPv6 address assignment are not recommended.)

1. draft-ietf-v6ops-unique-ipv6-prefix-per-host says nothing one way or
another about networks that *only* use DHCPv6 address assignment, so RFC
7934 is not relevant in this case, even by your own arguments.

2. 7934 does not state that networks that *only* use DHCPv6 address
assignment are not recommended.  There was no WG consensus for your
interpretation, and your interpretation is in direct conflict with the
reality that DHCPv6 can be used to provide multiple IP addresses to a
host, as 7934 recommends, and as was proven with working examples during
that thread and others.  Either way, this is outside the scope of
draft-ietf-v6ops-unique-ipv6-prefix-per-host and it's not helpful to
have another rehash of this argument here.

3. you are now arguing that an option to implement
draft-ietf-v6ops-unique-ipv6-prefix-per-host with DHCPv6 shouldn't be
considered because of rfc7934.  In other words, you're arguing that we
shouldn't introduce the option for hosts to be able to get multiple ipv6
addresses via dhcpv6, because according to you, rfc7934 recommends
against using dhcpv6-only because it lacks the ability to provide
multiple ipv6 addresses for hosts.  I.e. circular reasoning.

These arguments are untenable.  In fact, they're completely ridiculous.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Nov 2017 16:43:50 +0000

This one needs a bit more discussion:

>But in the real world, that is a hard requirement for things to work, since in the real world, the DHCPv6 server is almost never in the client's first-hop router.

In my use case, the DHCPv6 server most definitely is on the Client’s first-hop router.
I do DHCPv6 PD, and everything gets set up correctly, including routing on the first
hop router.

But, what I would really like to get to is the ability to do everything in a single message
exchange. I don’t want to have to do two separate message exchanges (RS/RA followed
by DHCPv6 Solicit/Reply or vice-versa). So, what I would really like would be for the
DHCPv6 Reply to contain information normally found in an RA, e.g., default router
lifetime, default router preferences, link MTU, etc.

So, maybe what would satisfy it would be a new DHCPv6 option that embeds an IPv6
RA with all of its many features. Then, DHCPv6 servers that are known to be on the
same link as the client can include an RA in the DHCPv6 Reply and the client can do
all of its RA-style configurations without having to issue an RS/RA.

Failing that, there would need to be a way to embed information normally gotten
from DHCPv6 in an RA and then make RS/RA the only exchange.

This is very important for devices on which even a single message exchange is
expensive (e.g., airplanes with low-end data links) so I really need an all-in-one
exchange.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, November 13, 2017 12:17 AM
To: Ted Lemon <[email-masked]>
Cc: Fernando Gont <[email-masked]>; [email-masked] WG <[email-masked]>; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

On Mon, Nov 13, 2017 at 5:04 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

  *   DHCPv6 PD has exactly the same problem.
DHCPv6 PD specifies a stateful mechanism for managing prefixes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Nov 2017 02:08:51 +0900

> 7934 is not relevant in this case, even by your own arguments.

Agreed. It is relevant only in that there were comments on this thread that
roughly said "why not use DHCPv6 instead".

> have another rehash of this argument here.

The 7934 recommendation that can't be met by networks that only use DHCPv6
address assignment is not "provide hosts with multiple addresses" - it's
"allow hosts to form new addresses without explicit requests to the
network". But I agree it's not useful to repeat that argument here.

> multiple ipv6 addresses for hosts.  I.e. circular reasoning.

I don't think you understood me. If you're saying that a unique prefix per
host can be assigned using DHCPv6 PD, then of course that's true. Given
that DHCPv6 PD is not widely supported by hosts, it's not a fit for the
goals of this document, which are to support as many hosts as possible. But
it would work.

RFC 7934 only recommends against a network that exclusively uses DHCPv6
*address* assignment. Using DHCPv6 PD to assign a /64 *prefix* to each host
is fine (and in fact, cited as an example).

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Nov 2017 11:03:18 -0800

On Nov 12, 2017, at 18:14, Lorenzo Colitti <[email-masked]> wrote:
> On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:

I agree with Lorenzo here, and I have to push back against Mr. Touch’s earlier message insisting that a protocol specification cannot be useful unless it defines the finite state machines for each participating member. This is not even true in theory, much less in actual practice. In theory, and here I am referring to the literature of bisimulation and the calculi for communicating processes, it’s generally sufficient when formally specifying a protocol to require implementations to exhibit "barbed equivalence" with one another. Indeed, what is the point of insisting on interoperability between disparate implementations if we only accept strict bisimilarity as conformance?

Moreover, we don’t even require formal protocol specifications here, preferring instead— as a matter of explicit policy— to publish informal specifications rather than formal ones. Therefore, it seems to me that a more broadly expansive understanding of the term “protocol” is warranted than the very narrow, much more formalized one that Mr. Touch outlined.

Here’s how I see it: when we publish a protocol specification here, what we are defining the rules to a multiplayer game where each player is free to adopt whatever strategy within the rules is optimal for achieving their aims. Our job as Internet engineers is to insure that the rules of the new and revised games we publish are balanced and do not contribute any damage to the Internet as a communications ecosystem. This draft does not modify any of the rules for provider routers that subscriber hosts legitimately expect them to follow. It makes no recommendations to change any host behaviors. It is therefore not a new protocol. It is merely a new strategy for performing an existing protocol.

It’s also my view that this draft is mainly an attempt by service provider operators to establish a new convention for keeping state in the network on behalf of hosts, and its authors have taken great pains— cut many corners and shaved off a lot of risk mitigation— in order to avoid requiring, or even inviting, hosts to modify their behavior. Maybe, if 6MAN were more responsive to the needs of both provider router operators and subscriber host users, a more elegant solution to the problems this draft is meant to address could have been developed. I don’t blame V6OPS for devising new strategies for dealing with perceived deficiencies in the protocols that 6MAN maintains. Not at all. It’s their job. I’m also far from sure there is even a deficiency here for 6MAN to consider. I can easily see how this draft essentially amounts to exactly the sort of refinement that 6MAN intended to permit when it specified IPv6 Neighbor Discovery the way it did.

---

From: Mark Smith <[email-masked]>
Date: Tue, 14 Nov 2017 06:43:06 +1100

> DHCPv6 PD has exactly the same problem.

No it doesn't.

> As far as I am aware there is no RFC that documents the solutions that are
> in use for DHCPv6 PD.

DHCPv6 has been designed to avoid having state in intermediary devices
by incorporating a relay agent into the architecture, specified in
RFC3315.

Clients use DUIDs to identify themselves, and the DHCPv6 server
associates client attributes with the client's DUID. That is what
allows DHCPv6-PD to survive a router/DHCPv6 relay reboot.

This draft hasn't been published as an RFC, however it is also
considering this issue.

"DHCPv6 Relay Agent Assignment Notification (RAAN) Option"
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-03

A number of vendors seem to have implemented the functional equivalent
by looking directly at the ID_PD option when the DHCPv6 reply is sent
to the client - search for "DHCPv6 Relay Agent Notification for Prefix
Delegation"

The alternative is to have a RADIUS server provide the delegated
prefix information to a DHCPv6 server running on the router. "RADIUS
Delegated-IPv6-Prefix Attribute", RFC4818.

Possibly the RADIUS method could be used in this draft's scenario if a
layer 2 attribute such as the MAC address or per-client VLAN tags, or
802.1X authentication information, is used to identify the client.

If this draft can't document that method because it doesn't exist,
then, assuming Comcast is the only deployment of this, it seems
Comcast aren't trying to have a prefix assignment survive a router
reboot. That's a "flash renumbering" approach, which I don't think is
right for IPv6.

> This has not stopped the deployment of tens or hundreds of millions of

What was the alternative that didn't have this limitation?

There is a big difference between something working and something working well.

I worked on the first production deployment of residential broadband
IPv6 in Australia in 2010. Going by the beta software we were working
with from one of the major BRAS vendors, that was likely one of the
earliest in the world. Making it work was the goal. If the goal was to
make it work well, we wouldn't have deployed it. (I haven't worked on
an IPv6 residential deployment since because of Australia's position
of being early in the IPv4 game, and ISP consolidation making IPv4
pools bigger.)

Six years later, with much more production IPv6 deployment, new
methods and solutions shouldn't be functionally equivalent, they
should be functionally superior, because the consequences of failure
matter more.

> Why are we holding this document up on this?

Half baked cakes aren't cakes, even though they may look like them.

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Nov 2017 08:43:03 +0800

Chair hat off.

> On Nov 13, 2017, at 9:09 PM, Nick Hilliard <[email-masked]> wrote:
> 

I just went back to read it. Having an argument with the author of a document about what it means is an interesting tactic.

There are 26 references to DHCP(v6) in the document. The vast majority of them are factual - "it does this, and there are networks that use it".

The two references I found that are negative statements about DHCP are about IA_NA. Section 8, second and third paragraphs, reads

I think it is absolutely fair to say that the RFC doesn't recommend (recommends against) the mechanism that IA_NA uses. That said, the laptop I'm typing on (a Mac) generally keeps 2-3 addresses per interface and has several interfaces. 30 is a viable number for it. I can also report that I have worked in an environment that only uses DHCPv6, and it worked just fine for any purpose I put it to.

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 08:57:33 +0800

> On 14 Nov 2017, at 03:43, Mark Smith <[email-masked]> wrote:
> 
> 

Yes, it's quite unfortunate that we haven't solved the problem of robust route injection in PD yet.

Ralph and I when writing 3633, concluded while there were many options, few of them were attractive, and instead resorted to specify that PD must operate without relays.

Markus enumerated the options here:
https://www.ietf.org/archive/id/draft-stenberg-pd-route-maintenance-00.txt

Let me know if you are interested in working on the problem.

Best regards,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 09:40:09 +0800

> time and time again because that feature is already provided by RA.

This is actually a reflection of the consensus that Lorenzo mentioned earlier: that we do not recommend DHCPv6-only networks.   Also, it is not true that there is no pushback when new options are proposed for RA.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 09:42:24 +0800

On Nov 13, 2017, at 11:36 PM, Nick Hilliard <[email-masked]> wrote:
> The change
> in the SLAAC protocol to being stateful

Can you explicitly detail what the new state is that needs to be tracked for SLAAC?   I was rather short in my answer to Fernando, but as an implementor I do not see what additional state I now need to track in my SLAAC implementation, and would appreciate it if you could say what state that is.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 09:45:37 +0800

> Half baked cakes aren't cakes, even though they may look like them.

FWIW, "we" aren't holding up this document.   It's in AUTH48.   The working group already has consensus on the document, the IESG has approved it, and at this point the only changes allowed are editorial changes that do not substantively change what the document says.   The working group has no agency here: this is entirely up to the authors and the AD.

If the authors or the AD were to make substantive changes to the document, that would be grounds for an appeal by the working group.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 09:47:29 +0800

On Nov 14, 2017, at 8:43 AM, Fred Baker <[email-masked]> wrote:
> I can also report that I have worked in an environment that only uses DHCPv6, and it worked just fine for any purpose I put it to.

How do you get your route?

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Nov 2017 17:49:24 -0800

On Nov 13, 2017, at 17:40, Ted Lemon <[email-masked]> wrote:
> 
> Also, it is not true that there is no pushback when new options are proposed for RA.

I have a pile of rejections, none of which were duplicates of DHCPv6. One of them was eventually obsoleted by PCP. Another probably gets replaced by a mess of security vulnerabilities (but at least ND6 will remain pure!).

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Nov 2017 01:57:43 +0000

This may be a good moment to halt this discussion.
The original reported finding that this draft makes protocol changes "making SLAAC statefull" has been found invalid.
This means that there is no procedural issue caused by this draft.

AUTH48 process can now go forward as planned.

G/

From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, November 14, 2017 09:46
To: Mark Smith <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>; Fernando Gont <[email-masked]>; [email-masked] WG <[email-masked]>; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

On Nov 14, 2017, at 3:43 AM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Why are we holding this document up on this?
Half baked cakes aren't cakes, even though they may look like them.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Nov 2017 10:08:46 +0800

Hi Philip,

> time and time again because that feature is already provided by RA.

This is certainly not the case. Other than the DNS option in RA (which enables hosts to get minimal internet connectivity) there has been a conscious effort to avoid overlap between DHCPv6 and RA based configuration. Lot of the thinking as to why this has been done is documented in RFC5505 (Section 2.3).

Thanks
Suresh

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Nov 2017 10:41:01 +0800

On Tue, Nov 14, 2017 at 9:45 AM, Ted Lemon <[email-masked]> wrote:
> FWIW, "we" aren't holding up this document.   It's in AUTH48.   The working
> group already has consensus on the document, the IESG has approved it, and
> at this point the only changes allowed are editorial changes that do not
> substantively change what the document says.   The working group has no
> agency here: this is entirely up to the authors and the AD.

Yup, but the AD is closely watching the discussion, because what the
WG wants is critical.

I held up publication because Fernando claimed that this was a
protocol change, and so doing this in V6OPS was a process violation --
as this was right before the meeting I decided it made sense to hold
publication so that A: I could get feedback from the WGs and B: I
could talk to Suresh (in his capacity as 6MAN AD).

Neither Suresh nor I think that this is a protocol change (and these
isn't really even a very fast V6OPS cannot touch protocol) - at the
moment I'm very strongly leaning towards just publishing it, although
(based on discussions with Suresh) I'm *considering* that this should
be Informational instead

Note that versions -04, -05, -06 of the document were Informational;
the GenArt (and other feedback) questioned the BCP status, and it was
(IMO) right on the hairy edge of Informational / BCP (enough that I
asked the IESG to comment on the status during eval). It was right on
the edge before, the new text, WG discussion (and my discussions with
Suresh) may have tipped it over to Informational.

I would feel out the WG about this - would you be OK with this being
Info (and getting it out the door)?

I feel I also owe the WG (and authors) an apology - this has been a
painful process and taken up way more of your time than it should
have.

W
>
> If the authors or the AD were to make substantive changes to the document,
> that would be grounds for an appeal by the working group.
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 03:57:49 +0100

Le 14/11/2017 à 01:57, Ole Troan a écrit :
>> DHCPv6 has been designed to avoid having state in intermediary
>> devices by incorporating a relay agent into the architecture,
>> specified in RFC3315.
>> 
>> by looking directly at the ID_PD option when the DHCPv6 reply is
>> sent to the client - search for "DHCPv6 Relay Agent Notification
>> for Prefix Delegation"
>> 
>> prefix information to a DHCPv6 server running on the router.
>> "RADIUS Delegated-IPv6-Prefix Attribute", RFC4818.
>> 
>> Possibly the RADIUS method could be used in this draft's scenario
>> if a layer 2 attribute such as the MAC address or per-client VLAN
>> tags, or 802.1X authentication information, is used to identify the
>> client.
>> 
>> reboot. That's a "flash renumbering" approach, which I don't think
>> is right for IPv6.
>> 
>> 
>>> This has not stopped the deployment of tens or hundreds of
>>> millions of networks that use DHCPv6 PD.
>>> 
>> 
> Ralph and I when writing 3633, concluded while there were many
> options, few of them were attractive, and instead resorted to specify
> that PD must operate without relays.
> 

I am not sure whether this is an open invitation, or aimed at your
conversation peer.

But I am interested in this problem.  We wrote a draft earlier:
draft-petrescu-relay-route-pd-problem-00.txt

I wonder whether an operator looks at setting a relay on SGW or on PGW.

In a cellular network, there is an interesting point to note in that the
PGW does not have an IP address, is a DHCP server and when it sets
forwarding it actually sets things about GTP.

Alex

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

---

From: DY Kim <[email-masked]>
Date: Tue, 14 Nov 2017 11:59:32 +0900

With my self torn between two schools of thought, I might retry the following argument:

  ‘The draft doesn’t make SLAAC stateful’

The essence of my argument is that what the draft brings new to the router side is not any change of states of any protocols but rather implementation details that need not be reflected on existing protocols like SLAAC or NDv6.

The rationale for my argument goes like the followings:

1.	As far as the hosts are concerned, nothing changes. A host receives RAs as usual, not even knowing that the prefix provided is unique per host, hence running DAD as usual.

2.1.	As for the router, take the case of usual SLAAC. There are no code lines specific about SLAAC. They just issue RAs, either in response to RSs or unsolicited. All it does is either set L=1 or L=0, in accordance with the operators policy.

2.2.	Let us see what changes are taking place to the router as a consequence of this draft.
	First of all, the router intended to implement the ideas of this draft should already know that it’s going to deal with different prefixes for different hosts, uniquely per host. Any routers of the intention then surely have to write in codes to manage the table of prefix-to-host mapping. 
	Should there be any changes to the specs of NDv6 (rfc4861) that the router is running? No. (can be confirmed by re-reading NDv6). NDv6 is silent about how to store/manage the prefix it has handed out, anyhow. That part is implementation details that a protocol need not / should not bother itself with.
	Should any part of the specs of SLAAC (rfc4862) be changed? No. (can be confirmed by re-reading SLAAC). The router hasn’t been involved with any SLAAC specific behaviors anyhow in the fist place, all it does in connection with prefix assignment are NDv6-related actions, which puts us back to the statements made in the just preceding paragraph.

3.	Anything new this draft has brought are not spec changes (of either SLAAC or NDv6) but operational recommendations for any routers intending to adopt the ideas described in the draft. Certainly, you might have to rewrite part of your router software, but the necessary rewriting is such that you put more care about database management in regard to prefix-to-host mappings, but is not of such consequential quality that you might have to ask 6man to revise either SLAAC or NDv6.

4.	The conclusion is that the draft has not made any changes to SLAAC. The management of the prefix-to-host mapping table is not part of the SLAAC specs itself, but is simply part of your implementation details up to your best choice in your system environment.

P.S.: A protocol, by definition, is an interaction between two remote entities by exchange of messages of specific syntax and semantics. If there are no changes to such incurred, it’s not a protocol changes, and so is not subject to be sent to 6man.

---
DY

> On 14 Nov 2017, at 10:49, james woodyatt <[email-masked]> wrote:
> 
> --james woodyatt <[email-masked]>
> 
> 
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Nov 2017 11:01:05 +0800

As specified in 3315, I imagine...

Sent using a machine that autocorrects in interesting ways...

> On Nov 14, 2017, at 9:47 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Nov 2017 04:15:08 +0100 (CET)

> forwarding it actually sets things about GTP.

The PGW has a link-local address, so your above statement is not correct.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 14 Nov 2017 03:17:47 +0000

Ole I think this is perhaps 5-7 years too late possibly longer.  To be clear this has in fact been solved, PDRI was something we needed to address to launch IPv6 for DOCSIS based HSD many years ago.  Ralph (since you mention him) was there, he knows.

This is widely supported today across cable networks specifically for DOCSIS and even other fiber based (PON) access network implementations where we (Comcast) were involved in the development of IPv6 support.  Note we use the same implementation for our video services, which are IPv6 only.

Why in heavens name would you now go back and document something that has been done for so long? (rhetorical)

Please note a documentation exercise will not change any existing deployments, this ship has sailed.  This is not a wise use of IETF time and energy.  If this is the type of work the IETF believes requires attention perhaps it is time to start shutting down some of the IPv6 (6man/v6ops) WGs.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Ole Trøan <[email-masked]>
Date: Monday, November 13, 2017 at 18:57
To: Mark Smith <[email-masked]>
Cc: Fernando Gont <[email-masked]>, v6ops <[email-masked]>, "[email-masked]" <[email-masked]>, Gunter Van de Velde <[email-masked]>
Subject: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))

    

    
    
    Best regards,
    Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 04:21:21 +0100

Le 14/11/2017 à 04:15, Mikael Abrahamsson a écrit :
>> In a cellular network, there is an interesting point to note in that 
>> the PGW does not have an IP address, is a DHCP server and when it sets 

I agree, I meant PGW had no GUA.

Alex

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Nov 2017 11:22:49 +0800

Hi all,
  I would like to summarize the issues that have been brought up, along with my views (I apologize for the long mail but I think it is warranted in this case)

a) Changes were made to the draft after most of the IESG balloted on an older version of the document

Yes .This is an issue but hardly limited to this draft. I keep reading newer versions of the draft if I balloted DISCUSS and/or have some open issues that need to get resolved. After the issues are resolved, I do not usually read newer versions unless I am the shepherding AD for the document in which case I do. I spoke to some of the other ADs and their workflows are similar. This is something we need to discuss on the IESG in order to see how we can improve.

b) Mechanism does not work

Given that the mechanism has been implemented and deployed by the authors, I have a hard time taking this claim at face value. Providing an unique prefix per host has been standard practice in 3GPP mobile networks for the past *15 years*. based on recommendations from the IETF back at that time. When a mobile attaches, there is state created on the first hop router that does exactly what this draft wants to do. The only issue I see is a lack of mechanism to clean up stale prefixes if the hosts go away, but depending on the deployment this may or may not be an issue.

c) The document should be Informational and not BCP

Regardless of people claiming on this thread that the IESG chose this to be a BCP, it is the *v6ops WG* that decided to send this in as BCP. The document was IETF Last Called as BCP way before it even hit the IESG. Given that there is no objective guidance in RFC2026 on what constitutes a BCP (“best” and "what is believed to be the best way” are not exactly objective) we could go either way. I am inclined to go along with the wishes of the WG (v6ops), the shepherding AD (Warren) in the absence of a more definitive measure of suitability. That said, as I conveyed to Warren, I would not object if this was made Informational either.

d) Draft should have been done in 6man

Let me start off by stating that (AFAIK) there is no written agreement between 6man and v6ops as to the split of work. We have mostly used common sense to decide where things go. Specifically, if there have been bits-on-the-wire changes we have insisted that the work be done in 6man and this is certainly not the case for the document in question. I think this work is certainly pertinent to v6ops based on the following text in their charter

Solicit input from network operators and users to identify
operational issues with IPv6 networks, and determine solutions or
workarounds to those issues.

In closing, looking at where the document is in the publication cycle (It is in AUTH48 and it was probably an hour or so away from being published as an RFC), I think making major changes to the draft without a clear justification and WG consensus is not appropriate .

Thanks
Suresh

> On Nov 14, 2017, at 9:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> The original reported finding that this draft makes protocol changes “making SLAAC statefull” has been found invalid.
>   <>
> On Nov 14, 2017, at 3:43 AM, Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Nov 2017 04:30:29 +0100 (CET)

> I agree, I meant PGW had no GUA.

So what is "interesting" about this situation?

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 04:46:37 +0100

Le 14/11/2017 à 04:30, Mikael Abrahamsson a écrit :
>>>> the PGW does not have an IP address, is a DHCP server and when it 
>>>> sets forwarding it actually sets things about GTP.
>>>

Well, there is no Relay, so one would think there is no need for 'route 
injection'.

There is what can be assimilated to 'route insertion' in that the Server 
(PGW) does relate the GTP tunnel to the prefix it allocated, in its 
local table, without sending 'route updates' in the network.

There is a need to send route updates only if there is a Relay.  When 
there is a Relay the Server has a GUA.

This makes wonder whether in cellular networks the PGW needs to do route 
injection (route updates) during DHCPv6-PD.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Nov 2017 12:23:44 +0800

> Info (and getting it out the door)?

Warren,

is it worth asking that question on a new thread that is narrowly scoped to
that question? There's a lot of discussion still on this thread that might
cloud the response.

Cheers,
Lorenzo

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Nov 2017 06:00:10 +0100 (CET)

> there is a Relay the Server has a GUA.

Commonly, but not necessarily, and also irrelevant to the problem at hand.

> injection (route updates) during DHCPv6-PD.

It needs to install the delegated prefix into its RIB/FIB. If it needs to 
tell anyone else about it is a different problem, and it depends on the 
setup. If there is a covering larger prefix statically routed to it then 
it doesn't need to tell anyone else. There is no requirement for the PGW 
to use a routing protocol, but nothing in the architecture that precludes 
it from doing so.

PGW is a router, and in this case for PD it can be either a relay or a 
DHCPv6 server, perhaps with a diameter backend. Depends on how you define 
it, is a DHCPv6-PD delegating router asking Diameter what prefix to 
assign, actually a relay or a server? I don't think it matters anyway, it 
ends up the same thing.

Nontheless, there is no fundamentally different about this, to any other 
situation with a PPPoE terminating BNG for instance.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 07:47:18 +0100

Le 14/11/2017 à 06:00, Mikael Abrahamsson a écrit :
>> There is a need to send route updates only if there is a Relay.
>> When there is a Relay the Server has a GUA.
> 
> Commonly, but not necessarily,

It is very necessary for the Server to put its GUA in the Advertise it
sends to the Client through a Relay.  Because LL-addressed packets dont
get through Relays.

> and also irrelevant to the problem at hand.

I think the routing injection problem is at Relay.  If there is no Relay
there is no route injection problem.

>> This makes wonder whether in cellular networks the PGW needs to do
>>  route injection (route updates) during DHCPv6-PD.
> 
> It needs to install the delegated prefix into its RIB/FIB >
> If it needs to tell anyone else about it is a different problem, and
> it depends on the setup. If there is a covering larger prefix
> statically routed to it then it doesn't need to tell anyone else.
> There is no requirement for the PGW to use a routing protocol, but
> nothing in the architecture that precludes it from doing so.

Agreed both points.

> PGW is a router, and in this case for PD it can be either a relay or
> a DHCPv6 server, perhaps with a diameter backend. Depends on how you
>  define it, is a DHCPv6-PD delegating router asking Diameter what
> prefix to assign, actually a relay or a server? I don't think it
> matters anyway, it ends up the same thing.
> 
> Nontheless, there is no fundamentally different about this, to any
> other situation with a PPPoE terminating BNG for instance.

Well, is the BNG the equivalent of a PGW?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Nov 2017 07:51:43 +0100 (CET)

> Well, is the BNG the equivalent of a PGW?

No. It's similar to a PGW but for PPPoE, typically used for *DSL, PON etc. 
So it's just a fancy word for "router" with some added functions.

---

From: DY Kim <[email-masked]>
Date: Tue, 14 Nov 2017 17:34:29 +0900

Apology to James. My message is not meant to be directed against James message.

---
DY

> On 14 Nov 2017, at 11:59, DY Kim <[email-masked]> wrote:
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 Nov 2017 16:47:05 +0800

Suresh,

Thanks for summarizing.

On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
> Given that the mechanism has been implemented and deployed by the 
> authors, I have a hard time taking this claim at face value. Providing 
> an unique prefix per host has been standard practice in 3GPP mobile 
> networks for the past *15 years*. based on recommendations from the IETF 
> back at that time. When a mobile attaches, there is state created on the 
> first hop router that does exactly what this draft wants to do. The only 
> issue I see is a lack of mechanism to clean up stale prefixes if the 
> hosts go away, but depending on the deployment this may or may not be an 
> issue.

The draft is claiming more general applicability that what I understand 
has been implemented and/or specified in the draft, in particular when 
it comes to  being able to reclaim the allocated prefixes when the host 
goes away. The fact that this has been solved in particular contexts 
(such as the 3GPP one) when there is some other mechanisms to detect 
when the host goes away doesn't provide any useful information to the 
Internet community how to make this work in the general case, nor any 
indication that it can be made to work in an interoperable way in the 
general case.

My attempt to find out what has actually been implemented to handle 
hasn't indicated that there is any agreement or any common way to 
implement the reclaim in the general case.

Hence I think the current general applicability is misplaced and if this 
draft is implemented it would be a nice excuse to consume all of the 
IPv6 address space since there is no robust way to reclaim the allocated 
prefixes.

Does the IETF really want to make such a statement?

Note that I would have no issue with publishing what has been 
implemented (in 3GPP and/or Cablelabs specifications) but scoped to 
those environments with their specific reclaim mechanisms.

Regards,
    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 23:08:16 +1300

> IPv6 address space since there is no robust way to reclaim the allocated 

That seems a bit alarmist. I don't think the RIRs will be handing out
IPv6 /16 prefixes because operators have lost millions of prefixes
and don't know where they are. Clearly an implementation of this
is going to have a mechanism for recycling these prefixes when
the host has been inactive for X amount of time, or has gone
physically off line, or whatever criterion they prefer to use.
Do we need to specify that? It isn't a wire protocol. 
(Another way to look at it is that the lifetime of the implied
prefix delegation is identical to the advertised router lifetime.
The host doesn't know it's getting a prefix, it just hears about
a router with a certain lifetime. If that isn't refreshed, it
can no longer send packets and the address will also vanish.)

   Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Nov 2017 09:36:18 -0600

> Info (and getting it out the door)?

I'd be fine with Informational.

> painful process and taken up way more of your time than it should

Don't worry about it, you have simply occupied us so we didn't have start
another round of the RFC4291bis discussion. :)

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Nov 2017 09:37:12 -0600

On Mon, Nov 13, 2017 at 10:23 PM, Lorenzo Colitti <[email-masked]>
wrote:

> is it worth asking that question on a new thread that is narrowly scoped
> to that question? There's a lot of discussion still on this thread that
> might cloud the response.
>

+1

---

From: james woodyatt <[email-masked]>
Date: Tue, 14 Nov 2017 10:28:43 -0800

> Regardless of people claiming on this thread that the IESG chose this to be a BCP, it is the *v6ops WG* that decided to send this in as BCP. The document was IETF Last Called as BCP way before it e…

In light of its other deficiencies that I’ve previously complained about (lack of clarity about some significant contingencies, e.g., reclaiming prefixes, ND redirects, et cetera), I’d be marginally happier with Informational rather than Best Current Practice.

---

From: Gert Doering <[email-masked]>
Date: Tue, 14 Nov 2017 21:16:37 +0100

Hi,

On Tue, Nov 14, 2017 at 10:28:43AM -0800, james woodyatt wrote:
> In light of its other deficiencies that I???ve previously complained
> about (lack of clarity about some significant contingencies, e.g.,
> reclaiming prefixes, ND redirects, et cetera), I???d be marginally
> happier with Informational rather than Best Current Practice.

+1

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: Fernando Gont <[email-masked]>
Date: Fri, 17 Nov 2017 15:44:57 +0800

Hello, Suresh,

On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
> Hi all,
>   I would like to summarize the issues that have been brought up, along
> with my views (I apologize for the long mail but I think it is warranted
> in this case)

Thanks for the summary!

> hosts go away, but depending on the deployment this may or may not be an

I don't think anyone has argued that the mechanism "does not work".

The issue raised has had to do with two things:

1) Reduced resiliency of SLAAC as a result of the required (previously
inexistent) state

2) The security implications associated with 1)

This means that SLAAC can break in new ways, and also that attackers can
attack SLAAC in new ways.

FWIW, the motivation for raising this discussion was the reduced
resiliency and reduced security of the corresponding deployment of
SLAAC. Essentially, it was either "bad timing" (on my side, as it
happened), or "worse timing" ( on my side, too -- i.e. not raise the
issue at all, and then just see the aforementioned issues happen). The
fact that the document is bcp made the above considerations even more of
a concern, since we are telling all IPv6 deployments that this document
is the way to go.

Thanks,