Virtual Subnet Selection Options for DHCPv4 and DHCPv6
draft-ietf-dhc-vpn-option-15

[Ballot discuss]
1. From section 5, "A relay agent which receives a DHCP request from a DHCP client on a VPN SHOULD include Virtual Subnet Selection information in the DHCP packet prior to forwarding the packet on to the DHCP server unless inhibited from doing so by configuration information or policy to the contrary." This reflects an implicit requirement; that requirement should be made explicit. - "DHCP relay agent implementations MUST provide a configuration knob to inhibit this behavior." (I'm not sure how you expect policy to be specified, but with the configuration knob, a policy might use the knob to enforce a policy.)

[Ballot comment]
I modified this discuss to add some more nits I found:

I'm curious about the answer to David's discuss.

Nits:

s3.2: r/see Section 35./see Section 3.5.

s3.3: r/This sub-option only only/This sub-option only

s5: r/DHCPvr4/DHCPv4

IANA has questions about the last action for draft-ietf-dhc-vpn-option-14.txt:

ACTION 1:

Upon approval of this document, IANA will make the following
changes in the "BOOTP Vendor Extensions and DHCP Options" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters

OLD:
Tag Name Data Length Meaning Reference
--- ------------------------------- --------- ------ ---------
221 Virtual Subnet Selection Option (Tentatively Assigned - 2005-06-23)

NEW:

Tag Name Data Length Meaning Reference
--- ------------------------------ ---------- ------- ---------
221 Virtual Subnet Selection Option [RFC-to-be]


ACTION 2:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Relay Agent Sub-Option Codes" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters

Code Sub-Option Description Reference
---- ---------------------- ---------
TBD(151) Virtual Subnet Selection Sub-Option [RFC-to-be]


ACTION 3:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Relay Agent Sub-Option Codes" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters

Value Description Reference
----- ----------- ---------
TBD VSS-control [RFC-to-be]


ACTION 4:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters

Value Description Reference
----- ----------- ---------
TBD OPTION_VSS [RFC-to-be]


ACTION 5:

Upon approval of this document, IANA will create the following registry:

Registry Name:
Registration Procedures: IETF Review (note: RFC5226 replaced the "IETF Consensus" policy with "IETF Review")

QUESTIONS: In which page should we create this registry? Which heading at http://www.iana.org/protocols should it be filed under? What are the possible values? Should any values be marked "reserved"?

[Ballot comment]
This is a fine document. There is one issue I'd like to mention, namely, the term "NVT ASCII VPN identifier" is underspecified. This term might refer to something like "an identifier containing characters only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using the Network Virtual Terminal (NVT) encoding [RFC5198]". If that is more accurate, feel free to use the text or initiate a conversation about appropriate changes. Also, please expand "NVT" on first use.

[Ballot comment]
This is a fine document. There is one issue I'd like to mention, namely, the term "NVT ASCII VPN identifier" is underspecified. This term might refer to something like "an identifier containing characters only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using the Network Virtual Terminal (NVT) encoding [RFC5198]". If that is more accurate, feel free to use the text or initiate a conversation about appropriate changes.

[Ballot discuss]
1. From section 5, "A relay agent which receives a DHCP request from a DHCP client on a VPN SHOULD include Virtual Subnet Selection information in the DHCP packet prior to forwarding the packet on to the DHCP server unless inhibited from doing so by configuration information or policy to the contrary." This reflects an implicit requirement; that requirement should be made explicit. - "DHCP relay agent implementations MUST provide a configuration knob to inhibit this behavior." (I'm not sure how you expect policy to be specified, but with the configuration knob, a policy might use the knob to enforce a policy.)

2. In section 5.1,  "In some cases, a DHCP server may use the Virtual Subnet Selection sub-option or option to inform a relay agent that a particular DHCP client is associated with a particular VPN. It does this by sending the Virtual Subnet Selection sub-option or option with the appropriate information to the relay agent in the relay-agent- information option for DHCPv4 or the Relay-reply message in DHCPv6. If the relay agent cannot respond correctly to the DHCP server's requirement to place the DHCP client into that VPN (perhaps because it has not been configured with a VPN that matches the VSS information received from the DHCP server) it MUST drop the packet and not send it to the DHCP client."

if a relays requests a specific VPN, but the server returns an
address not within that VPN, then the relay should drop the packet. Should the
relay let the server know that it dropped the packet and why? (maybe sending a release packet?)
Otherwise, Won't the server assume the address has actually been assigned to the client, thus reducing the
pool of available addresses? Could an attacker, masquerading as a relay-agent use this behavior to create a DoS attack?

[Ballot comment]
The Gen-ART Review by Roni Even on 1-Jan-2012 includes some editorial
  suggestions.  Please consider them.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07005.html

State changed to In Last Call from In Last Call.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: REVISED Last Call:  (Virtual Subnet Selection Options for DHCPv4 and DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Note that this document has been
extensively revised based on previous IESG review, and this is a
second IETF Last Call on this document.  Please send substantive
comments to the ietf@ietf.org mailing lists by 2012-01-04.
Exceptionally, comments may be sent to iesg@ietf.org instead.  In
either case, please retain the beginning of the Subject line to allow
automated sorting.

Abstract


  This memo defines a Virtual Subnet Selection (VSS) option for each of
  DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay-
  agent-information option.  These are intended for use by DHCP
  clients, relay agents, and proxy clients in situations where VSS
  information needs to be passed to the DHCP server for proper address
  or prefix allocation to take place.

  For the DHCPv4 option and relay-agent-information sub-option, this
  memo documents existing usage as per RFC 3942 [RFC3942].  This memo
  updates RFC 3046 [RFC3046] regarding details relating to copying of
  sub-options (see Section 8).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1245/

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Virtual Subnet Selection Options for DHCPv4 and DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines a Virtual Subnet Selection (VSS) option for each of
  DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay-
  agent-information option.  These are intended for use by DHCP
  clients, relay agents, and proxy clients in situations where VSS
  information needs to be passed to the DHCP server for proper address
  or prefix allocation to take place.

  For the DHCPv4 option and relay-agent-information sub-option, this
  memo documents existing usage as per RFC 3942 [RFC3942].  This memo
  updates RFC 3046 [RFC3046] regarding details relating to copying of
  sub-options (see Section 8).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1245/

[Ballot comment]
I support Jari's discuss with respect to differentiating between relay and client behavior.

To my reading, the only scenarios that are known to be useful involve VSS-aware relays
and clients that are not VSS-aware.  However, the document indicates clients can make use
of this option.

[Ballot discuss]
Dave Harrington's secdir/opsdir review has not received a response (to my knowledge, anyway.)
I am particularly interested in the authors' feelings on identifying known mitigation
strategies, as suggested in the secdir portion of the review.

[Ballot comment]
I support Jari's discuss with respect to differentiating between relay and client behavior.

To my reading, the only scenarios that are known to be useful involve VSS-aware relays
and clients that are not VSS-aware.  However, the document indicates clients can make use
of this option.

[Ballot comment]
Support for Dan's discuss on clarifying how to handle unknown VSS Information formats. This can be a MUST ignore if that works properly. Or if you are going to stay with SHOULD you need to define what the alternative is and that it makes sense. Or maybe you do need to define a error or response procedure.

[Ballot discuss]
I support this document and it was generally well written. However,
there are a few issues that need to be looked at before the specification
is complete. The document says:

> Thus, if a DHCPv4 relay agent has a requirement to determine if the
> address allocated by a DHCPv4 server is on a particular VPN, it must
> use some other approach than the appearance of the VSS sub-option in
> the reply packet to make this determination.

But there is no other mechanism.

I would have understood if you simply said that the document assumes
the relay and server must be configured properly and be capable of
using VSS options. And that nothing works if this assumption is broken.
But the document has many words about the situation and strong
requirements like the one quoted above. In my view, these are
confusing the message to the reader, which should be that the
mechanism defined in this document is very brittle. If that is
really the case, please say so and add sufficient warning labels
for users. But maybe that's not the case and I have misunderstood
something?

The document says:

  The typical use of the VSS option or sub-option is for the relay
  agent to know the VPN on which the DHCP client is operating.  The
  DHCP client itself does not, in this scenario, know the VPN on which
  it resides.
  ...
  In this second scenario, the DHCP client is again unaware of any VPN
  activity.
  ...
  A DHCPv4 or DHCPv6 client will employ the VSS option to communicate
  VSS information to their respective servers.  This information MUST
  be included in every message concerning any IP address on a different
  VPN than the global or default VPN.

These excerpts give an inconsistent view about what the client needs to
do. I believe a key use case is that the network handles the VPN
selection and the clients are blissfully unaware of what is going on.
This seems inconsistent with the requirement that the VPN information
MUST be included in every message that the client sends. Furthermore,
an existing client does not understand this specification, and hence
its fundamentally incapable of respecting the rules.

I would suggest that the document be corrected with respect to the
following:

1. Make it clear what its limitations are with respect relays or clients
using this option with a server that does not support the option in v4.
(Alternatively, develop an additional option that you can actually use
to verify that the server did indeed understand the VSS option.)

2. Clients need to be able to work with this, without being aware of
this specification.

[Ballot comment]
The Gen-ART Review by Spencer Dawkins on 2009-10-21 (later than usual)
  raised two questions about 2119 language in Section 5.

  > A DHCPv4 relay agent SHOULD include a DHCPv4 VSS sub-option in a
  > relay-agent-information option [RFC3046], while a DHCPv6 relay agent
  > SHOULD include a DHCPv6 VSS option in the Relay-forward message.
  >
  Is this functionality supposed to work if either SHOULD is violated?
  I'm wondering why these are not MUSTs.

  > The value placed in the Virtual Subnet Selection sub-option or option
  > SHOULD be sufficient for the relay agent to properly route any DHCP
  >
  I don't think this is a 2119 SHOULD. I'm thinking "more like a statement
  of fact" - perhaps "will be sufficient"? If it's really 2119, why
  isn't it a MUST?

[Ballot comment]
1. The Terminology section defines upstream and downstream using terms that have not been defined.
It is unclear to me whether access concentrator and subscriber are similar to server and client.

2. In section 3.4, might it be better to declare 2-254 as reserved rather than invalid?
The text says "invalid as of this memo".
Should there be a mechanism to support enterprise-specific VSS?

3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN and in the global IP space, because the address is qualified by the VPN. Is this always true? Is there any potential for conflict, such as in forwarding loops, if the two addresses spaces are handled by the same device?

4. I think section 4 would benefit from sub-sections to separate the scenarios, and all the "in this scenario" phrases could be eliminated.
Diagrams of the scenarios would be helpful.

5. Will legacy DHCP entities ignore the VSS option by default? or will the presence of the option somehow impact entity behaviors (e.g., by dropping packets)?

6. In section 5, it says the relay SHOULD insert VSS information into requests from a client. What happens if the client has inserted a VSS option? That isn't discussed.

7. Section 5 says
  "Anytime a relay agent places a VSS option or sub-option in a DHCP
  request, it MUST send it only to a DHCP server which supports the VSS
  option or sub-option." How does it know? is there an option discovery mechanism?

8. In section 5, if a relays requests a specific VPN, but the server returns an address not within that VPN, then the relay should drop the packet. Should the relay let the server know that it dropped the packet and why? Won't the server assume the address has actually been assigned to the client, thus reducing the pool of available addresses?

9. In section 5,  "If an IP address that is on the requested VPN is not required, then the relay agent is free to accept the IP address that is not on the VPN that was requested." Then why request it? Under what conditions would it not be required? how does the relay know whether it is or is not required?

10. In section 5, it says "There are only two pieces of information which can be determined ..." but the speciied behaviors could also result from mis-configuration, right? And the relay cannot tell whether it is a deliberate behavior or a mis-configuration.

11. section 5:  " Thus, if a DHCPv4 relay agent has a requirement to
determine if the address allocated by a DHCPv4 server is on a particular VPN, it must use some other approach than the appearance of the VSS sub-option inthe reply packet to make this determination." What other approach works?

12. section 5: "  Note that in some environments a relay agent may
choose to always place a VSS option or sub-option into packets and messages that it forwards in order to forestall any attempt by a downstream relay agent or client to specify VSS information.  In this case, a type field of 255 is used to denote the global, default VPN.  When the type field of 255 is used, there MUST NOT be any additional VSS
Information in the VSS option."  This section does not say that the relay must check to make sure there is no existing VSS option. Section 5 talks about relays inserting VSS options, but does not specify that the relay must check that no VSS=255 is present in the message already.
But section 7.3 talks about resolving conflicting VSS options. I am not sure the potential conflicts abd resolutions are covered adequately.

13. section 5.1 what does "if the relay agent is unable to honor the server requirement" mean? This could be made less ambiguous.

14. section 5.1 "  The DHCP server MUST NOT place VSS information in
an outgoing packet if the relay agent or DHCP client is unprepared to properly interpret the VSS information." This seems ambiguous. How will the server know if the other entities can properly interpret the VSS information?

s/send in/insert/

15. Section 4 says "The DHCP client, in this scenario, does not know the VPN on which it resides. Section 6 says "A DHCPv4 or DHCPv6 client will employ the VSS option to communicate VSS information to their respective servers.  This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN."
These statements seem to conflict regarding the client's knowledge.

16. section 6: "  Clients should be aware that some DHCP servers will
return a VSS option with different values than that which was sent in.  In addition, a client may receive a response from a DHCP server with a VSS option when none was sent in by the Client."

So should subsequent messages from the client use the original VSS information or the server-returned or relay-returned VSS info?

Can a return message contain multiple VSS options? If I read the document correctly, multiple relays can add their own VSS options, and a server typically copies all the options. If a client is expected to include the VSS option information in subsequent messages, does it include multiple VSS options? The second paragraph of 6 says that is not allowed.

17. The terminology issue concerns the use of the word "global"
for non-VPN addresses. According to the use of this term, also a "private" IP address, such as 10.X.X.X, is called "global".
Is it appropriate calling it so even if this address is usually called "private" and is not globally routable?

The draft says in line 6 of the second paragraph of section 4:
" ... the IP address space is in the global or default VPN used throughout the Internet". Are private IP addresses used throughout the Internet? Maybe ...

For me this terminology choice is confusing. I would rather rename it or at least add an entry to the terminology section that "global"
does not cover public IP addresses only but includes also private ones.

----

18. In lines 3-5 of the 3rd paragraph of section 4 the draft says:
"There is no conflict in this allocation, since the clients have essentially different IP addresses. Shouldn't it be different "IP address spaces" instead of "IP addresses"? Earlier in this paragraph you say the the IP addresses may be the same. Only the address spaces are different.

----

19. page 4, 4th paragraph:
"It is important to ensure that each entity in this scenario ..."
As far as I understand this applies only to the DHCP relay and server and not to the client. The client would be an antity in the scenario to which it is not important to ensure this.
If I'm correct, please change the text accordingly.

----

20. section 6, last paragraph:
Here "should" and "should not" are used. Shouldn't they get replaced by "SHOULD" and "SCHOULD NOT"?

21. section 1, lines 6-7:
"The configured rates are below the rate of the link ..."
would "the rate of the link" be "the maximum rate of the link"?

[Ballot discuss]
The OPS-DIR reviews performed by Juergen Quittek and David Harrington raised a number of issues which I believe need to be addressed before this documment can be approved:

1. It looks like in several cases there is an explicit concern of the operational impact of deploying agents that use the VSS sub-options with servers that do not use it. 

  Section 4 says "Deploying relay
  agents which support and emit VSS sub-options in concert with DHCPv4
  servers which do not support the VSS option or sub-option as defined
  in this document SHOULD NOT be done, as such an ensemble will not
  operate correctly together because all of the IP addresses will be
  allocated from the global or default VPN regardless of the VPN on
  which the client's reside."

and also:

  "There are many other scenarios which can be created with multiple
  relay agents each inserting VSS information into different Relay-
  forward messages, relay agent VSS information conflicting with client
  VSS information, or DHCP server VSS information conflicting with
  relay agent and client VSS information.  Since these scenarios do not
  describe situations that are useful today, specifying precisely how
  to resolve all of these conflicts is unlikely to be valuable in the
  event that these scenarios actually become practical in the future.

  The current use of the VSS option and sub-option require that each
  entity knows the part that it plays in dealing with VPN data.  Each
  entity -- client, relay agent or agents, and server -- SHOULD know
  through some policy or configuration beyond the scope of this
  document whether it is responsible for specifying VPN information
  using the VSS option or sub-option or responsible for responding to
  VSS information specified by another entity, or simply ignoring any
  VSS information which it might see.

  Some simple conflict resolution approaches are discussed below, in
  the hopes that they will cover simple cases that may arise from
  scenarios beyond those envisioned today.  However, for more complex
  scenarios, or simple scenarios where appropriate conflict resolution
  strategies differ from those discussed in this document, a document
  detailing the usage scenarios and appropriate conflict resolution
  strategies SHOULD be created and submitted for discussion and
  approval."

or:

  section 7 says "  In either case above, care should be taken to 
  ensure that a client or
  relay agent receiving a reply containing a VSS option will correctly
  understand the VSS option.  Otherwise, the client or relay agent will
  end up using the address as though it were a global address."

I would like to understand better this negative impact and also what kind of care should be taken - especially by an operator - other then deploying full and correct VSS option aware agents and servers.

2.      VPN types 2-254 are declared to be invalid "as of this memo", but there is no discussion if and how they could become valid in the future. The IANA section unclear on whether it can or cannot be expanded in the future.

3. It is not clear how these solutions will be configured. There is quite a bit of text that says the entity "has been configured in some way"

In some cases, the configuration MUST be done correctly for the system to work, but the configuration requirements are not detailed. For example, Section 4 says "It is important to ensure that each entity ... is configured correctly." and "There is no conflict between different entities trying to specify different VSS information -- each entity knows its role through policy or configuration external to this document." and "In the event that there were more than one relay agent involved in this transaction, some external configuration or policy would be needed to inform the DHCPv6 server into which Relay-reply message the VSS option should go."

[Ballot comment]
1. The Terminology section defines upstream and downstream using terms that have not been defined.
It is unclear to me whether access concentrator and subscriber are similar to server and client.

2. In section 3.4, might it be better to declare 2-254 as reserved rather than invalid?
The text says "invalid as of this memo".
Should there be a mechanism to support enterprise-specific VSS?

3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN and in the global IP space, because the address is qualified by the VPN. Is this always true? Is there any potential for conflict, such as in forwarding loops, if the two addresses spaces are handled by the same device?

4. I think section 4 would benefit from sub-sections to separate the scenarios, and all the "in this scenario" phrases could be eliminated.
Diagrams of the scenarios would be helpful.

5. Will legacy DHCP entities ignore the VSS option by default? or will the presence of the option somehow impact entity behaviors (e.g., by dropping packets)?

6. In section 5, it says the relay SHOULD insert VSS information into requests from a client. What happens if the client has inserted a VSS option? That isn't discussed.

7. Section 5 says
  "Anytime a relay agent places a VSS option or sub-option in a DHCP
  request, it MUST send it only to a DHCP server which supports the VSS
  option or sub-option." How does it know? is there an option discovery mechanism?

8. In section 5, if a relays requests a specific VPN, but the server returns an address not within that VPN, then the relay should drop the packet. Should the relay let the server know that it dropped the packet and why? Won't the server assume the address has actually been assigned to the client, thus reducing the pool of available addresses?

9. In section 5,  "If an IP address that is
  on the requested VPN is not required, then the relay agent is free to
  accept the IP address that is not on the VPN that was requested."
Then why request it?
Under what conditions would it not be required?
how does the relay know whether it is or is not required?

10. In section 5, it says "There are only two pieces of information which can be determined ..."
but the speciied behaviors could also result from mis-configuration, right?
And the relay cannot tell whether it is a deliberate behavior or a mis-configuration.

11. section 5:  " Thus, if a DHCPv4 relay agent has a requirement to
determine if the
  address allocated by a DHCPv4 server is on a particular VPN, it must
  use some other approach than the appearance of the VSS sub-option in
  the reply packet to make this determination."
What other approach works?

12. section 5: "  Note that in some environments a relay agent may
choose to always
  place a VSS option or sub-option into packets and messages that it
  forwards in order to forestall any attempt by a downstream relay
  agent or client to specify VSS information.  In this case, a type
  field of 255 is used to denote the global, default VPN.  When the
  type field of 255 is used, there MUST NOT be any additional VSS
  Information in the VSS option."
This section does not say that the relay must check to make sure there is
no existing VSS option.
Section 5 talks about relays inserting VSS options, buit does not specify that
the relay must check that no VSS=255 is present in the message already.
But section 7.3 talks about resolving conflicting VSS options.
I am not sure the potential conflicts abd resolutions are covered adequately.

13. section 5.1 what does "if the relay agent is unable to honor the server requirement" mean?
This could be made less ambiguous.

14. section 5.1 "  The DHCP server MUST NOT place VSS information in
an outgoing packet
  if the relay agent or DHCP client is unprepared to properly interpret
  the VSS information." This seems ambiguous. How will the server know if the other entities
can properly interpret the VSS information?

s/send in/insert/

15. section 4 says "The DHCP client, in this scenario, does not know the VPN on which it resides."
    section 6 says "  A DHCPv4 or DHCPv6 client will employ the VSS
option to communicate
  VSS information to their respective servers.  This information MUST
  be included in every message concerning any IP address on a different
  VPN than the global or default VPN."
these statements seem to conflict regarding the client's knowledge.

16. section 6: "  Clients should be aware that some DHCP servers will
return a VSS
  option with different values than that which was sent in.  In
  addition, a client may receive a response from a DHCP server with a
  VSS option when none was sent in by the Client."

So should subsequent messages from the client use the original VSS information or
the server-returned or relay-returned VSS info?

Can a return message contain multiple VSS options? If I read the document correctly,
multiple relays can add their own VSS options, and a server typically copies all the
options. If a client is expected to include the VSS option information in subsequent
messages, does it include multiple VSS options? The second paragraph of 6 says that
is not allowed.

17. The terminology issue concerns the use of the word "global"
for non-VPN addresses. According to the use of this term, also a "private" IP address, such as 10.X.X.X, is called "global".
Is it appropriate calling it so even if this address is usually called "private" and is not globally routable?

The draft says in line 6 of the second paragraph of section 4:
" ... the IP address space is in the global or default VPN used throughout the Internet". Are private IP addresses used throughout the Internet? Maybe ...

For me this terminology choice is confusing. I would rather rename it or at least add an entry to the terminology section that "global"
does not cover public IP addresses only but includes also private ones.

----

18. In lines 3-5 of the 3rd paragraph of section 4 the draft says:
"There is no conflict in this allocation, since the clients have essentially different IP addresses. Shouldn't it be different "IP address spaces" instead of "IP addresses"? Earlier in this paragraph you say the the IP addresses may be the same. Only the address spaces are different.

----

19. page 4, 4th paragraph:
"It is important to ensure that each entity in this scenario ..."
As far as I understand this applies only to the DHCP relay and server and not to the client. The client would be an antity in the scenario to which it is not important to ensure this.
If I'm correct, please change the text accordingly.

----

20. section 6, last paragraph:
Here "should" and "should not" are used. Shouldn't they get replaced by "SHOULD" and "SCHOULD NOT"?

21. section 1, lines 6-7:
"The configured rates are below the rate of the link ..."
would "the rate of the link" be "the maximum rate of the link"?

[Ballot discuss]
he OPS-DIR reviews performed by Juergen Quittek and David Harrington raised a number of issues which I believe need to be addressed before this documment can be approved:

1. It looks like in several cases there is an explicit concern of the operational impact of deploying agents that use the VSS sub-options with servers that do not use it. 

  Section 4 says "Deploying relay
  agents which support and emit VSS sub-options in concert with DHCPv4
  servers which do not support the VSS option or sub-option as defined
  in this document SHOULD NOT be done, as such an ensemble will not
  operate correctly together because all of the IP addresses will be
  allocated from the global or default VPN regardless of the VPN on
  which the client's reside."

and also:

"  There are many other scenarios which can be created with
multiple
  relay agents each inserting VSS information into different Relay-
  forward messages, relay agent VSS information conflicting with client
  VSS information, or DHCP server VSS information conflicting with
  relay agent and client VSS information.  Since these scenarios do not
  describe situations that are useful today, specifying precisely how
  to resolve all of these conflicts is unlikely to be valuable in the
  event that these scenarios actually become practical in the future.

  The current use of the VSS option and sub-option require that each
  entity knows the part that it plays in dealing with VPN data.  Each
  entity -- client, relay agent or agents, and server -- SHOULD know
  through some policy or configuration beyond the scope of this
  document whether it is responsible for specifying VPN information
  using the VSS option or sub-option or responsible for responding to
  VSS information specified by another entity, or simply ignoring any
  VSS information which it might see.

  Some simple conflict resolution approaches are discussed below, in
  the hopes that they will cover simple cases that may arise from
  scenarios beyond those envisioned today.  However, for more complex
  scenarios, or simple scenarios where appropriate conflict resolution
  strategies differ from those discussed in this document, a document
  detailing the usage scenarios and appropriate conflict resolution
  strategies SHOULD be created and submitted for discussion and
  approval."

or:

section 7 says "  In either case above, care should be
taken to ensure that a client or
  relay agent receiving a reply containing a VSS option will correctly
  understand the VSS option.  Otherwise, the client or relay agent will
  end up using the address as though it were a global address."
This could have a negative impact on the existing network deployment.

I would like to understand better this 'negative impact' and also what kind of care should be take - especially by an operator - other then deploying full and correct VSS option aware agents and servers.

2.      VPN types 2-254 are declared to be invalid "as of this memo", but there is no discussion if and how they could become valid in the future. The IANA section unclear on whether it can or cannot be expanded in the future.

3. It is not clear how these solutions will be configured. There is quite a bit of text that says the entity "has been configured in some way"

In some cases, the configuration MUST be done correctly for the system to work, but the configuration requirements are not detailed. For example, Section 4 says "It is important to ensure that each entity ... is configured correctly." and "There is no conflict between different entities trying to specify different VSS information -- each entity knows its role through policy or configuration external to this document." and "In the event that there were more than one relay agent involved in this transaction, some external configuration or policy would be needed to inform the DHCPv6 server into which Relay-reply message the VSS option should go."

[Ballot comment]
Section 1
  This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
  and DHCPv6, and a DHCPv4 relay-agent-information sub-option.  These
  are intended for use by DHCP clients, relay agents, and proxy clients
  in situations where VSS information needs to be passed to the DHCP
  server for proper address or prefix allocation to take place.  If the
  receiving DHCP server understands the VSS option or sub-option, this
  information may be used in conjunction with other information in
  determining the subnet on which to select an address as well as other
  information such as DNS server, default router, etc.
What is meant by "VSS option or sub-option"? You have only mentioned a
"VSS option" and a "relay-agent-information sub-option".
I think this is just a bit of sloppy language and can be cleaned up to
match section 3 where you define two VSS options and one VSS sub-option.
You could probably say
OLD
  This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
  and DHCPv6, and a DHCPv4 relay-agent-information sub-option.
NEW
  This memo defines a Virtual Subnet Selection (VSS) option for each of
  DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay-
  agent-information option.

---

Please be careful to be consistent about naming. For example...
Section 1
  This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
  and DHCPv6, and a DHCPv4 relay-agent-information sub-option.
and
  If the allocation is being done through a DHCPv4 relay, then the
  relay sub-option defined here should be included.

[Ballot discuss]
I feel like I'm missing something here: If I have a client that has a VPN link up, and it broadcasts a DHCP message on that link, the only way a DHCP relay or a DHCP server will see that message if they themselves are part of that virtual network. So why is there a need for an option to identify the virtual network?

[Ballot comment]
5.  Relay Agent Behavior

  Anytime a relay agent places a VSS option or sub-option in a DHCP
  request, it MUST send it only to a DHCP server which supports the VSS
  option or sub-option.

Does this need to be a MUST? This seems like configuration/policy.


7.1.  Returning the DHCPv4 or DHCPv6 Option

  The appearance of the DHCPv6 VSS option in the OPTION_ORO [RFC3315]
  or the OPTION_ERO [RFC4994] should not change the processing or

"SHOULD NOT"?

  decision to return (or not to return) the VSS option as specified in
  this document.


9.  IANA Considerations

  While the type byte defined in Section 3.4 defines a number space
  that could be managed by IANA, expansion of this number space is not
  anticipated and so creation of a registry of these numbers is not
  required by this document.  In the event that additional values for
  the type byte are defined in subsequent documents, IANA should at
  that time create a registry for these type bytes.  New values for the
  type byte may only be defined by IETF Consensus, as described in
  [RFC5226].  Basically, this means that they are defined by RFCs
  approved by the IESG.

This is an interesting way of saying that new IANA registry is not needed, but then putting requirements on future documents if this registry established in the future. Is this text needed?

[Ballot comment]
5.  Relay Agent Behavior

  Anytime a relay agent places a VSS option or sub-option in a DHCP
  request, it MUST send it only to a DHCP server which supports the VSS
  option or sub-option.

Does this need to be a MUST? This seems like configuration/policy.

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
changes in the "BOOTP Vendor Extensions and DHCP Options" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

OLD:
Tag Name Data Length Meaning Reference
--- -------------------------------------------------------
---------- ------ ---------
221 Virtual Subnet Selection Option (Tentatively Assigned - 2005-06-23)

NEW:

Tag Name Data Length Meaning Reference
--- ------------------------------ ---------- ------- ---------
221 Virtual Subnet Selection Option [RFC-dhc-vpn-option-11]


Action 2:

Upon approval of this document,IANA will make the following
assignment in the "DHCP Relay Agent Sub-Option Codes" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Code Sub-Option Description Reference
---- ---------------------- ---------
TBD(151) Virtual Subnet Selection Sub-Option [RFC-dhc-vpn-option-11]


Action 3:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Value Description Reference
----- ----------- ---------
TBD OPTION_VSS [RFC-dhc-vpn-option-11]


We understand the above to be the only IANA Actions for this document.

Submission questions for "Virtual Subnet Selection Options for DHCPv4 and DHCPv6"

(1.a)  Who is the Document Shepherd for this document?  Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

John Jason Brzozowski, dhc WG co-chair
I have reviewed the document and I believe it is ready for
publication.

(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?  Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document was reviewed by key members of the dhc WG as well as non-dhc WG members.

At this time there are no concerns about the breadth and depth of the review conducted
for this document.  This document is ready for publication.

(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML?

No, the document has been thoroughly reviewed.  No additional reviews appear to be required at this time.

(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.  Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

I have no specific concerns about this document.  This document is ready for publication.

The bulk of the discussions that resulted in the version of the draft being presented to the IESG were editorial in nature or were requests for clarifying text.  There appeared to be no comments fundamentally related to the specification.

To the best of my knowledge, there are no IPR disclosures on file with the IETF related to this document.

(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was good level of WG involvement in the development leading up to the final version of this document.  There was strong consensus from a number of individuals.  There were no objections in response to the WG last call.  I believe the WG as a whole understands and agrees with the document.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

No.

(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not enough; this check needs to be thorough.  Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

All idits have been satisified.  All review criteria has been met, no additional reviews are required.

(1.h)  Has the document split its references into normative and informative?  Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?  If such normative references exist, what is the strategy for their completion?  Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative.  There are no problematic normative references.

(1.i)  Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document?  If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified?  If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations?  Does it suggest a reasonable name for the new registry?  See [RFC2434].  If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists.  It specifies reservations that are appropriate for the clearly identified existing registries.

(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

(1.k)  The IESG approval announcement includes a Document Announcement Write-Up.  Please provide such a Document Announcement Write-Up?  Recent examples can be found in the "Action" announcements for approved documents.  The approval announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract and/or introduction of the document.  If not, this may be
an indication that there are deficiencies in the abstract or introduction.

The draft documents DHCPv4 and DHCPv6 options used by client, servers, relays, and in some cases proxies to identify the VPN that a particular request originates from.  These options are intended to be used to by DHcP servers to help determine how to respond to DHCP requests.  For DHCPv4 the draft defines options in agreement with [RFC3942].

Working Group Summary
Was there anything in WG process that is worth noting?  For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was nothing controversial about this document.

Document Quality
Are there existing implementations of the protocol?  Have a significant number of vendors indicated their plan to implement the specification?  Are there any reviewers that merit special mention as having done a thorough review,  e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?  If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?  In the case of a Media Type review, on what date was the request posted?

At least one DHCP server supports this implementation.  it is also believed that at least one client implementation exists that supports the specified options for DHCPv4.

Beyond was was performed with key members of the dhc WG no special reviews were performed or required.

Personnel
Who is the Document Shepherd for this document?
Who is the Responsible Area Director?
Is an IANA expert needed?

Shepherd: John Jason Brzozowski
AD:      Ralph Droms
IANA:    N/A