Subject: [dhcwg] Echoing back options in server response

From: "gvithal ." <[email-masked]>
Date: Wed, 15 May 2013 18:30:24 +0530

Does RFC 3315 mandate that DHCPv6 server should echo back all options in
the client request message in its response even if the server does not
support a specific option.
For example, if the client message contains vendor-specific information
option (section 22.17 rfc 3315), does the server need to echo back the same
option in its response even if does not support that option.

Thanks,
Prasad

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2013 13:06:57 +0000

On May 15, 2013, at 9:00 AM, gvithal . <[email-masked]<mailto:[email-masked]>> wrote:
Does RFC 3315 mandate that DHCPv6 server should echo back all options in the client request message in its response even if the server does not support a specific option.
For example, if the client message contains vendor-specific information option (section 22.17 rfc 3315), does the server need to echo back the same option in its response even if does not support that option.

No.   There is a provision in RFC3315 that servers MAY do this, which is actually an echo of the ancient provision in RFC2131 that servers MAY do it, but I've never heard of anyone implementing this in a server, much less using it in a client.   I argued against putting this into 3315, but found myself on the rough side of consensus... :}

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 May 2013 13:15:37 +0000

Confirm Ted's answer. Not sure why a client would need this information back as it can just save it? If server supports vendor option, it would do what is required for that option ... Such as echoing back parts (or all) if that is needed.

Servers also also don't echo back anything the Relay sent except the interface-id option. Though we did define the ERO (echo reply option) to allow relay to request the server to echo back options.

- Bernie

On May 15, 2013, at 9:07 AM, "Ted Lemon" <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Wed, 15 May 2013 13:53:01 +0000

Sorry for intruding on the thread but I have a scenario that resembles this one below so will use the opportunity to ask a question.
What would be the best way to deal with this scenario below?

DHCP v4/v6 client ------- relay-agent--------BNG-------DHCP Serverv4/6

The BNG needs to extract information in various DHCP options arriving from the client side. BNG needs this in order to identify and instantiate the subscriber.
Say on BNG there is a RegExp tool that can parse DHCP options, look at them and then take internal actions based on them (assign service level to the client when the client is instantiated in the BNG).
The problem is that BNG needs this information (to instantiate subscriber) at the end of the DHCP process when receiving DHCP ACK/Reply .
The BNG looks into various options (relay-agent and client options). Some of them will not be available when the ACK/Reply arrives since DHCP4/6 server will not echo them.

So the idea is that the BNG looks in upstream DHCP packets (arriving from the client side - <Discover,Request>, <Solicit,Request>), extracts information that it needs and  inserts this information in an option that it know that the server will return.

So, my idea for DHCPv4 is that this is inserted in Option (82,9) -vendor specific relay suboption.
For DHCPv6 I would use Option 17 (Vendor-Specific Information Option).

For DHCPv6 case this should work since we would add Relay Agent Echo Request Option.

But for DHCPv4 I'm not sure what would be needed since RFC3046 says (it may return it or may not):
RFC 3046
DHCP servers unaware of the Relay Agent Information option will
ignore the option upon receive and will not echo it back on
responses.  This is the specified server behavior for unknown
options.
DHCP servers claiming to support the Relay Agent Information option
SHALL echo the entire contents of the Relay Agent Information option
in all replies.  Servers SHOULD copy the Relay Agent Information
option as the last DHCP option in the response.

Any suggestion?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, May 15, 2013 6:16 AM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] Echoing back options in server response

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 May 2013 14:05:58 +0000

I don't think it is safe to assume option 17 will be echoed back ... The processing for this option is complex as there could be several instances, some of which have special processing. Section 5.a., if taken literally, could mean a server would not echo back all instances of option 17 (and 16) if the server processing already added one. Servers ideally would factor in the enterprise id number when echoing back these, but the document was not explicit with respect to this.

If the BNG needs state, it should just keep that state. Timers can be used to remove stale data. Memory isn't that expensive now adays.

- Bernie

On May 15, 2013, at 9:53 AM, "Poscic, Kristian (Kristian)" <[email-masked]<mailto:[email-masked]>> wrote:

So the idea is that the BNG looks in upstream DHCP packets (arriving from the client side – <Discover,Request>, <Solicit,Request>), extracts information that it needs and  inserts this information in an option that it know that the server will return.

So, my idea for DHCPv4 is that this is inserted in Option (82,9) –vendor specific relay suboption.
For DHCPv6 I would use Option 17 (Vendor-Specific Information Option).

But for DHCPv4 I’m not sure what would be needed since RFC3046 says (it may return it or may not):
RFC 3046

Any suggestion?

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, May 15, 2013 6:16 AM
To: Ted Lemon
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] Echoing back options in server response

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2013 14:07:25 +0000

No server you are likely to use in a BNG scenario will fail to support RFC 3046.