Subject: [dhcwg] RFC3633 Clarification

From: "Weil, Jason" <[email-masked]>
Date: Wed, 22 Feb 2012 14:14:25 -0500

I posted this question on the v6ops list, but it is more pertinent to this list so I will repost here.

Side Question: Is the expected negative response to a Requesting Router Rebind
event on link bounce for the Server to respond with NotOnLink status as
per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but
since Confirm is not supported in RFC3633 it is a bit unclear what the
Requesting Router is expected to do next, but I personally would expect a
new SOLICIT.

Thanks,

Jason

________________________________
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: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2012 19:22:59 +0000

On Feb 22, 2012, at 2:14 PM, "Weil, Jason" <[email-masked]<mailto:[email-masked]>> wrote:

I'm not entirely clear on what question you are asking.    I think you haven't fully described the scenario that you have in mind.

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 22 Feb 2012 17:52:47 -0500

I may have answered my own question but just in case:

Use Case: A Requesting Router sends a Rebind for a prefix in an IA-PD after an interface transition event takes place. The Delegating Router determines that the prefix included in the IA_PD option is no longer usable for this link. Based on Section 12.2 of RFC3633 what is the correct response by the Delegating Router?

My read is that the Delegating Router could respond in one of two ways:

 1.  Generate a REPLY containing the IA_PD sent by the requesting router and include the prefix with lifetimes set to 0 and a Status code of NoBinding or NotOnLink.
 2.  Ignore the REBIND and silently discard the REBIND with no response at which point it is up to client to take further action.

Thanks,

Jason

The 2nd Paragraph of Section 12.2 of RFC3633 contains this sentence:

If the delegating router finds that any
of the prefixes are not in the requesting router's binding entry, the
delegating router returns the prefix to the requesting router with
lifetimes of 0.

It goes on to state:

   The delegating router behaves as follows when it cannot find a
   binding for the requesting router's IA_PD:

   Renew message:      If the delegating router cannot find a binding
                       for the requesting router's IA_PD the delegating
                       router returns the IA_PD containing no prefixes
                       with a Status Code option set to NoBinding in the
                       Reply message.

   Rebind message:     If the delegating router cannot find a binding
                       for the requesting router's IA_PD and the
                       delegating router determines that the prefixes in
                       the IA_PD are not appropriate for the link to
                       which the requesting router's interface is
                       attached according to the delegating routers
                       explicit configuration, the delegating router MAY
                       send a Reply message to the requesting router
                       containing the IA_PD with the lifetimes of the
                       prefixes in the IA_PD set to zero.  This Reply
                       constitutes an explicit notification to the
                       requesting router that the prefixes in the IA_PD
                       are no longer valid.  If the delegating router is
                       unable to determine if the prefix is not
                       appropriate for the link, the Rebind message is
                       discarded.

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: Wed, 22 Feb 2012 14:22:59 -0500
To: jason weil <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] RFC3633 Clarification

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Feb 2012 02:06:39 +0000

On Feb 22, 2012, at 5:52 PM, "Weil, Jason" <[email-masked]<mailto:[email-masked]>> wrote:
My read is that the Delegating Router could respond in one of two ways:

This is a really interesting question.   In order to answer it, it might be worth contemplating what exactly it means for a prefix to be delegated.   Does RFC3633 allow a delegating router to revoke a prefix when its lifetime is still valid?   To me that seems like an invalid operation: once the prefix has been delegated, the requesting router should have it until it expires.   If the delegating router wants to renumber the requesting router, it should do so by renewing the old prefix with a preferred lifetime of zero.   But I haven't read RFC3633 closely to see if this is in fact what it recommends.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 23 Feb 2012 10:06:21 +0100

Jason,

> 1.  Generate a REPLY containing the IA_PD sent by the requesting router and include the prefix with lifetimes set to 0 and a Status code of NoBinding or NotOnLink.

this behaviour is a "MAY". and only applies if the delegating router can somehow determine if the IA_PD option is appropriate for the link or not. I'm not quite sure how it would do that.

> 2.  Ignore the REBIND and silently discard the REBIND with no response at which point it is up to client to take further action.

both behaviours are allowed, but given that 1 is quite improbable...

cheers,
Ole

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 23 Feb 2012 07:36:35 -0600

I sent a query to Ole separately regarding this, but I think as it is related to the issue of what to do about IA_NA & IA_PD in a single request (or not), it is something for the community at large to consider ...

Given the RFC 3633 text, what is a server supposed to do if there are TWO IA_PDs in the Rebind and it only knows about 1 and not the other? (And let's assume it doesn't do the 'MAY' part of can't determine the 'onlink' nature of the prefixes in the one it doesn't know about). 

While RFC 3315 and 3633 were developed with the idea that multiple IAs would be present, I don't think we thought about these issues clearly enough to have correctly handled them all.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Thursday, February 23, 2012 4:06 AM
To: Weil, Jason
Cc: [email-masked]; Ted Lemon
Subject: Re: [dhcwg] RFC3633 Clarification

Jason,

cheers,
Ole

> If the delegating router finds that any of the prefixes are not in the 
> requesting router's binding entry, the delegating router returns the 
> prefix to the requesting router with lifetimes of 0.
> 
> It goes on to state:
> 
> 
> Side Question: Is the expected negative response to a Requesting 
> Router Rebind event on link bounce for the Server to respond with 
> NotOnLink status as per 18.1.8 of RCC3315 CONFIRM process? This is for 
> a Confirm messages but since Confirm is not supported in RFC3633 it is 
> a bit unclear what the Requesting Router is expected to do next, but I 
> personally would expect a new SOLICIT.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Feb 2012 13:39:34 +0000

On Feb 23, 2012, at 8:36 AM, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:
While RFC 3315 and 3633 were developed with the idea that multiple IAs would be present, I don't think we thought about these issues clearly enough to have correctly handled them all.

That's for sure.

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 23 Feb 2012 14:48:56 +0100

+1
Moreover.  I've suggested before to include a clear state machine drawing for DHCPv6 RFC.
This would avoid ending up with different implementations due to different interpretation of things.

Just an example: @ BBF, the DHCPv6 model has defined as such (in TR181) that a DHCPv6 client can be bound to multiple DHCPv6 servers at the same time, allowing the possibility to get options from different v6 servers.  While I would strongly doubt this to really happen in real life (yes you can have offers from multiple servers, no you should only take them from the preferred one) it could have been avoided with a clear state machine (this is not possible in v4 either).

WRT the latest discussion, having multiple IA requests, but only 1 gets served, I think it is important to not start injecting too much extra intelligence or state into the client side, i.e. not to start having separate sessions for each individual option request, this is not how DHCP was designed I think + contradicting the other discussion on MAX RT.
Different possibilities are possible: either just accept what you get, or deny if you don't get all you asked for. One could inject into the DHCPv6 client some optional configuration parameter to only bound in case of all requested stuff is received or the more liberal way (probably the default one) to just use what you get.  Problem still exist on what e.g. the renew/rebind should include etc.

Regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: donderdag 23 februari 2012 14:40
To: Bernie Volz (volz)
Cc: <[email-masked]>
Subject: Re: [dhcwg] RFC3633 Clarification

That's for sure.

---

From: [email-masked]
Date: Thu, 23 Feb 2012 12:30:25 -0500

> Moreover.  I’ve suggested before to include a clear state machine 
drawing for DHCPv6 RFC.

+1 on the state machine, it would help implementors a lot. We're seeing 
all kinds of DHCPv6 behaviors now and it hurts deployment. 

Needless to say, keeping that state machine away from undue complexity (as 
simple as possible) would also help. 

/JF

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Feb 2012 18:40:01 +0000

On Feb 23, 2012, at 8:48 AM, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:
While I would strongly doubt this to really happen in real life (yes you can have offers from multiple servers, no you should only take them from the preferred one) it could have been avoided with a clear state machine (this is not possible in v4 either).

Of course it can happen in real life if a site is multihomed.   The reason we didn't diagram a state machine is because when we did in in DHCPv4, people read the state machine diagram instead of the spec.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 23 Feb 2012 13:07:20 -0600

And the recent discussions show that such a state-machine would likely
have been wrong and, if correct, exceedingly complex!

I don't really see that a state machine adds much value and ends up, as
Ted points out, just another place where there could be conflicting
information.

The basic state machine for DHCPv6 is pretty simple. It is handling all
of the edge cases that makes life hard and also would be very difficult
to reflect in a state machine. And depending on the application, the
state machine might be different. Showing the simple state machine would
thus add little value and also misrepresent the problem.

Having said that ... If you feel strongly about a state machine, please
feel free to generate one and publish is as an Internet-Draft - the WG
can then decide whether it is something useful to adopt as a WG work
item and move it forward.

-          Bernie

From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, February 23, 2012 1:40 PM
To: Wuyts Carl
Cc: Bernie Volz (volz); <[email-masked]>
Subject: Re: [dhcwg] RFC3633 Clarification

On Feb 23, 2012, at 8:48 AM, Wuyts Carl <[email-masked]>
wrote:

	While I would strongly doubt this to really happen in real life
(yes you can have offers from multiple servers, no you should only take
them from the preferred one) it could have been avoided with a clear
state machine (this is not possible in v4 either).

Of course it can happen in real life if a site is multihomed.   The
reason we didn't diagram a state machine is because when we did in in
DHCPv4, people read the state machine diagram instead of the spec.

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 24 Feb 2012 08:11:13 +0100

Interesting statement.
So, your use case is multi-homed.  And you're getting bound to multiple servers, so getting options for different DHCpv6 servers.
As far as I can see, this is NOT what I've stated.  The BBF data model allows for a SINGLE DHCPv6 client to get options from MULITPLE DHCPv6 servers, hence getting bound to multiple ones.  Correct me if I see this wrong, but if you're multi-homed, you've multiple interfaces (one to each 'home"), hence are running multiple dhcpv6 clients, no ??

Regs
Carl

From: Ted Lemon [mailto:[email-masked]]
Sent: donderdag 23 februari 2012 19:40
To: Wuyts Carl
Cc: Bernie Volz (volz); <[email-masked]>
Subject: Re: [dhcwg] RFC3633 Clarification

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 24 Feb 2012 10:17:58 +0100

On 12-02-24 08:11, Wuyts Carl wrote:
> Interesting statement.
> 
> So, your use case is multi-homed.  And you’re getting bound to multiple
> servers, so getting options for different DHCpv6 servers.
> 
> As far as I can see, this is NOT what I’ve stated.  The BBF data model
> allows for a SINGLE DHCPv6 client to get options from MULITPLE DHCPv6
> servers, hence getting bound to multiple ones.  Correct me if I see this
> wrong, but if you’re multi-homed, you’ve multiple interfaces (one to
> each ‘home”), hence are running multiple dhcpv6 clients, no ??
Not necessarily. What happens if you have two servers from two
provisioning domains, e.g. home network with two uplinks (two CPEs
leading to two separate ISPs), connected to the same link. See
discussion in homenet WG.

BTW it's an interesting use case. It breaks things in so many unexpected
ways. From purely user's perspective, that is reasonable case. I can't
imagine how it could work today, but with proper protocol modifications,
I hope it will work one day.

Also, if you read RFC3315 closely, section 17.1.3 has this interesting
sentence: "Upon receipt of one or more valid Advertise messages, the
client selects one or more Advertise messages based upon the following
criteria". Following criteria are about server preference values. So
sending requests to more than one server at the same time is uncommon,
but valid operation.

Cheers,
Tomek

---

From: Ole Trøan <[email-masked]>
Date: Fri, 24 Feb 2012 14:59:19 +0100

Bernie,

> Given the RFC 3633 text, what is a server supposed to do if there are TWO IA_PDs in the Rebind and it only knows about 1 and not the other? (And let's assume it doesn't do the 'MAY' part of can't d…

this is no different than if there was two IA_NA's. the 3633 section is cut and paste from 3315 section 18.2.4.
when the client and server is out of sync, presumably the correct behaviour is to silently discard.

> While RFC 3315 and 3633 were developed with the idea that multiple IAs would be present, I don't think we thought about these issues clearly enough to have correctly handled them all.

I wouldn't go that far. I think the main issues are around multi-homing / multiple administrative domains / policy collisions. I don't think we have to confluence the two problems.

if we:
 - deprecated "CONFIRM" messages
 - moved T1/T2 out of the IA_* container
 - moved address specific text out of the base protocol text

then:
 - RFC3633 could be replaced with a simple "DHCP option for prefix delegation" instead of a 
   new flavour of DHCP
 - we could handle any new stateful option
 - punt on solving the issues of multi-homing / multiple administrative domains / policy collisions

cheers,
Ole