Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt

From: Kim Kinnear <[email-masked]>
Date: Mon, 05 Jan 2009 11:17:40 -0500

David, Bernie,

I'd like to try to wrap up this discussion about the use of
ERO/ORO for DHCPv6 VSS options.

I'm very uneasy with the concept of using the ORO or ERO to
specify which entity takes the lead with regard to assigning a
VPN to a particular client, as was suggested in the thread below.

In addition, the current VSS draft has specific language surrounding
the returning of the VSS option:

>7.1. Returning the DHCPv4 or DHCPv6 Option
>
>   DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option
>   processing, see below) MUST return an instance of this option in the
>   reply packet or message if the server successfully uses this option
>   to allocate an IP address, and it MUST NOT include an instance of
>   this option if the server was unable to or not configured to support
>   the requested VPN.

In addition, the server may spontaneously return the VSS option
in cases where it is taking the lead on assigning the VPN.

My point: the appearance or lack thereof of the VSS option in a
reply packet communicates important information well beyond the
scope of a "normal" configuration options (e.g., DNS server
addresses).  In particular, it may communicate information about
whether or not the server could satisfy a particular request made
by a client.  Moreover, this has been specified clearly in the
current draft.

Thus, I think that the only thing I'd add to the current draft
would be to say that the appearance of the VSS option in the ORO
or ERO should not change the processing that is otherwise
specified by the draft.

Can you both agree to that?

Thanks -- Kim

At 12:52 PM 12/18/2008, David W. Hankins wrote:
>On Wed, Dec 17, 2008 at 11:55:26PM -0500, Bernie Volz (volz) wrote:
>> I think ORO, if anything, is appropriate. ERO requests the option to be
>> echoed back, which is different, as the VPN can change. I don't think
>> the complexity of allow either ORO or ERO (and the subtle meaning
>> difference) is worth it.
>> 
>> Also, we have both the client and relay agent which could supply the
>> option; ERO is only for relays, as clients are stateful and thus there's
>> no reason they'd need something they sent in echoed.
>
>Yes; but the draft describes several different scenarios, some of
>which the relay would expect its transmitted value returned, and in
>others would expect an assignment by the server.
>
>> I don't have strong feelings either way. I lean towards considering this
>> option a "core" protocol option and thus does not require ORO - if a
>> server supports it, it must do processing to do so and hence there's
>> really little need to include it in the ORO.
>
>I don't think processing is required in all of the scenarios the draft
>supposes.
>
>So I'd lean towards putting the option on ORO; older servers with no
>support can still mimic sufficient support with manually or scripted
>values, but they won't send the value unless it's on ORO.
>
>This also simplifies DHCPv6 packet creation routines by treating more
>options consistently the same.
>
>-- 
>Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
>Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
>-- 
>David W. Hankins        "If you don't do it right the first time,
>Software Engineer                    you'll just have to do it again."
>Internet Systems Consortium, Inc.               -- Jack T. Hankins
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 5 Jan 2009 11:47:30 -0500

I fully agree that ERO should not come into play here. That would be the
wrong place for this.

I also view this as a "core" DHCPv6 protocol option (such as Server ID,
Client ID, IA_NA, ...) and thus agree that there is no need for this to
be in the ORO. I do think the document should be clear on this.

>or ERO should not change the processing that is otherwise

I would not mention the ERO option. Note also that if a relay agent were
to include this in the ERO option, the ERO processing would likely
result in the proper action:
- If the server did not include the VPN option, the received option
would be echoed.
- If the server did include the VPN option, the ERO would do nothing (as
the option is already present in the response).

- Bernie 

-----Original Message-----
From: Kim Kinnear Jr. (kkinnear) 
Sent: Monday, January 05, 2009 11:18 AM
To: David W. Hankins; DHC WG
Cc: Bernie Volz (volz); Kim Kinnear Jr. (kkinnear)
Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on
draft-ietf-dhc-vpn-option-09.txt

David, Bernie,

Thanks -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 05 Jan 2009 17:10:12 -0500

Folks,

I was just reminded of the email on Dec 23 by Alfred Hoenes
where he proposes a rather more dramatic solution to this issue.

I had missed that email, and will read it in detail and respond to
the list concerning that proposal tomorrow.

Kim

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 5 Jan 2009 17:39:59 -0800

> where he proposes a rather more dramatic solution to this issue.

I haven't taken a close enough look yet.

My inclination is that a DHCPv6 relay has no just cause to believe
it will receive the option unless it is on a request option of some
sort.  DHCPv4 relays obviously live in a stranger world.

I think in DHCPv4 it's highly unlikely a server would appropriately
support these options without some extensive changes in source in
other areas; permitting address ranges in different VPN's to overlap
as being separate 'DHCP views'.

But I suspect that requirement is much more lax in DHCPv6 use cases,
so I think it's much more reasonable to expect to see any-old-DHCPv6
server used to assign VPN's, without necessarily needing to be able
to see them as overlapping 'views'.

I admit I hadn't thought a relay could use the ORO at all, something
we might want to address in future versions of our software, but that
at least allows an admin to potentially use this option even without
explicit support, so this is something our server doesn't even do
currently.

Certainly, however, in our DHCPv6 server today, we're not going to
echo the relay-assigned VPN, if we're being used in a relay-assigns
situation, unless it's on the ERO.

Point being, it's not a real 'existing software' compatibility issue.
It's a more fuzzy future tense.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 6 Jan 2009 22:00:32 -0500

David:

If the DHCPv6 server doesn't process (support/understand) the option, it
should NOT return it. At least, to me that's the implication of the text
in 7.2 with respect to DHCPv4 where the relay agent's data is echoed and
hence a DHCPv4 relay can't tell whether the data was echoed or actually
used.

   DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option
   processing, see below) MUST return an instance of this option in the
   reply packet or message if the server successfully uses this option
-> to allocate an IP address, and it MUST NOT include an instance of
-> this option if the server was unable to or not configured to support
-> the requested VPN.

Perhaps we need to extend this to include does not support the option.

A DHCPv6 server that doesn't support/understand the option will just do
what it does today. The Client or Relay Agent can know this because it
won't get the option back in the Reply. If ERO was used, the Relay Agent
couldn't tell this. The ORO is also kind of useless because this isn't a
"other configuration" data item, but a core protocol issue.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Monday, January 05, 2009 8:40 PM
To: DHC WG
Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon
draft-ietf-dhc-vpn-option-09.txt

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 7 Jan 2009 09:24:21 -0800

> -> this option if the server was unable to or not configured to support

Hmm, I think you're right.  The relay does need a positive indication
that the server is on the same page, otherwise you run the risk of
putting the client in an inappropriate VLAN, potentially a security
issue.