diff options
Diffstat (limited to 'doc/rfc/rfc6607.txt')
| -rw-r--r-- | doc/rfc/rfc6607.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc6607.txt b/doc/rfc/rfc6607.txt new file mode 100644 index 0000000..9841d76 --- /dev/null +++ b/doc/rfc/rfc6607.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Kinnear +Request for Comments: 6607 R. Johnson +Updates: 3046 M. Stapp +Category: Standards Track Cisco Systems +ISSN: 2070-1721 April 2012 + + + Virtual Subnet Selection Options for DHCPv4 and DHCPv6 + +Abstract + + This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a + DHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options + 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-options, this + memo documents and extends existing usage as per RFC 3942. This memo + updates RFC 3046 regarding details relating to the copying of sub- + options (see Section 8). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6607. + + + + + + + + + + + + + + + +Kinnear, et al. Standards Track [Page 1] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Kinnear, et al. Standards Track [Page 2] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Virtual Subnet Selection Options and Sub-Options: Definitions ...6 + 3.1. DHCPv4 Virtual Subnet Selection Option .....................6 + 3.2. DHCPv4 Virtual Subnet Selection Sub-Option .................6 + 3.3. DHCPv4 Virtual Subnet Selection Control Sub-Option .........7 + 3.4. DHCPv6 Virtual Subnet Selection Option .....................7 + 3.5. Virtual Subnet Selection Type and Information ..............8 + 4. Overview of Virtual Subnet Selection Usage ......................8 + 4.1. VPN Assignment by the DHCP Relay Agent .....................9 + 4.2. VPN Assignment by the DHCP Server .........................12 + 4.3. Required Support ..........................................14 + 4.4. Alternative VPN Assignment Approaches .....................14 + 5. Relay Agent Behavior ...........................................15 + 5.1. VPN Assignment by the DHCP Server .........................16 + 5.2. DHCP Leasequery ...........................................17 + 6. Client Behavior ................................................17 + 7. Server Behavior ................................................19 + 7.1. Returning the DHCPv4 or DHCPv6 Option .....................20 + 7.2. Returning the DHCPv4 Sub-Option ...........................20 + 7.3. Making Sense of Conflicting VSS Information ...............21 + 8. Update to RFC 3046 .............................................22 + 9. Security Considerations ........................................22 + 10. IANA Considerations ...........................................23 + 11. Acknowledgments ...............................................24 + 12. References ....................................................25 + 12.1. Normative References .....................................25 + 12.2. Informative References ...................................25 + +1. Introduction + + There is a growing use of Virtual Private Network (VPN) + configurations. This growth comes from many areas: individual client + systems needing to appear to be on the home corporate network even + when traveling, ISPs providing extranet connectivity for customer + companies, etc. In some of these cases, there is a need for the DHCP + server to know the VPN (also called a "Virtual Subnet Selector" or + "VSS" in this document) from which an address, and other resources, + should be allocated. + + This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a + DHCPv6 VSS option, and two VSS sub-options 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. If the receiving DHCP server + + + +Kinnear, et al. Standards Track [Page 3] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + understands the VSS option or sub-options, 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. + + If the allocation is being done through a DHCPv4 relay, then the + Relay Agent Information sub-options defined here should be included. + In some cases, however, an IP address is being sought by a DHCPv4 + proxy on behalf of a client (which may be assigned the address via a + different protocol). In this case, there is a need to include VSS + information relating to the client as a DHCPv4 option. + + If the allocation is being done through a DHCPv6 relay, then the + DHCPv6 VSS option defined in this document should be included in the + Relay-forward and Relay-reply messages going between the DHCPv6 relay + and server. In some cases, addresses or prefixes are being sought by + a DHCPv6 proxy on behalf of a client. In this case, there is a need + for the client itself to supply the VSS information using the DHCPv6 + VSS option in the messages that it sends to the DHCPv6 server. + + In the remaining text of this document, when a DHCPv6 address is + indicated, the same information applies to DHCPv6 prefix delegation + [RFC3633] as well. + + In the remaining text of this document, when the term "VSS + sub-option" is used, it refers to the VSS sub-option carried in the + DHCPv4 Relay Agent Information option. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + This document uses the following terms: + + o DHCP client + + A DHCP client is a host using DHCP to obtain configuration + parameters such as a network address. + + o DHCP proxy + + A DHCP proxy is a DHCP client that acquires IP addresses not for + its own use but rather on behalf of another entity. There are a + variety of ways that a DHCP proxy can supply the addresses it + acquires to other entities that need them. + + + + +Kinnear, et al. Standards Track [Page 4] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + o DHCP relay agent + + A DHCP relay agent is an agent that transfers BOOTP and DHCP + messages between clients and servers residing on different + subnets, per [RFC951], [RFC1542], and [RFC3315]. + + o DHCP server + + A DHCP server is a host that returns configuration parameters to + DHCP clients. + + o DHCPv4 option + + A DHCPv4 option is an option used to implement a capability + defined by the DHCPv4 RFCs ([RFC2131] [RFC2132]). This option has + one-octet code and size fields. + + o DHCPv4 sub-option + + As used in this document, a DHCPv4 sub-option refers to a + sub-option of the Relay Agent Information option [RFC3046]. This + sub-option has one-octet code and size fields. + + o DHCPv6 option + + A DHCPv6 option is an option used to implement a capability + defined by the DHCPv6 RFC [RFC3315]. This option has two-octet + code and size fields. + + o Global VPN + + This term indicates that the address being described belongs to + the set of addresses not part of any VPN -- in other words, the + normal address space operated on by DHCP. This includes private + addresses -- for example, the 10.x.x.x addresses as well as the + other private subnets that are not routed on the open Internet. + + o NVT ASCII identifier + + A Network Virtual Terminal (NVT) identifier is an identifier + containing only characters from the ASCII repertoire and using the + Network Virtual Terminal encoding (see Appendix B of [RFC5198]). + + o VSS information + + VSS information provides information about a VPN necessary to + allocate an address to a DHCP client on that VPN and necessary to + forward a DHCP reply packet to a DHCP client on that VPN. + + + +Kinnear, et al. Standards Track [Page 5] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + o VPN + + This term refers to a virtual private network. A VPN appears to + the client to be a private network. + + o VPN identifier + + The VPN-ID is defined by [RFC2685] to be a sequence of 7 octets. + +3. Virtual Subnet Selection Options and Sub-Options: Definitions + + The VSS options and sub-options contain a generalized way to specify + the VSS information about a VPN. There are two options and two + sub-options defined in this section. The actual VSS information is + identical for both options and for one of the two sub-options. + +3.1. DHCPv4 Virtual Subnet Selection Option + + The format of the option is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Length | Type | VSS Info. ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code The option code (221). + + Length The option length, minimum 1 octet. + + Type and VSS Information -- see Section 3.5. + +3.2. DHCPv4 Virtual Subnet Selection Sub-Option + + This is a sub-option of the Relay Agent Information option [RFC3046]. + The format of the sub-option is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Length | Type | VSS Info. ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code The sub-option code (151). + + Length The sub-option length, minimum 1 octet. + + Type and VSS Information -- see Section 3.5. + + + +Kinnear, et al. Standards Track [Page 6] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +3.3. DHCPv4 Virtual Subnet Selection Control Sub-Option + + This is a sub-option of the Relay Agent Information option [RFC3046]. + The format of the sub-option is shown below. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code The sub-option code (152). + + Length The sub-option length, 0. + + This sub-option only appears in the DHCPv4 Relay Agent Information + option. In a DHCP request, it indicates that a DHCPv4 VSS sub-option + is also present in the Relay Agent Information option. In a DHCP + reply, if it appears in the Relay Agent Information option, it + indicates that the DHCP server did not understand any DHCPv4 VSS + sub-option that also appears in the Relay Agent Information option. + +3.4. DHCPv6 Virtual Subnet Selection Option + + The format of the DHCPv6 VSS option is shown below. This option may + be included by a client or relay agent (or both). + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_VSS | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | VSS Information ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + option-code OPTION_VSS (68). + + option-len The number of octets in the option, minimum 1. + + Type and VSS Information -- see Section 3.5. + + + + + + + + + + + +Kinnear, et al. Standards Track [Page 7] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +3.5. Virtual Subnet Selection Type and Information + + All of the (sub-)options defined above that carry VSS information use + identical payloads consisting of a Type value and additional VSS + information, as follows: + + Type VSS Information Format + ------------------------------------------------------------ + 0 Network Virtual Terminal (NVT) ASCII VPN identifier + 1 RFC 2685 VPN-ID + 2-254 Unassigned + 255 Global, default VPN + + o Type 0 -- Network Virtual Terminal (NVT) ASCII VPN identifier + + Indicates that the VSS information consists of an NVT ASCII + string. It MUST NOT be terminated with a zero byte. + + o Type 1 -- RFC 2685 VPN-ID + + Indicates that the VSS information consists of an RFC 2685 VPN-ID + [RFC2685], which is defined to be 7 octets in length. + + o Type 255 -- Global, default VPN + + Indicates that there is no explicit, non-default VSS information + but rather that this option references the normal, global, default + address space. In this case, there MUST NOT be any VSS + information included in the VSS option or sub-option, and the + length of the option or sub-option MUST be 1. + + All other values of the Type field are unassigned. + +4. Overview of Virtual Subnet Selection Usage + + At the highest level, the VSS option or sub-option determines the VPN + on which a DHCP client is supposed to receive an IP address. How the + option or sub-option is entered and processed is discussed below, but + the point of all of the discussion is to determine the VPN on which + the DHCP client resides. This will affect a relay agent, in that it + will have to ensure that DHCP packets sent to and received from the + DHCP client flow over the correct VPN. This will affect the DHCP + server in that it determines the IP address space used for the IP + address allocation. + + + + + + + +Kinnear, et al. Standards Track [Page 8] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + A DHCP server has as part of its configuration some IP address space + from which it allocates IP addresses to DHCP clients. These + allocations are typically for a limited time, and thus the DHCP + client gets a lease on the IP address. In the absence of any VPN + information, the IP address space is in the global or default VPN + used throughout the Internet. When a DHCP server deals with VPN + information, each VPN defines a new address space inside the server, + one distinct from the global or default IP address space. A server + that supports the VSS option or sub-option thereby supports + allocation of IP addresses from multiple different VPNs. Supporting + IP address allocation from multiple different VPNs means that the + DHCP server must be prepared to configure multiple different address + spaces (one per distinct VPN) and allocate IP addresses from these + different address spaces. + + These address spaces are typically independent, so that the same IP + address (consisting of the same string of bytes) could be allocated + to one client in the global, default VPN, and to a different client + residing in a different VPN. There is no conflict in this + allocation, since the clients have essentially different addresses, + even though these addresses consist of the same string of bytes, + because the IPv4 or IPv6 address is qualified by the VPN. + + Thus, a VSS option or sub-option is a way of signaling the use of a + VPN other than the global or default VPN. This brings up the + question of who decides what VPN a DHCP client should be using. + + There are three entities that can insert either a VSS option or + sub-option into a DHCPv4 packet or DHCPv6 message: a DHCP client, a + relay agent, or a DHCPv4 or DHCPv6 server. While all of these + entities could include a different VSS option or sub-option in every + request or response, this situation is neither typical nor useful. + There are two known paradigms for use of the VSS option or + sub-option; these are discussed below. + +4.1. VPN Assignment by the DHCP Relay Agent + + 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 approach, know the VPN on which + it resides. The relay agent is responsible for mediating the access + between the VPN on which the DHCP client resides and the DHCP server. + In this situation, the relay agent will insert two DHCPv4 + Relay Agent Information sub-options (one VSS sub-option, and one + VSS-Control sub-option) into the Relay Agent Information option, or a + DHCPv6 VSS option into the Relay-forward message of every request it + + + + + +Kinnear, et al. Standards Track [Page 9] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + forwards from the DHCP client. The server will use the DHCPv6 VSS + option or DHCPv4 VSS sub-option to determine the VPN on which the + client resides and will use that VPN information to select the + address space within its configuration from which to allocate an IP + address to the DHCP client. + + When, using this approach, a DHCPv4 relay agent inserts a VSS + sub-option into the Relay Agent Information option, it MUST also + insert a VSS-Control sub-option into the Relay Agent Information + option. This is to allow the determination of whether or not the + DHCPv4 server actually processes the VSS information provided by the + DHCPv4 relay agent. If the DHCPv4 server supports the VSS + capabilities described in this document, it will remove the + VSS-Control sub-option from the Relay Agent Information option that + it returns to the DHCPv4 relay agent. See Section 5 for more + information. + + In this approach, the relay agent might also send a VSS option or + sub-option in either a DHCPv4 or DHCPv6 Leasequery request [RFC4388] + [RFC5007], but in this case, it would use the VSS option in the + Leasequery request to select the correct address space for the + Leasequery. In this approach, the relay agent would be acting as a + DHCP client from a leasequery standpoint, but it would not be as if a + DHCP client were sending in a VSS option in a standard DHCP address + allocation request, say a DHCPDISCOVER. + + In this approach, only one relay agent would mediate the VPN access + for the DHCP client to the DHCP server, and it would be the relay + agent that inserts the VSS information into the request packet and + that would remove it prior to forwarding the response packet. + + + + + + + + + + + + + + + + + + + + + +Kinnear, et al. Standards Track [Page 10] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + The diagram below shows an example of a DHCPv4 client, DHCPv4 relay + agent, and DHCPv4 server. The DHCPv6 situation is similar but uses + the DHCPv6 VSS option. + + DHCPv4 + DHCPv4 Relay DHCPv4 + Client Agent Server + + | | | + | >--DHCPDISCOVER--> | | + | on VPN "abc" | | + | | >--DHCPDISCOVER----> | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | VSS-Control | + | | | + | | <----DHCPOFFER-----< | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | | + | <---DHCPOFFER----< | | + | on VPN "abc" | | + | | | + | >--DHCPREQUEST---> | | + | on VPN "abc" | | + | | >--DHCPREQUEST-----> | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | VSS-Control | + | | | + | | <----DHCPACK-------< | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | | + | <---DHCPACK------< | | + | on VPN "abc" | | + | | | + ... ... ... + + Figure 4.1-1: DHCPv4 - Relay Agent Knows VPN + + The DHCP server would know that it should respond to VPN information + specified in a VSS option or sub-option, and it would be configured + with appropriate VPN address spaces to service the projected client + requirements. Thus, in this common approach, the DHCP client knows + nothing of any VPN access, the relay agent has been configured in + some way that allows it to determine the VPN of the DHCP client and + transmit that using a VSS option or sub-option to the DHCP server, + + + +Kinnear, et al. Standards Track [Page 11] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + and the DHCP server responds to the VPN specified by the relay agent. + 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. + + If any misconfiguration exists, it SHOULD result in a DHCP client + being unable to acquire an IP address. For instance, a relay agent + that supports VPN access SHOULD couple transmission of VSS options or + sub-options to the configuration of VPN support and not allow one + without the other. + + It is important to ensure that the relay agent and DHCP server both + support the VSS option and sub-options (for DHCPv4) or the VSS option + (for DHCPv6). Deploying DHCPv4 relay agents that support and emit + VSS sub-options in concert with DHCPv4 servers that 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. Should this + situation occur, however, the relay agent can detect the problem + (since the VSS-Control sub-option will appear in the packets it + receives from the DHCPv4 server, indicating the server did not + effectively process the VSS sub-option), and it can issue appropriate + diagnostic messages. + +4.2. VPN Assignment by the DHCP Server + + In this approach, the DHCP server would be configured in some way to + know the VPN on which a particular DHCP client should be given + access. The DHCP server would in this case include the VSS + sub-option in the Relay Agent Information option for DHCPv4 or the + VSS option in the Relay-reply message for DHCPv6. The relay agent + responsible for mediating VPN access would use this information to + select the correct VPN for the DHCP client. In the unusual 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. + + Once the relay agent has placed the DHCP client into the proper VPN, + it SHOULD begin including VSS information in requests that it + forwards to the DHCP server. Since this information does not + conflict with the DHCP server's idea of the proper VPN for the + client, everything works correctly. + + + + + + + + + +Kinnear, et al. Standards Track [Page 12] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + The diagram below shows this approach using DHCPv4. The DHCPv6 + situation is similar but uses the DHCPv6 VSS option instead. + + DHCPv4 + DHCPv4 Relay DHCPv4 + Client Agent Server + + | | | + | >--DHCPDISCOVER--> | | + | on unknown VPN | | + | | >--DHCPDISCOVER----> | + | | | + | | <----DHCPOFFER-----< | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | | + | <---DHCPOFFER----< | | + | on VPN "abc" | | + | | | + | >--DHCPREQUEST---> | | + | on VPN "abc" | | + | | >--DHCPREQUEST-----> | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | VSS-Control | + | | | + | | <----DHCPACK-------< | + | | Relay Agent Info: | + | | VSS type 0:"abc" | + | | | + | <---DHCPACK------< | | + | on VPN "abc" | | + | | | + | | | + ... ... ... + + Figure 4.2-1: DHCPv4 - DHCPv4 Server Knows VPN + + In this approach, the DHCP client is again unaware of any VPN + activity. In this case, however, the DHCP server knows the VPN for + the client, and the relay agent responds to the VSS information + specified by the DHCP server. Similar to the previous approach, each + entity knows its role through a means external to this document, and + no two entities try to specify VSS information in conflict. + + + + + + + +Kinnear, et al. Standards Track [Page 13] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + It is important that both the relay agent and the DHCP server support + the VSS option and sub-options (for DHCPv4) and the VSS option (for + DHCPv6). Deploying and configuring VPN support in one element and + not in the other is not a practical approach. + +4.3. Required Support + + DHCP relay agents and servers MUST support the approach discussed in + Section 4.1. DHCP relay agents and servers SHOULD support the + approach discussed in Section 4.2. DHCP relay agents and servers + SHOULD NOT be configured to operate with both approaches + simultaneously. + +4.4. Alternative VPN Assignment Approaches + + There are many other approaches that 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 approaches + do not describe situations that are useful today, specifying + precisely how to resolve all of these conflicts is not likely to be + valuable in the event that these approaches actually become practical + in the future. + + The current use of the VSS option and sub-option requires that each + entity know 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 whether it should + simply ignore any VSS information that it might see. + + Some simple conflict-resolution approaches are discussed below, in + the hopes that they will cover simple cases that may arise from + situations beyond those envisioned today. However, for more complex + situations, or simple situations where appropriate conflict- + resolution strategies differ from those discussed in this document, a + document detailing the usage situations and appropriate conflict- + resolution strategies SHOULD be created and submitted for discussion + and approval. + + + + + + + + + +Kinnear, et al. Standards Track [Page 14] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +5. Relay Agent Behavior + + Implementers MAY provide a policy or configuration capability to + enable or disable VSS support. + + A relay agent that receives a DHCP request from a DHCP client on a + VPN SHOULD include VSS information in the DHCP packet prior to + forwarding the packet to the DHCP server unless inhibited from doing + so by configuration information or policy to the contrary. + + In this situation, a DHCPv4 relay agent MUST include a DHCPv4 VSS + sub-option in a Relay Agent Information option [RFC3046], while a + DHCPv6 relay agent MUST include a DHCPv6 VSS option in the + Relay-forward message. + + The value placed in the VSS sub-option or option would typically be + sufficient for the relay agent to properly route any DHCP reply + packet returned from the DHCP server to the DHCP client for which it + is destined. In some cases, the information in the VSS sub-option or + option might be an index to some internal table held in the relay + agent, though this document places no requirement on a relay agent to + have any such internal state. + + A DHCPv4 relay agent MUST, in addition, include a DHCPv4 VSS-Control + sub-option (which has a length of zero) in the + Relay Agent Information option [RFC3046] whenever it includes a VSS + sub-option in the Relay Agent Information option. The inclusion of + the VSS sub-option and the VSS-Control sub-option in the + Relay Agent Information option will allow the DHCPv4 relay agent to + determine whether the DHCPv4 server actually processed the + information in the VSS sub-option when it receives the + Relay Agent Information option in the reply from the DHCPv4 server. + + The reason to include this additional VSS DHCPv4 sub-option is that + [RFC3046] specifies (essentially) that a DHCPv4 server should copy + all sub-options that it receives in a Relay Agent Information option + in a request into a corresponding Relay Agent Information option in + the response. Thus, a server that didn't support the DHCPv4 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. + + To alleviate this potential confusion, a DHCPv4 relay agent instead + sends in two sub-options: one VSS sub-option, and one VSS-Control + sub-option. If both sub-options appear in the response from the + DHCPv4 server, then the DHCPv4 relay agent MUST assume that the + DHCPv4 server did not act on the VSS information in the VSS + sub-option. If only the VSS sub-option appears in the response from + + + +Kinnear, et al. Standards Track [Page 15] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + the DHCPv4 server and no VSS-Control sub-option appears in the + response from the DHCPv4 server, then the relay agent SHOULD assume + that the DHCPv4 server acted successfully on the VSS sub-option. + + Any time a relay agent places a VSS option or sub-option in a DHCP + request, it SHOULD send it only to a DHCP server that supports the + VSS option or sub-option, and it MUST check the response to determine + if the DHCP server actually honored the requested VSS information. + + In the DHCPv6 case, the appearance of the option in the Relay-reply + packet indicates that the DHCPv6 server understood and acted upon the + contents of the VSS option in the Relay-forward packet. In the + DHCPv4 case, as discussed above, the appearance of the VSS sub-option + without the appearance of a VSS-Control sub-option indicates that the + DHCPv4 server successfully acted upon the VSS sub-option. + + This document does not create a requirement that a relay agent + remember the contents of a VSS DHCPv4 sub-option or VSS DHCPv6 option + sent to a DHCP server. In many cases, the relay agent may simply use + the value of the VSS option or sub-option returned by the DHCP server + to forward the response to the DHCP client. If the VSS information, + the IP address allocated, and the VPN capabilities of the relay agent + all interoperate correctly, then the DHCP client will receive a + working IP address. Alternatively, if any of these items don't + interoperate with the others, the DHCP client will not receive a + working address. + + 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 relay agent closer to + the client or the client itself 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 or sub-option. In the DHCPv4 case, + an additional VSS-Control sub-option would be required, as discussed + above. + +5.1. VPN Assignment by the DHCP Server + + In some cases, a DHCP server may use the VSS 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 VSS 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 + + + + + +Kinnear, et al. Standards Track [Page 16] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + 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. + + In this situation, once the relay agent has placed the DHCP client + into the VPN specified by the DHCP server, it will insert a VSS + option or sub-option when forwarding packets from the client. The + DHCP server in normal operation will echo this VSS information into + the outgoing replies. + + In the event that the relay agent doesn't include VSS information on + subsequent requests after the DHCP server has included VSS + information in a reply to the relay agent, the DHCP server can + conclude that the relay agent doesn't support VSS processing, and the + DHCP server SHOULD stop processing this transaction and not respond + to the request. + +5.2. DHCP Leasequery + + A relay agent sometimes needs to submit a DHCP Leasequery [RFC4388] + [RFC5007] packet to the DHCP server in order to recover information + about existing DHCP-allocated IP addresses on networks other than the + normal, global VPN. In the context of a DHCP Leasequery, the relay + agent is a direct client of the DHCP server and is not relaying a + packet for another DHCP client. Thus, the instructions in Section 6 + ("Client Behavior") should be followed to include the necessary VSS + information. + +6. Client Behavior + + Typically, DHCPv4 and DHCPv6 clients have no interaction with VSS + options or sub-options. The VSS information is handled by exchanges + between a DHCPv4 or DHCPv6 relay agent and the corresponding DHCPv4 + or DHCPv6 server. + + However, there are times when an entity is acting as a DHCPv4 or + DHCPv6 client in that it is communicating directly with a DHCPv4 or + DHCPv6 server. In these instances -- where communication is + occurring without employing the DHCPv4 Relay Agent Information option + or the DHCPv6 Relay-forward or Relay-reply messages -- the entity is + acting as a DHCPv4 or DHCPv6 client with regard to its communication + with the DHCPv4 or DHCPv6 server, but not necessarily as a DHCP + client that is requesting a DHCPv4 or DHCPv6 address for its own use. + + The client, in this context, may be requesting an IP address for + another entity, thus acting as a DHCP proxy. The client may be + requesting information about another client-to-address binding, using + the DHCPv4 [RFC4388] or DHCPv6 [RFC5007] leasequery protocol. + + + +Kinnear, et al. Standards Track [Page 17] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + In the rest of this section, the term "client" refers to an entity + communicating VSS information directly to a DHCPv4 or DHCPv6 server + without using the DHCPv4 Relay Agent Information option or the DHCPv6 + Relay-forward or Relay-reply messages, and there is no requirement + that such a client be a traditional DHCPv4 or DHCPv6 client + requesting an IP address binding for itself. + + DHCPv4 or DHCPv6 clients 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. A DHCPv4 client will place the + DHCPv4 VSS option in its packets, and a DHCPv6 client will place the + DHCPv6 VSS option in its messages. + + A DHCPv6 client that needs to place a VSS option into a DHCPv6 + message SHOULD place a single VSS option into the DHCPv6 message at + the same level as the Client Identifier option. A DHCPv6 client MUST + NOT include different VSS options in the same DHCPv6 message. + + Note that -- as mentioned in Section 1 -- throughout this document, + when a DHCPv6 address is indicated, the same information applies to + DHCPv6 prefix delegation [RFC3633] as well. + + Since this option is placed in the packet in order to change the VPN + on which an IP address is allocated for a particular DHCP client, one + presumes that an allocation on that VPN is necessary for correct + operation. Thus, a client that places this option in a packet and + doesn't receive it or receives a different value in a returning + packet SHOULD drop the packet, since the IP address that was + allocated will not be in the requested VPN. + + Clients should be aware that some DHCP servers will return a VSS + option with different values than the values sent by the client. In + addition, a client may receive a response from a DHCP server with a + VSS option when none was sent by the client. + + Note that when sending a DHCP Leasequery request, a relay agent is + acting as a DHCP client, and so it SHOULD include the respective + DHCPv4 or DHCPv6 VSS option in its DHCPv4 or DHCPv6 Leasequery packet + if the DHCP Leasequery request is generated for other than the + default, global VPN. It SHOULD NOT include a DHCPv4 sub-option in + this case. + + + + + + + + + +Kinnear, et al. Standards Track [Page 18] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +7. Server Behavior + + A DHCP server receiving the VSS option or sub-option SHOULD allocate + an IP address (or use the VSS information to access an already + allocated IP address) from the VPN specified by the included VSS + information. + + In the case where the Type field of the VSS option or sub-option is + 255, the VSS option denotes the global, default VPN. In this case, + there is no explicit VSS information beyond the Type field. + + This document does not prescribe any particular address allocation + policy. A DHCP server may choose to attempt to allocate an address + using the VSS information and, if this is impossible, to not allocate + an address. Alternatively, a DHCP server may choose to attempt + address allocation based on the VSS information and, if that is not + possible, it may fall back to allocating an address on the global or + default VPN. This, of course, is also the apparent behavior of any + DHCP server that doesn't implement support for the VSS option and + sub-option. Thus, DHCP clients and relay agents SHOULD be prepared + for either of these alternatives. + + In some cases, a DHCP server may use the VSS 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 VSS 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. + + In this situation, the relay agent will place the client in the + proper VPN, and then it will insert a VSS option or sub-option in + subsequent forwarded requests. The DHCP server will see this VSS + information, and since it doesn't conflict in any way with the + server's notion of the VPN on which the client is supposed to reside, + it will process the requests based on the VPN specified in the VSS + option or sub-option, and echo the same VSS information in the + outgoing replies. + + The relay agent receiving a reply containing a VSS option should + support the VSS option. Otherwise, the relay agent will end up + attempting to use the address as though it were a global address. + Should this happen, the subsequent DHCPREQUEST will not contain any + VSS information, in which case the DHCP server SHOULD NOT respond + with a DHCPACK. + + + + + + + +Kinnear, et al. Standards Track [Page 19] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + If a server uses a different VPN than what was specified in the VSS + option or sub-option, it SHOULD send back the VPN information using + the same type as the received type. It MAY send back a different + type if it is not possible to use the same type (such as the RFC2685 + VPN-ID if no ASCII VPN identifier exists). + + A server that receives a VSS sub-option in the DHCPv4 + Relay Agent Information option and does not receive a VSS-Control + sub-option in the Relay Agent Information option MUST process the + information specified in the VSS sub-option in the same fashion as it + would have if it received both sub-options. + +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 is unable to support, is not configured to + support, or does not implement support for VSS information in general + or the requested VPN in particular. + + If they echo the option (based on the criteria above), servers SHOULD + return an exact copy of the option unless they desire to change the + VPN on which a client was configured. + + The appearance of the DHCPv4 VSS option code in the DHCPv4 Parameter + Request List option [RFC2132] should not change the processing or + decision to return or not return the VSS option as specified in this + document. The appearance of the DHCPv6 VSS option in the OPTION_ORO + [RFC3315] or the OPTION_ERO [RFC4994] should not change the + processing or decision to return (or not to return) the VSS option as + specified in this document. + +7.2. Returning the DHCPv4 Sub-Option + + The case of the DHCPv4 sub-option is a bit more complicated. Note + that [RFC3046] specifies that a DHCPv4 server that supports the + Relay Agent Information option SHALL copy all sub-options received in + a Relay Agent Information option into any outgoing + Relay Agent Information option. Thus, the default behavior for any + DHCPv4 server is to return any VSS sub-option received to the relay + agent whether or not the DHCPv4 server understands the VSS + sub-option. + + In order to distinguish a DHCPv4 server that is simply copying + Relay Agent Information option sub-options from an incoming to an + outgoing Relay Agent Information option from a DHCPv4 server that + + + +Kinnear, et al. Standards Track [Page 20] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + successfully acted upon the information in the VSS sub-option, DHCPv4 + relay agents MUST include a VSS-Control sub-option in the + Relay Agent Information any time that it includes a VSS sub-option in + the Relay Agent Information option. + + A DHCPv4 server that does not support the VSS sub-option will copy + both sub-options into the outgoing Relay Agent Information option, + thus signaling to the DHCPv4 relay agent that it did not understand + the VSS sub-option. + + A DHCPv4 server that supports the VSS sub-option + + o MUST copy the VSS sub-option into the outgoing + Relay Agent Information option + + o MUST NOT copy the VSS-Control sub-option into the outgoing + Relay Agent Information option + + Moreover, if a server uses different VSS information to allocate an + IP address than it receives in a particular DHCPv4 sub-option, it + MUST include that alternative VSS information in the VSS sub-option + that it returns to the DHCPv4 relay agent instead of the original VSS + information it was given. + + If a DHCPv4 server supports this sub-option and for some reason + (perhaps administrative control) does not honor this sub-option from + the request, then it MUST NOT echo either sub-option into the + outgoing Relay Agent Information option. + +7.3. Making Sense of Conflicting VSS Information + + It is possible for a DHCPv4 server to receive both a VSS option and + VSS sub-options in the same packet. Likewise, a DHCPv6 server can + receive multiple VSS options in nested Relay-forward messages as well + as in the client message itself. In either of these cases, the VSS + information from the relay agent closest to the DHCP server SHOULD be + used in preference to all other VSS information received. In the + DHCPv4 case, this means that the VSS sub-option takes precedence over + the VSS option, and in the DHCPv6 case, this means that the VSS + option from the outermost Relay-forward message in which a VSS option + appears takes precedence. + + The reasoning behind this approach is that the relay agent closer to + the DHCP server is almost certainly more trusted than the DHCP client + or more distant relay agents, and therefore information in the + Relay Agent Information option or the Relay-forward message is more + likely to be correct. + + + + +Kinnear, et al. Standards Track [Page 21] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + In general, relay agents SHOULD be aware through configuration or + policy external to this document whether or not they should be + including VSS information in packets that they forward, and so these + relay agents should not specify any conflicting VSS information. + + In situations where multiple VSS options or sub-options appear in the + incoming packet or message, when the DHCP server constructs the + response to be sent to the DHCP client or relay agent, all existing + VSS options or sub-options MUST be replicated in the appropriate + places in the response and MUST contain only the VSS information that + was used by the DHCP server to allocate the IP address (with, of + course, the exception of a VSS-Control sub-option of a DHCPv4 + Relay Agent Information option). + +8. Update to RFC 3046 + + This document updates the specification of the + Relay Agent Information option in Section 2.2 of RFC 3046, in the + first sentence of the second paragraph, as follows: + + o OLD: + + DHCP servers claiming to support the Relay Agent Information + option SHALL echo the entire contents of the Relay Agent + Information option in all replies. + + o NEW: + + DHCP servers claiming to support the Relay Agent Information + option SHALL echo the entire contents of the + Relay Agent Information option in all replies, except if otherwise + specified in the definition of specific Relay Agent Information + sub-options. + +9. Security Considerations + + Message authentication in DHCPv4 for intradomain use where the out- + of-band exchange of a shared secret is feasible is defined in + [RFC3118]. Potential exposures to attack are discussed in Section 7 + of the DHCP protocol specification [RFC2131]. + + Implementations should consider using the DHCPv4 Authentication + option [RFC3118] to protect DHCPv4 client access in order to provide + a higher level of security if it is deemed necessary in their + environment. + + + + + + +Kinnear, et al. Standards Track [Page 22] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + Message authentication in DHCPv4 relay agents as defined in [RFC4030] + should be considered for DHCPv4 relay agents employing the + sub-options defined in this document. Potential exposures to attack + are discussed in Section 7 of the DHCP protocol specification + [RFC2131]. + + For use of the VSS option by DHCPv6, the Security Considerations + section of [RFC3315] details the general threats to DHCPv6, and thus + to messages using the VSS option. The "Authentication of DHCP + Messages" section of [RFC3315] describes securing communication + between relay agents and servers, as well as clients and servers. + + The VSS option could be used by a client in order to obtain an IP + address from any VPN. This option would allow a client to perform a + more complete address-pool exhaustion attack, since the client would + no longer be restricted to attacking address pools on just its local + subnet. + + A DHCP server that implements these VSS options and the VSS + sub-option should be aware of this possibility and use whatever + techniques can be devised to prevent such an attack. Information + such as the giaddr in DHCPv4 or link address in the Relay-forward + DHCPv6 message might be used to detect and prevent this sort of + attack. + + One possible defense would be for the DHCP relay agent to insert a + VSS option or sub-option to override the DHCP client's VSS option. + + Servers that implement the VSS option and sub-option MUST by default + disable use of the feature; it must specifically be enabled through + configuration. Moreover, a server SHOULD provide the ability to + selectively enable use of the feature under restricted conditions, + e.g., by enabling use of the option only from explicitly configured + client-ids, enabling its use only by clients on a particular subnet, + or restricting the VSSs from which addresses may be requested. + +10. IANA Considerations + + IANA has assigned DHCPv4 option number 221 to the DHCPv4 Virtual + Subnet Selection option defined in Section 3.1, in accordance with + [RFC3942]. + + IANA has assigned sub-option number 151 to the DHCPv4 Virtual Subnet + Selection sub-option defined in Section 3.2 from the DHCP Relay Agent + Sub-options space [RFC3046], in accordance with the spirit of + [RFC3942]. While [RFC3942] doesn't explicitly mention the sub-option + space for the DHCP Relay Agent Information option [RFC3046], + + + + +Kinnear, et al. Standards Track [Page 23] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + sub-option 151 is already in use by existing implementations of this + sub-option, and this document is essentially upward-compatible with + these current implementations. + + IANA has assigned the value of 152 to the DHCPv4 Virtual Subnet + Selection Control sub-option defined in Section 3.3. + + IANA has assigned the value of 68 for the DHCPv6 Virtual Subnet + Selection option defined in Section 3.4 from the DHCP Option Codes + registry. + + The Type byte defined in Section 3.5 defines a number space for which + IANA has created and will maintain a new sub-registry entitled "VSS + Type Options". This sub-registry needs to be related to both the + DHCPv4 and DHCPv6 VSS options and the DHCPv4 Relay Agent Information + option sub-option (all defined by this document), since the Type byte + in these two options and the VSS sub-option MUST have identical + definitions. + + New values for the Type byte may only be defined by IETF Review, as + described in [RFC5226]. Basically, this means that they are defined + by RFCs approved by the IESG. + +11. Acknowledgments + + Jay Kumarasamy contributed to earlier versions of this document. + Bernie Volz recommended consolidation of the DHCPv4 option and + sub-option documents after extensive review of those former + documents, and provided valuable assistance in structuring and + reviewing this document. Alper Yegin expressed interest in the + DHCPv6 VSS option, resulting in this combined document covering all + three areas. Alfred Hoenes provided assistance with editorial review + and also raised substantive protocol issues. David Hankins and + Bernie Volz each raised important protocol issues that resulted in a + clarified document. Josh Littlefield provided editorial assistance. + Several IESG reviewers took the time to substantially review this + document, resulting in much-improved clarity. + + + + + + + + + + + + + + +Kinnear, et al. Standards Track [Page 24] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP + Vendor Extensions", RFC 2132, March 1997. + + [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks + Identifier", RFC 2685, September 1999. + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, January 2001. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC4994] Zeng, S., Volz, B., Kinnear, K. and J. Brzozowski, + "DHCPv6 Relay Agent Echo Request Option", RFC 4994, + September 2007. + +12.2. Informative References + + [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, + September 1985. + + [RFC1542] Wimer, W., "Clarifications and Extensions for the + Bootstrap Protocol", RFC 1542, October 1993. + + [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for + DHCP Messages", RFC 3118, June 2001. + + [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration + Protocol version 4 (DHCPv4) Options", RFC 3942, + November 2004. + + + + + + +Kinnear, et al. Standards Track [Page 25] + +RFC 6607 Virtual Subnet Selection Options April 2012 + + + [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for + the Dynamic Host Configuration Protocol (DHCP) Relay + Agent Option", RFC 4030, March 2005. + + [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration + Protocol (DHCP) Leasequery", RFC 4388, February 2006. + + [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, + "DHCPv6 Leasequery", RFC 5007, September 2007. + + [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network + Interchange", RFC 5198, March 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +Authors' Addresses + + Kim Kinnear + Cisco Systems + 1414 Massachusetts Ave. + Boxborough, MA 01719 + + Phone: (978) 936-0000 + EMail: kkinnear@cisco.com + + + Richard Johnson + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + + Phone: (408) 526-4000 + EMail: raj@cisco.com + + + Mark Stapp + Cisco Systems + 1414 Massachusetts Ave. + Boxborough, MA 01719 + + Phone: (978) 936-0000 + EMail: mjs@cisco.com + + + + + + + +Kinnear, et al. Standards Track [Page 26] + |