Subject: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 5 Apr 2012 12:25:25 -0500

At the Paris IETF-83 DHC WG meeting there was a lot of support for (and
I believe no opposition) adopting this as a DHC WG item.

I kindly request that we adopt this document as a DHC WG work item.

-          Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Apr 2012 17:34:46 +0000

On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I believe no opposition) adopting this as a DHC WG item.

This draft documents issues that have come up involving interactions between prefix delegation and regular IP address allocation in practice.   If you would like the working group to work on documenting this, please signify by responding to this message in the affirmative.   If you don't think we should work on it, please respond in the negative.   If you have no opinion, please do not respond.

We will determine consensus on Thursday, April 19.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 5 Apr 2012 14:25:09 -0400

I support adopting this as a DHC WG work item.

Regards -- Kim

On Apr 5, 2012, at 1:34 PM, Ted Lemon wrote:

> On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Daryl Tanner <[email-masked]>
Date: Thu, 5 Apr 2012 23:58:08 +0100

I also support the adoption of this draft within the DHC WG work item

Regards
Daryl

On 5 April 2012 19:25, Kim Kinnear <[email-masked]> wrote:

> > This draft documents issues that have come up involving interactions
> between prefix delegation and regular IP address allocation in practice.
> If you would like the working group to work on documenting this, please
> signify by responding to this message in the affirmative.   If you don't
> think we should work on it, please respond in the negative.   If you have
> no opinion, please do not respond.
> >

---

From: Dedecker Hans <[email-masked]>
Date: Fri, 6 Apr 2012 08:12:26 +0200

I support adopting this as a DHC WG item.

BR,
Hans

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: donderdag 5 april 2012 19:35
To: [email-masked] WG
Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

---

From: Timothy Winters <[email-masked]>
Date: Fri, 6 Apr 2012 08:35:12 -0400

I also support this becoming a DHC WG item.

Regards,
Tim

On Apr 6, 2012, at 2:12 AM, Dedecker Hans wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf OfTed Lemon

---

From: Tina TSOU <[email-masked]>
Date: Fri, 6 Apr 2012 15:56:10 +0000

I support adopting this as WG item.

Sent from my iPhone

On Apr 6, 2012, at 5:35 AM, "Timothy Winters" <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Tim

BR,
Hans

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf OfTed Lemon
Sent: donderdag 5 april 2012 19:35
To: [email-masked]<mailto:[email-masked]> WG
Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

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

---

From: Chris Donley <[email-masked]>
Date: Fri, 6 Apr 2012 15:11:58 -0600

I support adoption of this document.

Chris

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: Thu, 5 Apr 2012 11:34:46 -0600
To: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Sat, 7 Apr 2012 08:58:59 +0530

I support adopting this document as a DHC WG item.

Thanks,

Gaurav

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Thursday, April 05, 2012 11:05 PM
To: [email-masked] WG
Subject: [dhcwg] Call for Adoption,
draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

	At the Paris IETF-83 DHC WG meeting there was a lot of support
for (and I believe no opposition) adopting this as a DHC WG item.

	I kindly request that we adopt this document as a DHC WG work
item.

This draft documents issues that have come up involving interactions
between prefix delegation and regular IP address allocation in practice.
If you would like the working group to work on documenting this, please
signify by responding to this message in the affirmative.   If you don't
think we should work on it, please respond in the negative.   If you
have no opinion, please do not respond.

---

From: Hans Liu <[email-masked]>
Date: Sat, 7 Apr 2012 17:43:19 +0800

Cheers,
Hans

On Fri, Apr 6, 2012 at 1:34 AM, Ted Lemon <[email-masked]> wrote:
> At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I
> believe no opposition) adopting this as a DHC WG item.
>
> This draft documents issues that have come up involving interactions between
> prefix delegation and regular IP address allocation in practice.   If you
> would like the working group to work on documenting this, please signify by
> responding to this message in the affirmative.   If you don't think we
> should work on it, please respond in the negative.   If you have no opinion,
> please do not respond.
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Sun, 08 Apr 2012 18:18:59 +0200

> I kindly request that we adopt this document as a DHC WG work item.
I do support this work and its adoption.

I also have couple of comments:

0. Would it be reasonable to name this work 3315bis?

1. I assume this work will also cover all combinations of
IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in
draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors
should take a closer look at it. (I'm sorry I can't offer any better
comments here. I haven't read host-gen-id yet).

2. stateful-issues draft is a very useful work. Once adopted it should
also look at CGA issues - my understanding is that it basically degrades
DHCP into registration service, compared to normal assignment service. I
haven't read CGA drafts recently, so again this is only a pointer to
something that should be looked at. It is possible that there's nothing
to do in that matter.

3. Abstract could be reworded: "the ne options for Prefix Delegation
options for DHCPv6 into DHCPv6" part is repetitive. The same is true for
first paragraph of Introduction section.

4. Text refer to different IA options as IA_. I think it would look
better without the underscore. If that is not clear, perhaps it could be
clarified that "IA option" means any of IA_NA, IA_TA or IA_PD.

5. Section 3.1 states that client MUST ignore IAs with status code
NoAddrAvail. That doesn't help much. What about other status codes?
IA_PD may be returned with NoPrefixAvail. Much better would be to say
that client MUST ignore IAs with status code other than Success.

We should also add that client SHOULD rate advertise without assigned
IAs lower than other advertises, but exact advertise rating algorithm is
up to client imlementors. For example, I would implement a client that
accepts advertise with preference=5 and all IAs assigned rather than one
with preference=10, but without IA_NA or IA_PD assigned.

6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail,
NoPrefixAvail and NotOnLink) should appear within IA options. It would
be better to not explicitely limit to those 3 status code, but say all
non-success status codes to maintain forward compatibility. Something
like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success
status codes" will do. BTW you missed UnspecFail code that is already
defined and could be used, so the text as it is does not cover all
situations from day 1.

7. It should be clarified that status codes are specified per instance
of an option, not per option type. Think about client that sends 3 IA_NA
options. It can receive 2 addresses and NoAddrAvail in the third
instance. That could be either due to pool depletion (unlikely) or
server policy that allow server to assign no more than 2 addresses per
client (likely).

8. Proposed replacement errata in section 3.2 should clarify that such
proposed action should be taken on each IA being answered.

9. Section 3.3 could mention relation between T1/T2 and information
refresh option (RFC4242). The reasonable clarification would be that
client MAY request other options in ORO when sending RENEW or REBIND.

10. Allowing PD to be confirmed with CONFIRM could be tricky. In many
deployment scenarios routing is configured separately for each delegated
prefix and server can't really say "yeah, I've never assigned you that
one, but it should be valid on your link.". I don't object allowing
IA_PD in CONFRIM, but it should be accompanied with a clause that server
MUST include IA_PD response only if it is certain that delegated prefix
is really valid. This will complicate things. What is client sends
CONFIRM with IA_NA and IA_PD and server can confirm that address is
on-link, but is not sure about prefix? There's no such status as
IdontKnow. Different IA combinations should be given more thought.

11. Section 3.5. A what??? Are you suggesting that client can send RENEW
*after* it sent RELEASE? If that is the case, I strongly object. Once
client released a lease, it has no further claims to released
address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST,
not RENEW. Also. Section 3.5 title mentions DECLINE, but there is
nothing about DECLINE in the text. Authors probably forgot adding a
sentence that DECLINE may be sent at any time when client owns a lease.

12. A question about proposed operation in section 3.6. What if there
are two servers. Imagines a case with 2 servers: one that provides
addresses and second one that provides prefixes. Client requests IA_NA
and IA_PD. What should client do?

13. In 3rd paragraph in section 3.6 it would be better to say
non-success status codes rather than NoAddrsAvail (or at least
NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail).

14. Section 3.7 is the most unfortunate. I understand the reasons that
led authors to that decision, so I sadly accept it.

Despite my comments, I strongly support this work and it adoption. It is
great that we will get this thing clarified.

Greetings to all woods dwellers,
Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 8 Apr 2012 16:26:47 -0500

Tomek:

Regarding 0, no. This work would be folded into 3315bis but it should
proceed separately. Primarily because it is needed "now" and the 3315bis
work will probably be at a much slower pace.

Regarding the other issues, NA/PD are primary target. TA isn't renewed
so it has fewer issues. But, we will look to improving the situation for
multiple IA options. And, can consider others that are in various stages
of being proposed. I am not sure we can cover all cases as I'm sure
anything we conclude might have to be revisited in the future when a new
type comes along.

This work is really related to 6204bis and the fact that the cable
market needs the router behavior to be clarified.

Thanks for your other points and we'll review and incorporate or comment
on the list as appropriate. I have not reviewed the extensive list in
details - I just wanted to send out a note to make the 'scope' of the
work a bit clearer.

I will add that for:

>11. Section 3.5. A what??? Are you suggesting that client can send
RENEW *after* it sent RELEASE?

No. If the text implies that it will need to be cleaned up. Once you
RELEASE that's it. What it was supposed to communicate is that the
client can RELEASE the IA_NA, for example, and then do a RENEW with the
IA_PD and the IA_NA to get a different address. This is not renewing the
existing address. It isn't really clear why a client would release one
lease type but not the other, so this case is probably not likely. The
more likely cases is that the client finds a DAD conflict or other issue
with the address and much DECLINE it ... and rather than having to go
back to Solicit, this allows the client the ability to RENEW the IA_PD
and include the IA_NA to get a new address (that hopefully won't have
the DAD or other conflict). Note that in this RENEW, the IA_NA would not
have an IA_ADDR option (or if it does, it would be the unspecified
address).

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Sunday, April 08, 2012 12:19 PM
To: [email-masked]; Ole Troan
Cc: Bernie Volz (volz)
Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as
WG item

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 09 Apr 2012 00:36:28 +0200

On 12-04-08 23:26, Bernie Volz (volz) wrote:
> ...
Sure. In that case pick only those of my comments that you think are
useful in 6204bis context and we can get back to the other ones later
during 3315bis work.

> have an IA_ADDR option (or if it does, it would be the unspecified
Ok, that is less scary than it initially looked. Nevertheless, I still
don't like it much. Using RENEW to request new addresses or prefixes is
wrong and will not work. It is true that to some extent REQUEST and
RENEW work in similar manner, but they were kept separated for a reason.
I would prefer to send a separate REQUEST for requesting new allocations.

Also, the idea to use RENEW to get new address/prefix will not work with
conformant implementations. Servers will send back IA, but with status
code set to NoBinding. Here's appropriate part of 3315, section 18.2.3:

   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.

So no, don't request anything new in RENEW. That's what REQUEST is for.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 8 Apr 2012 19:21:23 -0500

Tomek:

I spend some time reviewing your other points and have comments inline.
Ole's position on any of these may be different.

Thanks again for your support and feedback!! Much appreciated.

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Sunday, April 08, 2012 12:19 PM
To: [email-masked]; Ole Troan
Cc: Bernie Volz (volz)
Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as
WG item

BV> Already discussed in previous email.

BV> Already discussed in previous email.

BV> This will have to be studied further. Another interesting question
will be how this interacts with failover. We also need to look at the
usage cases - will CGA addresses and PD be used by a device (seems to
make some sense) and whether the current CGA procedures can accommodate
this in the Solicit/Advertise/Request/Reply[/Renew/Reply...] cycle.

BV> Yes.

BV> Yes. We should use better/consistent terminology. "IA options" is
probably better.

BV> This is just to replace a specific text in Section 17.1.3 that
referred to NoAddrsAvail case. I think the new text needs to be fixed as
the 'ignore any IAs' here applies to IA_NA (and perhaps IA_TA) but not
IA_PD. But to be fair, RFC 3315 only references IA_NA/IA_TA. The point
here is simply that NoAddrsAvail applies to IA_NA/IA_TA options and the
client should process these for IA_PD (and potentially other IA
options).

BV> Yes, this is a good point. Advertises with all requests satisfied
should rank higher than ones with one some. This does get complicate
fast and we want to make sure to keep it simple since in most cases
there will only be one Advertise (there usually aren't a lot of DHCP
servers on networks with very different configurations).

BV> 3.2 lists "NoAddrsAvail, NotOnlink, NoBinding" and is describing the
differences between the possible location of Status Code options in
Reply and Advertise messages.I don't think UnspecFail appears
encapsulated in an IA option (where did you find that)?

BV> I do think we need to revise the "Proposed Solution" as it isn't
just IA_NA but also IA_TA. We believe it best to keep backwards
compatibility and not change the existing behavior as we might break
client implementations if were to change this. So, we want to stick with
the current RFC 3315 behavior. What we feel we can change is that the
client SHOULD look at the other IA options that are returned and the
'other configuration' options and use them. Existing clients that follow
RFC 3315 to the letter won't as they'll ignore these Advertise messages.

BV> Actually section 17.2.2 in RFC 3315 says nothing like that. If there
are 3 IA_NA options and 2 return addresses, then the Advertise will
contain 3 IA_NA options, 2 with IA_ADDR option(s) and one with no
IA_ADDR options. The NoAddrAvail is ONLY used when the server returns NO
addresses to any IA_NA/IA_TA options.

BV> Not sure I understand your comment. I think that the text should say
this NoAddrsAvail ONLY applies to the IA_NA/IA_TA options). IA_PD is
already covered by RFC 3633. And, other IA_* options should state what
the behavior is to be (hopefully following IA_PDs lead and encapsulating
the status code into the IA option). We can't change IA_NA/IA_TA because
of backwards compatibility, but all others should follow the IA_PD lead
and place the "NoAddrsAvail" or whatever status code option inside the
IA option.

BV> Could you clarify? RFC 4242 (Information Refresh Time) states: "It
is only used in Reply messages in response to Information-Request
messages." I believe that the T1/T2 times are to cover the 'other
information' renewal.

BV> Yes, there is an I Don't Know status. The server MUST NOT Reply in
that case. Confirm has this built in. That's why I like Confirm. It
doesn't overload other messages. It doesn't require the heavier weight
processing of Renew (or Rebind). It allows for 3 responses types - On
Link (Success), NotOnLink, and I can't tell / don't know (drop Confirm).

BV> I really wonder how often this concept of the delegated prefix being
completely outside anything other servers (on the same network) know is.
In all of the PD cases I'm aware of, the other would know. Yes, I agree
it "could" happen. But in those cases if you used Renew, you'd gain
nothing since only the assigning server would be able to say yes or no.

BV> Already answers this in previous email. Yes, we need to clean up
this text. DECLINE is the more likely situation. I am not sure why a
client would Release just the address but not the prefix if it got both.
We probably should add something to the document about discouraging
releasing only 'half' the acquired leases.

BV> We have specifically indicated that this is NOT a situation we are
supporting. We consider this split administrative domains. We will need
to add text.

BV> If you look at the slide deck uploaded for IETF-83 (Paris), the last
slide has a slide about Administrative Domains. So, this is something we
will work on. The idea is fairly simple in that we'd add a new
"Administrative Domain Name" option which servers could include in
replies. The client COULD then decide which administrative domain it
wants to use and even support split domains (i.e., accept an Advertise
from one domain for addresses and another for prefixes). Clearly there
are security issues and client complexity here but if people want this,
we'll need to craft something to handle it.

BV> Note that the Authentication option already has something like this
- the "DHCP Realm". But this would be separating out this concept from
any authentication.

BV> The RFC 3315 text would only reference NoAddrsAvail. 3633 would need
to change to specify NoPrefixAvail instead of NoBinding. But NotOnLink
and UnspecFail are not applicable here (they are as already is).

BV> As mentioned above, we intend to follow on with work to address this
(see your 12).

BV> Thanks!

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 8 Apr 2012 19:27:37 -0500

> Also, the idea to use RENEW to get new address/prefix will not work
with conformant implementations.

Correct. Existing servers will respond as they have been. But clients
will be no worse off than they are today. This is probably a point that
should be made and clients that can't expect new servers will have to
live with the old behavior.

What would you propose? Doing a REQUEST hardly seems correct either.

We want to avoid separate 'state machines' in the clients and have one
set of request messages handle the client recovering.

Note also that I believe that the REBIND behavior as specified today is
BROKEN for failover. Consider the case Server A gives out a lease but
goes down before updating its partner, Server B. Server B now gets the
REBIND at T2. It would send back NoBinding as it has no record of the
client and/or bindings. This needs to change too for failover to work -
at least if we want to be consistent with the way we handle this in v4
failover.

I don't think the RENEW (or REBIND) is damaged by allowing new bindings.
The client is still asking to renew leases but to also get new ones. Why
is that so bad? The addresses (or prefix) can change in a
Renew/Rebinding, so why not allow new bindings?

Note that we are NEVER saying a client can send a RENEW or REBIND
without having at least one valid lease. It must at least have one
binding & lease.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tomek Mrugalski
Sent: Sunday, April 08, 2012 6:36 PM
To: Bernie Volz (volz)
Cc: [email-masked]; Ole Troan
Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as
WG item

On 12-04-08 23:26, Bernie Volz (volz) wrote:
> proceed separately. Primarily because it is needed "now" and the 
> 3315bis work will probably be at a much slower pace.
> ...

> the DAD or other conflict). Note that in this RENEW, the IA_NA would 
> not have an IA_ADDR option (or if it does, it would be the unspecified

I would prefer to send a separate REQUEST for requesting new
allocations.

Tomek

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Apr 2012 15:10:45 +0000

+1
Barbara

> Of Hans Liu
> Sent: Saturday, April 07, 2012 5:43 AM
> To: Ted Lemon
> Cc: [email-masked] WG
> Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-
> issues-00 as WG item
> 
> > At the Paris IETF-83 DHC WG meeting there was a lot of support for
> > (and I believe no opposition) adopting this as a DHC WG item.
> >
> > between prefix delegation and regular IP address allocation in
> > practice.   If you would like the working group to work on documenting
> > this, please signify by responding to this message in the affirmative.
> > If you don't think we should work on it, please respond in the
> > negative.   If you have no opinion, please do not respond.
> >

---

From: Bud Millwood <[email-masked]>
Date: Mon, 16 Apr 2012 11:21:38 +0200

> at least if we want to be consistent with the way we handle this in v4

RFC 3315, 18.1.8 says that if the client receives a 'NoBinding' in
response to its Rebind, it should send a Request. Does anyone know the
reasoning behind that?

Does 'NoBinding' in DHCPv6 explicitly override an existing contract
for a lease? Can the client not continue to use its lease?

- Bud

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Apr 2012 15:24:16 +0000

Reminder, we're halfway through the last call period for this document.   We've gotten a good response, so there's no need to respond if you aren't that interested, but if you are interested and haven't responded, please do.

Begin forwarded message:

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
Date: April 5, 2012 1:34:46 PM EDT
To: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>

---

From: "Weil, Jason" <[email-masked]>
Date: Mon, 16 Apr 2012 14:06:25 -0400

I am definitely interested in seeing this move forward especially for all those working on client implementations out there in the world.

Thanks,

Jason

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: Mon, 16 Apr 2012 11:24:16 -0400
To: DHC WG <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

Begin forwarded message:

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 18 Apr 2012 23:38:42 +0000

On 12-04-16 15:24, Ted Lemon wrote:
> Reminder, we're halfway through the last call period for this document.
>   We've gotten a good response, so there's no need to respond if you
> aren't that interested, but if you are interested and haven't responded,
> please do.
Ted,
I would love to see this document progress fast, but I thought that we
are in the process of adoption, not last call.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Apr 2012 02:35:06 +0000

On Apr 18, 2012, at 7:38 PM, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>> wrote:
I would love to see this document progress fast, but I thought that we
are in the process of adoption, not last call.

Oops, yes, sorry.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 19 Apr 2012 12:07:19 +0000

I've read through this informational document and am interested in its progress in the WG. +1 for the adoption. I believe the numbered (WAN model) CPE is a well-known and necessary case in broadband access (referred to BBF TR-177), which needs the support of multiple stateful options (eg. 1x IA_NA for its WAN interface & 1x IA_PD for the subscriber network) in DHCPv6.

Comments and questions:

1. The document sounds need more text on the scope of the status codes. (Section 3.2, section 3.6)
<quote>In Advertisement messages the Status code option with the NoAddrsAvail code is in the "global" scope.</quote> – Globe?
<quote>NoPrefixAvail is only applicable to IA_PD, and NoAddrsAvail is only applicable to IA_NA/IA_TA, it may be problematic to make this assumption for all status codes. </quote>  - What does the 'problematic' means here?
<quote>For backwards compatibility, the IA_NA status code can be kept in the global scope. </quote> - Globe?
<quote>For the IAs that the server has no binding for, it must reply using the same behaviour as for a Request message. That is with a "NoAddrsAvail" status. (As opposed to the currently specified NoBinding). </quote> - Status code change here?

2. Confirm message (section 3.4)
<quote>It is encouraged to use Renew instead of Confirm. </quote> Per RFC3633, DHCPv6 don't use Confirm & Decline message in PD process. Will we try to adopt these messages back again?

3. Decline message (section 3.5)
No text about Decline message in section 3.5 yet.

Best Regards,
Leaf

------------------------------------------------------------------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, April 16, 2012 11:24 PM
To: DHC WG
Subject: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

Begin forwarded message:

From: Ted Lemon <[email-masked]>
Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
Date: April 5, 2012 1:34:46 PM EDT
To: "[email-masked] WG" <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Apr 2012 13:58:48 +0000

On Apr 5, 2012, at 1:34 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
This draft documents issues that have come up involving interactions between prefix delegation and regular IP address allocation in practice.   If you would like the working group to work on documenting this, please signify by responding to this message in the affirmative.   If you don't think we should work on it, please respond in the negative.   If you have no opinion, please do not respond.

Thirteen participants spoke in favor of adopting the document, and none opposed it, so it's officially adopted as a working group item.   Would the authors please submit a new version (perhaps with edits as a result of Leaf's, Tomek's, Bud's and Bernie's comments?