Subject: [dhcwg] Some high-priority errata for RFC3315/3396...

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 03:18:51 +0000

There's been a bit of a discussion going on in the v6ops working group about a problem in the DHCP protocol that has to do with the coexistence of stateful address allocation and prefix delegation.

The problem is that it's entirely possible that a PD requesting router might also want an IP address to number its upstream interface, so it might send a DHCP Solicit message containing both an IA_NA and an IA_PD.    Suppose the DHCP server is willing to do prefix delegation, but expects the RR to do SLAAC for the upstream address.   In this case, it's going to send an IA_PD containing one or more prefixes, but an IA_NA containing no addresses.

RFC3315 wasn't written with RFC3361 in mind, so it doesn't really talk about what to do in this case.   It also doesn't address the problem of what to do if an IA_TA appears in the solicit, but the server isn't configured to offer temporary addresses.   This hasn't been much of an issue since I don't know of any clients that actually request temporary addresses, but of course it is an issue for IA_PD.

There exist two errata that address this issue: erratum 2471 and erratum 2472.   These errata propose to have the status code appear inside the IA_NA option rather than in the outer layer of the Advertise message.   A similar erratum exists for RFC3361, proposing to put the status code option in the IA_PD option instead of, similarly, in the outer layer of the packet.

In addition, the following observation has been made:

  The other unclear problem area is around how to deal with IA_PD and IA_NA:
    * Client requests both IA_NA and IA_PD in the same session, gets only IA_PD.
      - Does it fork off a separate session for IA_NA and continues sending SOLICITs for only the IA_NA?
      - Reset the DHCP client, and tries again?
      - Keeps single session, and continues to ask for IA_NA on next RENEW?
 
      all 3 behaviors have been seen in the wild plus some additional pathological cases.
      in general dealing with multiple stateful options in DHCP is underspecified.

So the topic for discussion in the working group here is as follows:

1. Is what is proposed in the errata the right thing?   Should we in fact have status codes inside of IA_* options instead of in the main packet?

2. If so, what is the full set of edits to RFC3315 and RFC3361 that are required to do this?
2a. What do we do for clients that don't implement the errata?

3. If not, what should we do instead?

4. If the client gets an IA_NA and no IA_PD, or vice versa, which of the three behaviors listed above should it follow?   Is it bad that different clients do this differently?

5. What have I missed?

Comments?   Criticisms?   Rotten tomatoes?

---

From: Ole Troan <[email-masked]>
Date: Sat, 3 Dec 2011 12:30:06 +0100

Ted,

s/3361/3633/g

phrased another way:
do we think we can do better than treating each stateful DHCPv6 option (IA_NA, IA_TA, IA_PD) as separate protocol instances?
as in:
A DHCPv6 client MUST initiate a separate session for each IA_ option it will request. DHCPv6 message behaviour and initiation will have slight variations per option type. A DHCPv6 server that has more than one stateful option to give to a client, MUST only include the requested IA_ option in any reply to the client.

cheers,
Ole

On Dec 3, 2011, at 4:18 , Ted Lemon wrote:

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Dec 2011 13:14:33 -0500

On Dec 2, 2011, at 10:18 PM 12/2/11, Ted Lemon wrote:

> [...]

For those unfamiliar with the RFC Errata process, the two errata for RFC 3315 are available at:
http://www.rfc-editor.org/errata_search.php?eid=2471
http://www.rfc-editor.org/errata_search.php?eid=2472

The related errata for RFC 3633 are at:

http://www.rfc-editor.org/errata_search.php?eid=2469
http://www.rfc-editor.org/errata_search.php?eid=2470

> 1. Is what is proposed in the errata the right thing?   Should we in fact have status codes inside of IA_* options instead of in the main packet?

In my opinion, the corrections proposed in these errata should be made.

> 2. If so, what is the full set of edits to RFC3315 and RFC3361 that are required to do this?

I think the errata specify the full set of edits required to implement the change.

> 2a. What do we do for clients that don't implement the errata?

Client processing for a status code of NoAddrsAvail in a Reply message in RFC 3315 is somewhat different from the processing of NoAddrsAvail in an Advertise message.  Section 18.1.8 of RFC 3315 specifies that the client looks for NoAddrsAvail in each IA individually.

If the server treats all clients as having implemented the errata, it will include the NoAddrsAvail in the IA_*s rather than in the main body of the Advertise messages.  If the client does not act on those NoAddrsAvail status codes will be notified of the NoAddrsAvail in the IA in the Reply message.

> 3. If not, what should we do instead?

The errata should be accepted.

> 4. If the client gets an IA_NA and no IA_PD, or vice versa, which of the three behaviors listed above should it follow?   Is it bad that different clients do this differently?

Seems to me the client should take the NoAddrsAvail as an indication that the server does not intend to fulfill the request for that IA.  I suggest the third behavior should be specified.

> 5. What have I missed?

Nothing I can think of...

> Comments?   Criticisms?   Rotten tomatoes?

Thanks for laying out the discussion as you have.  I think the answers to questions 1-3 are somewhat independent of the answers to question 4.  We can go ahead with acting on the 4 errata before we have an answer to 4.

At the same time, we need to answer 4 as soon as possible, which should be in place and specified before the expected surge in production of IPv6-compatible home gateways.

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 6 Dec 2011 12:57:57 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms
Sent: Tuesday, December 06, 2011 1:15 PM
To: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

>At the same time, we need to answer 4 as soon as possible, which should
be in place and specified before the expected surge in production of
IPv6->compatible home gateways.

I do not think it is acceptable to let different clients do three
different behaviors.  The behavior has got to be consistent for every
DHC client.  I am not going with choice 3 yet because the Renew is a
unicast message between the client and the server and now my CMTS DHCPv6
relay agent has to sniff unicast DHCPv6 messages in the fast path.  At
least the CMTS relay agent does need to track any IA_NA, IA_PD doled out
to a DHCPv6 client in the CMTS downstream.  Maybe choice 1 is fine where
the client accepts one option and then sends subsequent SOLICITs for the
other option.  To keep the server from getting pounded if choice 1 is
picked, use the new Ralph's draft SOL_MAX_RT option.    

If folks balk at choices 1 and 2, then I am still open to choice 3.

Thanks,

Hemant

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Dec 2011 14:03:28 -0500

Hemant - DHCPv6 uses multicast for all messages unless the server has explicitly sent the server-unicast option.  Read section 18 of RFC 3315.

- Ralph

On Dec 6, 2011, at 1:57 PM 12/6/11, Hemant Singh (shemant) wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
> >At the same time, we need to answer 4 as soon as possible, which should be in place and specified before the expected surge in production of IPv6->compatible home gateways.
>  
> I do not think it is acceptable to let different clients do three different behaviors.  The behavior has got to be consistent for every DHC client.  I am not going with choice 3 yet because the Renew is a unicast message between the client and the server and now my CMTS DHCPv6 relay agent has to sniff unicast DHCPv6 messages in the fast path.  At least the CMTS relay agent does need to track any IA_NA, IA_PD doled out to a DHCPv6 client in the CMTS downstream.  Maybe choice 1 is fine where the client accepts one option and then sends subsequent SOLICITs for the other option.  To keep the server from getting pounded if choice 1 is picked, use the new Ralph's draft SOL_MAX_RT option.    
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 6 Dec 2011 13:09:25 -0600

Ralph,

OK, got it.  I was confused from DHCPv4.  So when the server-unicast
option is set, then the relay does have to sniff unicast DHCPv6 messages
which is not a new problem for choice 3.  Thus I am for choice 3.

Thanks,

Hemant

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, December 06, 2011 2:03 PM
To: Hemant Singh (shemant)
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

Hemant - DHCPv6 uses multicast for all messages unless the server has
explicitly sent the server-unicast option.  Read section 18 of RFC 3315.

- Ralph

Of Ralph Droms
> >At the same time, we need to answer 4 as soon as possible, which
should be in place and specified before the expected surge in production
of IPv6->compatible home gateways.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Dec 2011 19:22:51 +0000

On Dec 6, 2011, at 2:09 PM, Hemant Singh (shemant) wrote:
OK, got it.  I was confused from DHCPv4.  So when the server-unicast
option is set, then the relay does have to sniff unicast DHCPv6 messages
which is not a new problem for choice 3.  Thus I am for choice 3.

I think we should be aware that choice 3 does have the side effect that if a DHCP that would offer an IA_NA is offline, and then comes back online, a client that follows choice 3 as I understand it will never get an IA_NA.   I realize that choice 3 (accept an offer that contains an IA_PD and no IA_NA, keep asking for IA_NA in subsequent renews, and do not fork another requestor for IA_NA) is attractive for the case where there is no DHCP server on the wire that *could* offer an IA_NA, however, since it will stop the client soliciting for an IA_NA it will never get, and hence reduce the load on the server.

Having said that, I think that DHCP currently is simply broken with respect to multiple provisioning domains on the same wire.  The case where choice 3 fails is a case where there are multiple provisioning domains on the wire.   So I think that if we solve the MPD problem, we will also have addressed the problem with choice 3.   Until we solve the MPD problem, we really can't solve the problem with choice 3.

So I am willing to provisionally agree that choice 3 is the right choice, that RFC3315bis should mandate choice 3, and that we need an additional errata that mandates choice 3.

Ralph, I have to disagree with you that simply blessing the four errata you mentioned solves this problem.   We need more text, unfortunately.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Dec 2011 14:34:14 -0500

Ted...

> Ralph, I have to disagree with you that simply blessing the four errata you mentioned solves this problem.   We need more text, unfortunately.

To clarify...  In my opinion, the errata are necessary but not sufficient.  The errata are correct taken by themselves and can be approved on their own merit.  The errata enable a solution to the problem in your original point 4, but more text is required for the complete solution.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Dec 2011 20:33:04 +0000

On Dec 6, 2011, at 2:34 PM, Ralph Droms wrote:
To clarify...  In my opinion, the errata are necessary but not sufficient.  The errata are correct taken by themselves and can be approved on their own merit.  The errata enable a solution to the problem in your original point 4, but more text is required for the complete solution.

Fair enough.   However, I think approving them by themselves creates an inconsistency in the standard that still needs to be addressed, so we have to address it before we approve them.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Dec 2011 16:07:31 -0500

> Fair enough.   However, I think approving them by themselves creates an inconsistency in the standard that still needs to be addressed, so we have to address it before we approve them.

What is the inconsistency you see?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Dec 2011 21:11:17 +0000

On Dec 6, 2011, at 4:07 PM, Ralph Droms wrote:
What is the inconsistency you see?

We're told to treat status codes as nested, but not what to do when we get an offer that contains an IA_PD and not an IA_NA, and not what to do when we receive a status code that's not nested, and not what to do as a server if we have to send status codes for both IA_PD and IA_NA.   Maybe "incomplete" is a better choice of words, but the point is that if we just make these four changes, we are going to create more permutations in acceptable set of behaviors that servers and clients may follow.   This is really bad for interoperability, and we can't easily take it back once it's done.

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Dec 2011 22:41:49 +0100

Ted,

> We're told to treat status codes as nested, but not what to do when we get an offer that contains an IA_PD and not an IA_NA, and not what to do when we receive a status code that's not nested, and…

you have all the permutations today.
I was hoping this set of changes were all done as a "package", so that we also close this last loose thread. I don't think anyone suggested only doign the 4 existing errata(?)

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Dec 2011 21:44:13 +0000

On Dec 6, 2011, at 4:41 PM, Ole Troan wrote:
you have all the permutations today.
I was hoping this set of changes were all done as a "package", so that we also close this last loose thread. I don't think anyone suggested only doign the 4 existing errata(?)

In that case we're in agreement.   I would really like it if someone else could carefully analyze the set of changes required to RFC3315 and propose them as a single erratum, and do the same for RFC3361.   I can do it, but I have a really long to-do list at the moment.   Of course, I suppose I'm not unique in this... :)

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Dec 2011 14:01:19 -0500

dhc WG - it is important that we get a discussion on these errata and related changes from which the chairs and I can determine a consensus for a solution.  If the dhc WG doesn't approve/extend/update the errata and other changes required by the errata, the work will be done elsewhere ... and it really *should* be done here in the dhc WG.

If you have questions about the nature of the problem, the use scenario, etc., please ask...

- Ralph

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 8 Dec 2011 08:38:21 +0100

All,

I think solution 3, i.e. including ia_na in renew if not received, would be ok for us.

Some additional remark/Q:
While TR181 was progressing on defining the DHCPv6 part some time ago, we've already given some feedback on the modelling, e.g. the model has been made as such that 1 DHCPv6 client can "connect" to several DHCPv6 servers at the SAME time.  So, in order to get you options, you can potentially get them from different DHCPv6 servers.  (so, not to check who can give you what options, but really to fetch options from different servers at the same time)

Now I read the below discussion on what to do if no ia_na gets provided, only ia_pd.

Maybe I'm cutting some corners here, but I think the main thing missing in the RFC3315 is a clear state machine.  This opens up the gate for interpretations.  I've asked our BBF representative back then to challenge the authors to provide us the procedure (i.e. state machine) to use when an option would have either different content, is no longer available at some server, ...  I've seen nothing on it.

Today, I've bumped onto this discussion.  As mentioned already, solution 3, including the ia_na in the renew if not received sounds reasonable to us, but I saw some other possibilities like continuing to send discovers for the ia_na only.  I must say I'm quite surprised to see this kind of proposal ??!!
The same applies here: clear state machine would help a lot in these matters.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: zaterdag 3 december 2011 12:30
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

Ted,

s/3361/3633/g

phrased another way:

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Thu, 8 Dec 2011 17:06:37 -0500

The context for this discussion is an I-D intended for publication as Informational and updating RFC 6204: "Basic Requirements for IPv6 Customer Edge Routers," draft-ietf-v6ops-6204bis.  The specific problem is defining the behavior of a IPv6 CE router that sends both an IA_PD and an IA_NA in a Request message, and receives a delegated prefix in the IA_PD but no assigned address in the IA_NA.

BTW, "this scenario can't happen" is not an answer; details available on request.

The four errata cited earlier in this thread partially solve the problem by scoping the NoAddrsAvail status code so the client can determine which prefix and address requests were not fulfilled.  However, the client's behavior after receiving NoAddrsAvail for some but not all IA_* needs to be defined.

The following requirements from draft-ietf-v6ops-6204bis are related to this issue:

   W-5:  DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
         (IA_PD) SHOULD be done as a single DHCPv6 session.

   WPD-5:  If the IPv6 CE router is configured to initiate DHCPv6 before
           receiving a Router Advertisement, it MUST also request an
           IA_NA option in DHCPv6.
 
   WPD-7:  If the IPv6 CE router requests both an IA_NA and an IA_PD
           option in DHCPv6, it MUST accept an IA_PD option in DHCPv6
           Advertise/Reply messages, even if the message does not
           contain any addresses, unless configured to only obtain its
           WAN IPv6 address via DHCPv6.

The dhc WG needs to generate a single erratum or set of errata that form a complete solution to the problem, so we can accept it/them against RFC 3315 and RFC 3633.  draft-ietf-v6ops-6204bis can then cite the erratum/errata.

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 10 Dec 2011 21:04:25 -0600

I think that later including the IA_NA in a renew for the IA_PD in the
RENEW is problematic ...

Read RFC 3315, 18.2.3:

   When the server receives a Renew message that contains an IA option

   from a client, it locates the client's binding and verifies that the

   information in the IA from the client matches the information stored

   for that client.

   If the server cannot find a client entry for the IA the server

   returns the IA containing no addresses with a Status Code option set

   to NoBinding in the Reply message.

This would require servers to remember bindings for items that they have
no leases for, which seems rather odd? When should a server 'forget' a
binding? 

I think the cleanest is to use separate requests.

What if you had two DHCPv6 servers - one that offered addresses and one
that offered prefixes ... Would the client accept both advertises?

If you have separate transactions, a lot of these issues go away.

I regret having suggested to Hemant a while ago when RFC 6204 was in
Internet-Draft stage to have the CPE make one request, not two. I think
treating the requests completely separate, while perhaps a bit less
efficient, is just so much cleaner from an implementation and testing
standpoint.

While RFC 3315 and RFC 3633 handle no address/prefix differently, I
really don't see that as such a big deal. A client can easily understand
that NoAddrsAvail applies only to addresses, not prefixes. Personally, I
would leave this alone. I really see no win to changing this because
clients will have to support BOTH the old and new standard as they
cannot assure what servers they will be communicating with - SO WHAT
BENEFIT IS THERE????? It just adds to complexity and testing. I do NOT
think this change in the errata is CORRECT. I "vote" against it.

Cisco Network Registrar DHCP server has been sending back these results
per the RFCs and it works just fine. Note that if we do send back an
IA_PD with prefix information, we "violate" RFC 3315 text that says the
NoAddrsAvail shouldn't include "other configuration" options ... so we
will send "other configuration" options back to the client *if* we send
back either IAPREFIX or IAADDR options (in the appropriate bindings).

We also discussed this issue at the DHCPv6 bakeoffs long ago.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Tuesday, December 06, 2011 2:23 PM
To: Hemant Singh (shemant)
Cc: dhc WG; Ralph Droms
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

	OK, got it.  I was confused from DHCPv4.  So when the
server-unicast
	option is set, then the relay does have to sniff unicast DHCPv6
messages
	which is not a new problem for choice 3.  Thus I am for choice
3.

I think we should be aware that choice 3 does have the side effect that
if a DHCP that would offer an IA_NA is offline, and then comes back
online, a client that follows choice 3 as I understand it will never get
an IA_NA.   I realize that choice 3 (accept an offer that contains an
IA_PD and no IA_NA, keep asking for IA_NA in subsequent renews, and do
not fork another requestor for IA_NA) is attractive for the case where
there is no DHCP server on the wire that *could* offer an IA_NA,
however, since it will stop the client soliciting for an IA_NA it will
never get, and hence reduce the load on the server.

Having said that, I think that DHCP currently is simply broken with
respect to multiple provisioning domains on the same wire.  The case
where choice 3 fails is a case where there are multiple provisioning
domains on the wire.   So I think that if we solve the MPD problem, we
will also have addressed the problem with choice 3.   Until we solve the
MPD problem, we really can't solve the problem with choice 3.

So I am willing to provisionally agree that choice 3 is the right
choice, that RFC3315bis should mandate choice 3, and that we need an
additional errata that mandates choice 3.

Ralph, I have to disagree with you that simply blessing the four errata
you mentioned solves this problem.   We need more text, unfortunately.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 10 Dec 2011 21:07:27 -0600

>Maybe I'm cutting some corners here, but I think the main thing missing
in the RFC3315 is a clear state machine.

While there is no state machine diagram, the state machine is very clear
if you do a separate requests for each IA_*. Keep-it-simple.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Thursday, December 08, 2011 2:38 AM
To: Ole Troan; Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

All,

I think solution 3, i.e. including ia_na in renew if not received, would
be ok for us.

Some additional remark/Q:
While TR181 was progressing on defining the DHCPv6 part some time ago,
we've already given some feedback on the modelling, e.g. the model has
been made as such that 1 DHCPv6 client can "connect" to several DHCPv6
servers at the SAME time.  So, in order to get you options, you can
potentially get them from different DHCPv6 servers.  (so, not to check
who can give you what options, but really to fetch options from
different servers at the same time)

Now I read the below discussion on what to do if no ia_na gets provided,
only ia_pd.

Maybe I'm cutting some corners here, but I think the main thing missing
in the RFC3315 is a clear state machine.  This opens up the gate for
interpretations.  I've asked our BBF representative back then to
challenge the authors to provide us the procedure (i.e. state machine)
to use when an option would have either different content, is no longer
available at some server, ...  I've seen nothing on it.

Today, I've bumped onto this discussion.  As mentioned already, solution
3, including the ia_na in the renew if not received sounds reasonable to
us, but I saw some other possibilities like continuing to send discovers
for the ia_na only.  I must say I'm quite surprised to see this kind of
proposal ??!!
The same applies here: clear state machine would help a lot in these
matters.

Regs
Carl

-----Original Message-----
Of Ole Troan

Ted,

s/3361/3633/g

phrased another way:
do we think we can do better than treating each stateful DHCPv6 option
(IA_NA, IA_TA, IA_PD) as separate protocol instances?
as in:
A DHCPv6 client MUST initiate a separate session for each IA_ option it
will request. DHCPv6 message behaviour and initiation will have slight
variations per option type. A DHCPv6 server that has more than one
stateful option to give to a client, MUST only include the requested IA_
option in any reply to the client.

cheers,
Ole

On Dec 3, 2011, at 4:18 , Ted Lemon wrote:

> There's been a bit of a discussion going on in the v6ops working group
about a problem in the DHCP protocol that has to do with the coexistence
of stateful address allocation and prefix delegation.
> 
> The problem is that it's entirely possible that a PD requesting router
might also want an IP address to number its upstream interface, so it
might send a DHCP Solicit message containing both an IA_NA and an IA_PD.
Suppose the DHCP server is willing to do prefix delegation, but expects
the RR to do SLAAC for the upstream address.   In this case, it's going
to send an IA_PD containing one or more prefixes, but an IA_NA
containing no addresses.
> 
> RFC3315 wasn't written with RFC3361 in mind, so it doesn't really talk
about what to do in this case.   It also doesn't address the problem of
what to do if an IA_TA appears in the solicit, but the server isn't
configured to offer temporary addresses.   This hasn't been much of an
issue since I don't know of any clients that actually request temporary
addresses, but of course it is an issue for IA_PD.
> 
> There exist two errata that address this issue: erratum 2471 and
erratum 2472.   These errata propose to have the status code appear
inside the IA_NA option rather than in the outer layer of the Advertise
message.   A similar erratum exists for RFC3361, proposing to put the
status code option in the IA_PD option instead of, similarly, in the
outer layer of the packet.
> 1. Is what is proposed in the errata the right thing?   Should we in
fact have status codes inside of IA_* options instead of in the main
packet?
> 4. If the client gets an IA_NA and no IA_PD, or vice versa, which of
the three behaviors listed above should it follow?   Is it bad that
different clients do this differently?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 10 Dec 2011 21:10:00 -0600

Simple ... fix these to specify separate requests!!!

W-5 should be:

   W-5:  DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
         (IA_PD) SHOULD NOT be done as a single DHCPv6 session - each
         SHOULD be done in a separate DHCPv6 session.

Similar changes to the others.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms
Sent: Thursday, December 08, 2011 5:07 PM
To: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

The context for this discussion is an I-D intended for publication as
Informational and updating RFC 6204: "Basic Requirements for IPv6
Customer Edge Routers," draft-ietf-v6ops-6204bis.  The specific problem
is defining the behavior of a IPv6 CE router that sends both an IA_PD
and an IA_NA in a Request message, and receives a delegated prefix in
the IA_PD but no assigned address in the IA_NA.

BTW, "this scenario can't happen" is not an answer; details available on
request.

The four errata cited earlier in this thread partially solve the problem
by scoping the NoAddrsAvail status code so the client can determine
which prefix and address requests were not fulfilled.  However, the
client's behavior after receiving NoAddrsAvail for some but not all IA_*
needs to be defined.

The following requirements from draft-ietf-v6ops-6204bis are related to
this issue:

 

The dhc WG needs to generate a single erratum or set of errata that form
a complete solution to the problem, so we can accept it/them against RFC
3315 and RFC 3633.  draft-ietf-v6ops-6204bis can then cite the
erratum/errata.

- Ralph

On Dec 6, 2011, at 4:11 PM 12/6/11, Ted Lemon wrote:

> We're told to treat status codes as nested, but not what to do when we
get an offer that contains an IA_PD and not an IA_NA, and not what to do
when we receive a status code that's not nested, and not what to do as a
server if we have to send status codes for both IA_PD and IA_NA.   Maybe
"incomplete" is a better choice of words, but the point is that if we
just make these four changes, we are going to create more permutations
in acceptable set of behaviors that servers and clients may follow.
This is really bad for interoperability, and we can't easily take it
back once it's done.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 11 Dec 2011 07:07:37 +0000

On Dec 10, 2011, at 10:04 PM, Bernie Volz (volz) wrote:
   If the server cannot find a client entry for the IA the server
   returns the IA containing no addresses with a Status Code option set
   to NoBinding in the Reply message.

This would require servers to remember bindings for items that they have no leases for, which seems rather odd? When should a server ‘forget’ a binding?

But doesn't it make sense in this case that there is no binding?   Why would the server need to remember anything?   Are you saying that the problem is that since 3315 doesn't say the server can allocate an address at this point, it can't?

Cisco Network Registrar DHCP server has been sending back these results per the RFCs and it works just fine. Note that if we do send back an IA_PD with prefix information, we “violate” RFC 3315 text that says the NoAddrsAvail shouldn’t include “other configuration” options … so we will send “other configuration” options back to the client *if* we send back either IAPREFIX or IAADDR options (in the appropriate bindings).

This is slightly OT, but if you think this is the right behavior, you should probably submit an erratum for it if you haven't already.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 11 Dec 2011 08:48:31 -0600

>Are you saying that the problem is that since 3315 doesn't say the
server can allocate an address at this point, it can't?

Correct. That is what RFC 3315 says. As the Solicit/Request didn't
return an IAADDR for the IA_NA, the binding would not exist and hence
RENEW says the server must return NoBinding status. So, that forces the
client to go back to Solicit/Request for the IA_NA.

-          Bernie

From: Ted Lemon [mailto:[email-masked]] 
Sent: Sunday, December 11, 2011 2:08 AM
To: Bernie Volz (volz)
Cc: Hemant Singh (shemant); dhc WG; Ralph Droms
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

	   If the server cannot find a client entry for the IA the
server

	   returns the IA containing no addresses with a Status Code
option set

	This would require servers to remember bindings for items that
they have no leases for, which seems rather odd? When should a server
'forget' a binding?

But doesn't it make sense in this case that there is no binding?   Why
would the server need to remember anything?   Are you saying that the
problem is that since 3315 doesn't say the server can allocate an
address at this point, it can't?

	Cisco Network Registrar DHCP server has been sending back these
results per the RFCs and it works just fine. Note that if we do send
back an IA_PD with prefix information, we "violate" RFC 3315 text that
says the NoAddrsAvail shouldn't include "other configuration" options
... so we will send "other configuration" options back to the client
*if* we send back either IAPREFIX or IAADDR options (in the appropriate
bindings).

This is slightly OT, but if you think this is the right behavior, you
should probably submit an erratum for it if you haven't already.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 11 Dec 2011 10:18:05 -0600

Bernie,

For W-5 what is the harm with keeping the SHOULD which you recommend to
change to a SHOULD NOT? I have a DHCPv6 relay agent which after reload
has to get 100K DHCPv6 clients online as expeditiously as possible.  In
such a network, I have the DHCPv6 server serving both the IA_NA and the
IA_PD so that one single SOLICIT per client gets both options to the
client.  Why send 200K SOLICITs when one can make do with 100K SOLICITs?
The CMTS DHCPv6 relay agent upstream is also a bandwidth constrained
link.  

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Saturday, December 10, 2011 10:10 PM
To: Ralph Droms; dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

W-5 should be:

- Bernie

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

 

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 11 Dec 2011 10:35:19 -0600

The Renew includes the Client Identifier option and also other IA's the client is renewing.  With the Client Identifier option the server can search for the client in the server database and find one or more IA's to return.  So seeing a new option in the Renew, why can't the server allocate a new IA_NA  to return to the client?   Since we are discussing changing RFC 3315, is such a thought (perhaps naïve - am not a DHCPv6 guru) possible for a change.   

Hemant

From: Bernie Volz (volz) 
Sent: Sunday, December 11, 2011 9:49 AM
To: Ted Lemon
Cc: Hemant Singh (shemant); dhc WG; Ralph Droms
Subject: RE: [dhcwg] Some high-priority errata for RFC3315/3396...

>Are you saying that the problem is that since 3315 doesn't say the server can allocate an address at this point, it can't?

Correct. That is what RFC 3315 says. As the Solicit/Request didn't return an IAADDR for the IA_NA, the binding would not exist and hence RENEW says the server must return NoBinding status. So, that forces the client to go back to Solicit/Request for the IA_NA.

-        Bernie

---

From: Ted Lemon <[email-masked]>
Date: Sun, 11 Dec 2011 17:05:01 +0000

On Dec 11, 2011, at 11:18 AM, Hemant Singh (shemant) wrote:
> Why send 200K SOLICITs when one can make do with 100K SOLICITs?

I think the core issue that needs to be resolved here is whether or not we _can_ make an update to the protocol that allows what you want, Hemant, or whether Bernie's position of keeping it simple is better.   Definitely at the moment option 3 is not recognized as a valid behavior in RFC3315: an RFC3315-compliant DHCP server would _always_ respond to an IA_NA that wasn't fulfilled in the original Solicit with a NoBinding status.

But as you say, Bernie's proposal requires us to send twice as many initial Solicits, and that adds up to a lot.   So that argues for the option where if there is a negative response to the IA_NA, but not the IA_PD, the client bifurcates its state machine.   This is actually something we discussed back when we were writing RFC3315, and is behavior that we anticipated then, in that case for situations where the DHCP client wanted to get addresses on two prefixes, and the DHCP server only offered addresses on one.

At the time we weren't sure when or why this would happen, so we didn't make any strong recommendations about how to do it, instead deferring to whatever insight the future might bring.   Well, now it seems that we have that insight.

> So seeing a new option in the Renew, why can’t the server allocate a new IA_NA  to return to the client?   Since we are discussing changing RFC 3315, is such a thought (perhaps naïve – am not a DHCPv6 guru) possible for a change. 

So yes, in order to get option 3, we need to change RFC3315.   We are already proposing a change, so we could do this if that were the consensus.   However, there's a bit of a choice to be made.

We could go with the dead simple option that Bernie proposes: one state machine for IA_NA, one per IA_PD.   This requires fairly minimal changes, but has a big downside in doubling the traffic to the server.

Actually, though, that's not the complete story.   Since the client will be getting a NoAddrsAvail response on the IA_NA, it will keep trying, which means that we'll actually see *substantially* more traffic in this case if we follow the "keep it simple" approach.

The same is true of the bifurcation approach.   It saves us the initial solicit packet, but none of the subsequent ones.   So in the case where there is going to be no address offered on the IA_NA, this isn't particularly winning—we still get a ton of traffic.   In the case that we have one server serving both IA_NA and IA_PD, however, this is a marginal win: it halves the traffic hitting the server.

The third case, where we make a change to RFC3315 as Hemant suggests to allow addresses to be allocated on renew, is the biggest win in terms of reducing traffic.   We can send a single solicit, and when we get the IA_PD, we give up on the IA_NA until the next renew, and trust that if addresses become available, the server we've chosen will offer us one.

Of course, the third alternative does mean that if the DHCP server that offers IA_NAs is down when a particular client first connects to the network, it will never get an IA_NA.

So I think the question that needs to be answered, if you have read this far, is whether the use case where one server serves IA_NA and a different server serves IA_PD is a realistic use case that we need to address.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 11 Dec 2011 19:08:28 -0600

>Since the client will be getting a NoAddrsAvail response
>on the IA_NA, it will keep trying, which means that we'll
>actually see *substantially* more traffic in this case if
>we follow the "keep it simple" approach.

I assume we'll be recommending Ralph's MAX_SOL_RT internet-draft to reduce this burden.

>From Hemant's message:

> For W-5 what is the harm with keeping the SHOULD which you recommend to change to a SHOULD NOT?

I guess it really doesn't matter if the client wants to try for both in a single request ... it just comes down to what happens if it gets only addresses or only prefixes - what does the client do then?

If it is supposed to keep trying (of course, adopting Ralph's MAX_SOL_RT internet-draft) for the one that it didn't get, that's fine ... just means more testing on the part of the coder. (There are other issues with piggybacking the address and prefix requests in a single "session" as the lifetimes and renewal times could be different and then either the client renews both at the earlier time or splits the requests. Most probably just renew at the earlier time.)

If the client is supposed to just wait until a "normal" RENEW and we allow the server to process the unknown binding (treating it like a REQUEST), that's fine too but it means that you can't have one server provide addresses and another prefixes (which is probably a marginal case).

It just seems to me that the client state machine is a bit easier to implement and test if you avoid putting both in a single request and treat them completely separate. Yes, it does mean more requests - but each request is also a bit simpler. It also has other benefits since it avoids confusion of 'other configuration' data - the PD related other configuration options are then easier to identify and pass on to clients eventually getting addresses from those delegated prefixes.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Sunday, December 11, 2011 12:05 PM
To: Hemant Singh (shemant)
Cc: Bernie Volz (volz); Ralph Droms; dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

> So seeing a new option in the Renew, why can't the server allocate a new IA_NA  to return to the client?   Since we are discussing changing RFC 3315, is such a thought (perhaps naïve - am not a DHCPv6 guru) possible for a change. 

The same is true of the bifurcation approach.   It saves us the initial solicit packet, but none of the subsequent ones.   So in the case where there is going to be no address offered on the IA_NA, this isn't particularly winning-we still get a ton of traffic.   In the case that we have one server serving both IA_NA and IA_PD, however, this is a marginal win: it halves the traffic hitting the server.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2011 03:08:36 +0000

On Dec 11, 2011, at 8:08 PM, Bernie Volz (volz) wrote:
It just seems to me that the client state machine is a bit easier to implement and test if you avoid putting both in a single request and treat them completely separate. Yes, it does mean more requests - but each request is also a bit simpler. It also has other benefits since it avoids confusion of 'other configuration' data - the PD related other configuration options are then easier to identify and pass on to clients eventually getting addresses from those delegated prefixes.

So you agree with Lorenzo that the O bit signifies the availability of PD information?

I think that there is no difference in the client state machine if it can bifurcate after sending a unified Solicit.   That's really a transport issue, not a state machine issue: if both state machines want to request their respective IA_NA and IA_PD at the same time, you combine them in a single solicit; otherwise you send them separately.

I think there's a better way to deal with the issue of using different servers to configure different things, which will take a bit longer to address and hence should be addressed separately.   So I'd be pretty happy to simply say that a Renew with an unsatisfied IA_NA can allocate an address for that IA_NA, and that the client should only have one state machine when it wants both an IA_NA and an IA_PD.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 11 Dec 2011 21:45:53 -0600

>So you agree with Lorenzo that the O bit signifies the availability of
PD information?

Not sure how you draw that conclusion. I didn't think we were discussing
this question.

To me M means managed stuff (i.e., Solicit with IA_NA and/or IA_PD)
whereas O means Information-Request.

-          Bernie

From: Ted Lemon [mailto:[email-masked]] 
Sent: Sunday, December 11, 2011 10:09 PM
To: Bernie Volz (volz)
Cc: Hemant Singh (shemant); Ralph Droms; dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

	It just seems to me that the client state machine is a bit
easier to implement and test if you avoid putting both in a single
request and treat them completely separate. Yes, it does mean more
requests - but each request is also a bit simpler. It also has other
benefits since it avoids confusion of 'other configuration' data - the
PD related other configuration options are then easier to identify and
pass on to clients eventually getting addresses from those delegated
prefixes.

So you agree with Lorenzo that the O bit signifies the availability of
PD information?

I think that there is no difference in the client state machine if it
can bifurcate after sending a unified Solicit.   That's really a
transport issue, not a state machine issue: if both state machines want
to request their respective IA_NA and IA_PD at the same time, you
combine them in a single solicit; otherwise you send them separately.

I think there's a better way to deal with the issue of using different
servers to configure different things, which will take a bit longer to
address and hence should be addressed separately.   So I'd be pretty
happy to simply say that a Renew with an unsatisfied IA_NA can allocate
an address for that IA_NA, and that the client should only have one
state machine when it wants both an IA_NA and an IA_PD.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2011 05:04:01 +0000

On Dec 11, 2011, at 10:45 PM, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:
Not sure how you draw that conclusion. I didn’t think we were discussing this question.
 To me M means managed stuff (i.e., Solicit with IA_NA and/or IA_PD) whereas O means Information-Request.

Hm, okay.   I drew the conclusion from the way you grouped IA_PD with other information, but I must have misunderstood.   Unfortunately, there isn't firm agreement outside of the DHCP community that the M bit applies to PD as well as regular addressing.   We never made it explicit.

---

From: Dedecker Hans <[email-masked]>
Date: Mon, 12 Dec 2011 10:30:09 +0100

Don't agree that creating separate requests for each IA_* will make the DHCPv6 client state machine simpler. Let's just think about the non IA_ options (eg DNS recursive name server) which are potentially included in the responses by the DHCPv6 servers. If for the IA_PD response the server includes DNS recursive name server option A and for IA_NA the server includes name server option B which one should be used ? Maybe this is not so important when the the reponses orginate from the same server but what if the responses come from different servers ? If everything is done in one request such complexity will not arise; also I'm wondering what the ORO option value should contain for each separate IA_x request?
To me it seems the state machine will only get complexer as the behavior should be clear/defined for all options and not only the IA_PD/IA_NA options.

Regs,
Hans  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: zondag 11 december 2011 4:07
To: Wuyts Carl; Ole Troan; Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

While there is no state machine diagram, the state machine is very clear if you do a separate requests for each IA_*. Keep-it-simple.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Thursday, December 08, 2011 2:38 AM
To: Ole Troan; Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

All,

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: zaterdag 3 december 2011 12:30
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

Ted,

s/3361/3633/g

phrased another way:

cheers,
Ole

> There's been a bit of a discussion going on in the v6ops working group
about a problem in the DHCP protocol that has to do with the coexistence of stateful address allocation and prefix delegation.
> The problem is that it's entirely possible that a PD requesting router
might also want an IP address to number its upstream interface, so it might send a DHCP Solicit message containing both an IA_NA and an IA_PD.
Suppose the DHCP server is willing to do prefix delegation, but expects
the RR to do SLAAC for the upstream address.   In this case, it's going
to send an IA_PD containing one or more prefixes, but an IA_NA containing no addresses.
about what to do in this case.   It also doesn't address the problem of
what to do if an IA_TA appears in the solicit, but the server isn't
configured to offer temporary addresses.   This hasn't been much of an
issue since I don't know of any clients that actually request temporary addresses, but of course it is an issue for IA_PD.
erratum 2472.   These errata propose to have the status code appear
inside the IA_NA option rather than in the outer layer of the Advertise
message.   A similar erratum exists for RFC3361, proposing to put the
status code option in the IA_PD option instead of, similarly, in the outer layer of the packet.
> 1. Is what is proposed in the errata the right thing?   Should we in
fact have status codes inside of IA_* options instead of in the main packet?

---

From: Ole Troan <[email-masked]>
Date: Mon, 12 Dec 2011 11:01:08 +0100

> To me it seems the state machine will only get complexer as the behavior should be clear/defined for all options and not only the IA_PD/IA_NA options.

and this doesn't only apply to IA_PD versus IA_NA. it would also apply to IA_TA, and any other stateful option that we may concoct in the future.

my assumption has been:
 - a single interface of a DHCP client is bound to a single DHCP domain.
 - in a DHCP domain all DHCP servers are operated by a single administrative entity

is it then not a configuration error that multiple DHCP servers give a different view of the world?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2011 20:26:52 +0000

On Dec 12, 2011, at 5:01 AM, Ole Troan wrote:
- a single interface of a DHCP client is bound to a single DHCP domain.
- in a DHCP domain all DHCP servers are operated by a single administrative entity

Your assumptions are essentially the assumptions we started out with, and the conclusion you draw from them is correct, as far as it goes.   I think using that conclusion to resolve the question we are discussing is fine.   However, I think that it's also turned out that the assumptions are incorrect, and we need to address that going forward.   I don't think we should try to address it as part of this discussion, however.

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 13 Dec 2011 09:35:40 +0100

Sorry, but fully disagree on a couple of things here.
1. The state machine is not very clear, maybe to some of us, but the fact that there's so much discussion today proves my point I'd say
2. As far as I know, I don't see the split (everything in separate requests) either present in this RFC
3. On one hand, you'd like to split, on the other there's the draft to avoid 'storms' (max_sol_rt) is also being dragged to the discussion, sounds a bit contradictive
4. This RFC6204bis is due to be applied on ALL CPEs, not only very powerful with huge amounts of memory and flash.  When you would start splitting up everything, you would have to keep track of each request individually, doubling (tripling,...) up the amount of memory too.

Overall, I don't think that splitting up can introduce more simplicity anyway, sounds very unlikely.

Regs
Carl

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: zondag 11 december 2011 4:07
To: Wuyts Carl; Ole Troan; Ted Lemon
Cc: dhc WG
Subject: RE: [dhcwg] Some high-priority errata for RFC3315/3396...

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Thursday, December 08, 2011 2:38 AM
To: Ole Troan; Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

All,

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: zaterdag 3 december 2011 12:30
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

Ted,

s/3361/3633/g

phrased another way:

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Tue, 13 Dec 2011 12:38:48 -0500

> Maybe I'm cutting some corners here, but I think the main thing missing in the RFC3315 is a clear state machine.  This opens up the gate for interpretations.  I've asked our BBF representative back…

As a bit of history, the WG made an explicit decision not to include a description of a state machine in RFC 3315, because the state machine in RFC 2131 (DHCPv4) was:

* observed to have had too much influence on implementors,
* necessarily incomplete, and
* not accurate relative to the formal protocol description in the text of RFC 2131.

So, can we describe the desired client behavior in the situation under discussion?  Perhaps something like (note that I'm writing this up pretty much on the fly without any in-depth analysis):

* if an IA_* request is granted, accept and manage (Renew, etc.) the assigned addresses as described in RFC 3315
* if an IA_* request is denied with NoAddrsAvail, continue to retry the request no more frequently than allowed by the retry backoff rules; if the denied request includes a SOL_MAX_RT option, use that new value for the backoff rules
* a client may choose to optimize by combining IA_* requests in a single message, as long as the rules about frequency of requests are adhered to

This set of rules would allow independent instances of a DHCP client for each IA_*, or would allow a single client to combine the management of several IA_* into a single series of messages; e.g., include an IA_* request that was previously denied in a subsequent Renew message.  The use of the SOL_MAX_RT option would allow control of the volume of DHCPv6 traffic.

One question would be the effect on the server - is handling the various IA_* requests sufficiently orthogonal that the various requests from these rules would not represent an undue burden on the server?

Bringing this back around to the SOL_MAX_RT option draft, seems like the SOL_MAX_RT option should be scoped to the individual RAs.

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 13 Dec 2011 11:40:45 -0600

Seeing replies from Carl and Hans, even the DHCPv6 client vendors do not
like splitting each option processing in a new process.  I as a DHCPv6
relay agent vendor already said the SP DHCPv6 relay agent such as a CMTS
will have to process 100K SOLICITs vs. 200K SOLICITs if the DHCPv6
clients issue one SOLICIT for both the IA_NA and the IA_PD.  It would be
good that the SP maintain one DHCPv6 server to allocate both the IA_NA
and the IA_PD.   Then if a client asked for both options but only got
one, we have a SP provisioning system configuration error to look into.
If we can avoid separate processes to ask for each option, that would be
my preference too - subject to such a restriction, now let's see what we
have to change in the client and server behavior. 

I appreciate the time Ted and Bernie spend replying over a weekend.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Tuesday, December 13, 2011 3:36 AM
To: Bernie Volz (volz); Ole Troan; Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] Some high-priority errata for RFC3315/3396...

Sorry, but fully disagree on a couple of things here.
1. The state machine is not very clear, maybe to some of us, but the
fact that there's so much discussion today proves my point I'd say
2. As far as I know, I don't see the split (everything in separate
requests) either present in this RFC
3. On one hand, you'd like to split, on the other there's the draft to
avoid 'storms' (max_sol_rt) is also being dragged to the discussion,
sounds a bit contradictive
4. This RFC6204bis is due to be applied on ALL CPEs, not only very
powerful with huge amounts of memory and flash.  When you would start
splitting up everything, you would have to keep track of each request
individually, doubling (tripling,...) up the amount of memory too.

Overall, I don't think that splitting up can introduce more simplicity
anyway, sounds very unlikely.

Regs
Carl