[dhcwg] draft-ietf-dhc-vpn-option-12.txt

[Kim Kinnear <[e-mail]>]

Folks,

I have posted a revised copy of the VPN option draft:

http://www.ietf.org/id/draft-ietf-dhc-vpn-option-12.txt

Approximately one year ago this draft underwent an extensive
IETF/IESG review, resulting in numerous DISCUSS and COMMENTs.  I
responded in email to these items around the time that they were
logged, but only managed to update the draft to include the
changes requested at this time.

The changes were significant in that we added an entirely new
mechanism to solve a long-standing problem: a DHCPv4 relay agent
supporting the VSS capability couldn't really tell if the DHCPv4
server to which it was communicating really supported the VSS
capability.  Now it can, in a simple and straightforward way.

Other than solving that problem, the changes were many but,
at least in my view, clarified but did not change the intent
of the draft.

Regards -- Kim

-----------------------------------------------

Changes in draft-ietf-dhc-vpn-option-12.txt:

Below is a list of both substantive changes to this draft as well as
less significant and editorial changes based on the IESG review.  

For most of the changes, I've included at least some of the reviewers
whose comments prompted the change, though in many cases there were
considerable overlapping comments so I may have not caught all of the
interested parties, for which I apologize.  In addition, the ordering of
the reviewers has nothing to do with who first found the issue and who
might have simply been echoing their concerns.

Substantive changes:
--------------------

1.  Added a new DHCPv4 relay-agent-info VSS suboption type, CONTROL,
which allows inclusion of a special length one )VSS sub-option by a
relay agent.  This particular sub-option will be removed by any DHCP
server which acts on a virtual subnet selection sub-option containing
valid VSS information that is also included in the same relay-agent-info
option.

There has been considerable discussion concerning the difficulty that a
DHCPv4 relay agent would have in determining if the DHCPv4 server to
which it sent a VSS sub-option actually acted upon the VSS information
in the VSS sub-option.

The reason for this is that RFC 3046 specifies (essentially) that a
DHCPv4 server should copy all sub-options that it receives in a request
into the relay-agent-info option in the response.  Thus, a server that
didn't support the VSS sub-option would normally just copy it to the
response packet, leaving the relay agent to wonder if in fact the DHCPv4
server actually used the VSS information when processing the request.

In this revised approach, a DHCPvr4 relay agent sends in two VSS
sub-options, one with valid VSS information, and one with a VSS type of
CONTROL.  If both sub-options appear in the response from the DHCPv4
server, then the relay agent can be assured that the DHCPv4 server did
not act on the valid VSS information in one of the sub-options.  If only
the VSS sub-option with the valid information appears in the response
from the DHCPv4 server, then the relay agent can be assured that the
DHCPv4 server acted successfully on the VSS sub-option with the valid
VSS information.

This is, in reality, a relatively small change that unambiguously solves
the most contentious issue that has plagued this draft for years.

[Dan Romascanu, Magnus Westerlund, Jari Arkko]

2.  Clarified the behavior of DHCPv4 and DHCPv6 clients and their
relationship to using the VSS option.  Mostly changes at the start of
Section 6, explaining how a DHCPv4 or DHCPv6 "client" isn't necessarily
a traditional DHCPv4 or DHCPv6 client asking for an address for its own
use.

[Tim Polk, Jari Arkko]

3.  Section 4 was considered confusing.  Broke it up into multiple
sub-sections.  Added some sequence diagrams for clarity.  Added
statement that network elements MUST support "Relay agent determines
VPN" approach, SHOULD support "Server determines VPN" approach.

[Dan Romascanu, David Harrington]

Less significant and editorial changes:
---------------------------------------

1.  Changed two SHOULD's to MUST's in the beginning of Section 5, as if
the relay agent's do not do this, the protocol doesn't work.

[Russ Housley, Spencer Dawkins]

2.  Removed a SHOULD from the beginning of Section 5 concerning whether
or not a relay agent could route the returned packet from just the
information in the VSS option or sub-option, and explained more about
the situation.

[Russ Housley, Spencer Dawkins]

3.  Confusion on the comments regarding creating a registry of VSS type
information in the IANA Considerations section.  Recently other draft(s)
have appeared which already request extension to this list of VSS type
data, and so we've changed the IANA Considerations section to request
creation of a registry for these types.  New wrinkle is that the
registry needs to be related to three different options or sub-options.
Also noted that unused Type values are "reserved", not "invalid".

[Dan Romascanu, David Harrington]

4.  There were concerns that how these solutions will be configured was
not specified clearly.  That is true, and must remain so, as this
document does not and cannot specify how configuration of the network
elements involved is performed.  However, one major issue was that
mis-configuration of a DHCPv4 relay agent and a DHCPv4 server, where the
relay agent employed the VSS sub-option and the DHCPv4 server did not
support the VSS sub-option, was not detectable.  In this new revision,
such a mis-configuration is now easily detectable, which I believe
removes some of the concern over the configuration issues.  I've tried
to change some wording to make this clearer.  Also clarified what
correct configuration was, in several cases.

[Dan Romascanu, David Harrington]

5.  There were complaints about the definition of upstream and
downstream.  Removed these words from the glossary and the document.
Additionally, there were questions about access concentrator and
subscriber.  These words also do not now appear in the document.

[Dan Romascanu, David Harrington]

6.  Why would a relay agent request a particular VPN and then not
require the response to be in that VPN?  Section 5 issue.  Removed that
language.

[Dan Romascanu]

7.  DHCP server MUST NOT place VSS information in outgoing packet if the
receiver is unprepared to process it.  Of course, there is no way for
the server to know, in general, if this is true short of saying
"configure it correctly to know".  So, removed this language.

[Dan Romascanu, David Harrington]

8.  "unable to honor" regarding relay agent's ability to respond to VSS
option/sub-option information was considered ambiguous.  Took out this
language, replaced it with specific information.

[Dan Romascanu, David Harrington]

9.  Replaced "send in" with "insert".

[Dan Romascanu, David Harrington]

10.  Multipe VSS options in messages from a DHCP server must all have
the same value.  Made this clear.

[Dan Romascanu, David Harrington]

11.  Global addresses include "private" addresses (10.0.0.0, etc.) in
the context of this draft.  Fixed glossary to include this.  Also
clarified in Section 4 language concerning different IP addresses as
opposed to different IP address "spaces".

[Dan Romascanu, David Harrington, Juergen Quittek]

12.  In Section 4, there was language which implied clients had to
support the VSS option and sub-option in order to operate.  Removed that
language.

[Dan Romascanu]

13.  Change "should" and "should not" to "SHOULD" and "SHOULD NOT" at
the very end of Section 6, where how to initiate Leasequery requests is
discussed.

14.  Section 1, changed initial description VSS option to increase
clarity.

[Adrian Farrel]

15.  Put in wording to make it clear that when the document says "VSS
sub-option", that it is referring to the DHCPv4 VSS sub-option of the
DHCPv4 relay-agent-information option (option-82).

[Adrian Farrel]