doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4280.txt b/doc/rfc/rfc4280.txt
new file mode 100644
index 0000000..6c9b753
--- /dev/null
+++ b/doc/rfc/rfc4280.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                       K. Chowdhury
+Request for Comments: 4280                              Starent Networks
+Category: Standards Track                                      P. Yegani
+                                                           Cisco Systems
+                                                               L. Madour
+                                                                Ericsson
+                                                           November 2005
+
+
+         Dynamic Host Configuration Protocol (DHCP) Options for
+                Broadcast and Multicast Control Servers
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines new options to discover the Broadcast and
+   Multicast Service (BCMCS) controller in an IP network.  BCMCS is
+   being developed for Third generation (3G) cellular telephone
+   networks.  Users of the service interact with a controller in the
+   network via the Mobile Node (MN) to derive information required to
+   receive Broadcast and Multicast Service.  Dynamic Host Configuration
+   Protocol can be used to configure the MN to access a particular
+   controller.  This document defines the related options and option
+   codes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 1]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+Table of Contents
+
+   1. Motivation ......................................................2
+   2. Overview of the 3GPP2 BCMCS Network .............................3
+   3. Terminology .....................................................4
+   4. Broadcast and Multicast Service Controller Options ..............4
+      4.1. Broadcast and Multicast Service Controller Domain
+           Name List for DHCPv4 .......................................4
+      4.2. Broadcast and Multicast Service Controller Domain
+           Name List Option for DHCPv6 ................................5
+      4.3. Broadcast and Multicast Service Controller IPv4
+           Address Option for DHCPv4 ..................................6
+      4.4. Broadcast and Multicast Service Controller IPv6
+           Address Option for DHCPv6 ..................................6
+      4.5. Consideration for Client Operation .........................7
+      4.6. Consideration for Server Operation .........................7
+   5. Security Considerations .........................................8
+   6. IANA Considerations .............................................8
+   7. Acknowledgements ................................................8
+   8. Normative References ............................................9
+
+1.  Motivation
+
+   Dynamic Host Configuration Protocol [RFC2131] and [RFC3315] can be
+   used to configure various non-IP address type of parameters.  These
+   parameters are required for normal operation of various services that
+   are offered over an IP network.
+
+   Broadcast and Multicast Service (BCMCS) is one such service that is
+   being standardized in various mobile wireless standard bodies such as
+   Third Generation Partnership Project 2 (3GPP2), Open Mobile Alliance
+   (OMA), and 3GPP.  A description of the BCMCS as defined in 3GPP2 can
+   be found in [BCMCS].
+
+   While DHCP already defines many options for device configuration, no
+   option exists for configuring a mobile device to use BCMCS.  This
+   memo defines extensions for both DHCPv4 and DHCPv6 so that DHCP can
+   be used to provide necessary configuration information to a mobile
+   device about the BCMCS controllers.
+
+   DHCP is being used in 3GPP2, to assist Mobile Nodes (MNs) with the
+   discovery of the BCMCS Controller in a mobile operator's IP network.
+   The BCMCS includes a controller component that is responsible for
+   managing the service via interaction with the MN and other network
+   entities.  In this document, we will call this a BCMCS controller.
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 2]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+   An overview of the 3GPP2 BCMCS architecture is given in the next
+   section.  It provides enough information to understand the basics of
+   the 3GPP2 BCMCS operation.  Readers are encouraged to find a more
+   detailed description in [BCMCS].
+
+   As described in [BCMCS], the MNs are required to know the IPv4 or the
+   IPv6 address of the BCMCS controller entity so that they can download
+   all the necessary information about a desired broadcast and/or a
+   multicast program.  In a roaming environment, static configuration of
+   the BCMCS controller's IP address becomes unrealistic.  Therefore,
+   DHCP is considered to be a method to dynamically configure the MNs
+   with the IP address or the fully qualified domain name (FQDN) of the
+   BCMCS controller in the 3G cellular telephone networks.
+
+   In order to allow the MNs to discover the BCMCS controllers, the MNs
+   request the appropriate option codes from the DHCP server.  The DHCP
+   servers need to return the corresponding configuration options that
+   carry either BCMCS controller's IP address or FQDN based on
+   configuration.  This document defines the necessary options and
+   option codes.
+
+2.  Overview of the 3GPP2 BCMCS Network
+
+   The Broadcast and Multicast Service architecture in a 3G cellular
+   telephone network such as 3GPP2 has the following model:
+
+                              +------------+   +--------+
+                              |   BCMCS    |   |        |
+                              | Controller |   |  DHCP  |
+                              |            |   | Server |
+                              +------------+   +--------+
+                                     ^
+                              Control|
+                                 Info|
+                                     |
+                                     |
+                                     V
+   +----+        +------------+    +------------+
+   |    |        |            |    |            |
+   | MN/| bearer |   Radio    |    | BCMCS      |
+   |User|<-------|   Access   |<---| Content    |
+   |    |        |   Network  |    | Server     |
+   +----+        +------------+    +------------+
+
+   Note that this figure is shown here for a basic understanding of how
+   Broadcast and Multicast Service works in a 3G cellular telephone
+   network.  The network elements except MN/user and the DHCP server are
+   not relevant to the text in this document.
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 3]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+   The MN interacts with the BCMCS Controller to request broadcast/
+   multicast program information from the network (e.g., scheduled time,
+   multicast IP address, port numbers).  The MN may also be
+   authenticated by the BCMCS Controller while downloading the relevant
+   program-security-related information (such as encryption key).  These
+   interactions may happen via HTTP and XML as defined in [BCMCS].
+   There may be more than one BCMCS controller in the network.  The MN
+   should discover the appropriate BCMCS controller to request the
+   relevant program information.  For details of Broadcast and Multicast
+   Service operation in 3GPP2, see [BCMCS].
+
+3.  Terminology
+
+   The keywords "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].
+
+4.  Broadcast and Multicast Service Controller Options
+
+   This section defines the configuration option for the BCMCS
+   controller of the Broadcast and Multicast Service.
+
+4.1.  Broadcast and Multicast Service Controller Domain Name List for
+      DHCPv4
+
+   The general format of the BCMCS Controller Domain list option for
+   DHCPv4 is as follows:
+
+           Code  Len  FQDN(s) of BCMCS Controller
+         +-----+-----+-----+-----+-----+-----+-----+--
+         | 88  |  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
+         +-----+-----+-----+-----+-----+-----+-----+--
+
+   The option MAY contain multiple domain names, but these domain names
+   SHOULD be used to construct Service Record (SRV) lookups as specified
+   in [BCMCS], rather than querying for different A records.  The client
+   can try any or ALL of the domain names to construct the SRV lookups.
+   The list of domain names MAY contain the domain name of the access
+   provider and its partner networks that also offer Broadcast and
+   Multicast Service.
+
+   As an example, the access provider may have one or more partners or
+   resellers often termed as MVNOs (Mobile Virtual Network Operators)
+   for Broadcast and Multicast Service.  In this case, the access
+   provider should be able to use the same DHCP option to send multiple
+   of those domain names (MVNOs).  To illustrate this further, let's
+   assume that the access provider (operator) has a reseller agreement
+   with two MVNOs: mvno1 and mvno2.  Therefore, the Broadcast and
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 4]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+   Multicast Service Controller Domain Name list for the DHCPv4 option
+   will contain three domain names: operator.com, mvno1.com, and
+   mvno2.com.  Upon receiving this option, the BCMCS client may choose
+   to use one of the domain names to fetch the appropriate BCMCS
+   controller address (based on user's preference or configuration).  If
+   no preferred domain name is found in the received list, the client
+   should use a default setting, e.g., use the first one in the list.
+
+   If the length of the domain list exceeds the maximum permissible
+   length within a single option (254 octets), then the domain list MUST
+   be represented in the DHCPv4 message as specified in [RFC3396].  An
+   example case when two controller domain names, example.com and
+   example.net, are returned will be:
+
+   +----+----+----+----+----+----+----+----+----+----+----+
+   | 88 | 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
+   +----+----+----+----+----+----+----+----+----+----+----+
+   +----+----+----+----+----+----+----+----+----+----+----+
+   |'c' |'o' | 'm'|  0 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'|
+   +----+----+----+----+----+----+----+----+----+----+----+
+   +----+----+----+----+----+----+
+   |'e' |  3 | 'n'| 'e'| 't'|  0 |
+   +----+----+----+----+----+----+
+
+4.2.  Broadcast and Multicast Service Controller Domain Name List Option
+      for DHCPv6
+
+   The semantics and content of the DHCPv6 encoding of this option are
+   exactly the same as the encoding described in the previous section,
+   other than necessary differences between the way options are encoded
+   in DHCPv4 and DHCPv6.
+
+   Specifically, the DHCPv6 option for the BCMCS Control Server Domain
+   Names has the following format:
+
+      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_BCMCS_SERVER_D    |         option-length         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          BCMCS Control Server Domain Name List                |
+     |                              ...                              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   option-code: OPTION_BCMCS_SERVER_D (33).
+
+   option-length: Length of the 'BCMCS Control Server Domain Name List'
+   field in octets; variable.
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 5]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+   BCMCS Control Server Domain Name List: Identical format as in Section
+   4.1 (except the Code and Len fields).
+
+4.3.  Broadcast and Multicast Service Controller IPv4 Address Option for
+      DHCPv4
+
+   The Length byte (Len) is followed by a list of IPv4 addresses
+   indicating BCMCS controller IPv4 addresses.  The BCMCS controllers
+   MUST be listed in order of preference.  Its minimum length is 4, and
+   the length MUST be a multiple of 4.  The DHCPv4 option for this
+   encoding has the following format:
+
+          Code   Len  Address 1               Address 2
+         +-----+-----+-----+-----+-----+-----+-----+--
+         | 89  |  n  | a1  | a2  | a3  | a4  | a1  |  ...
+         +-----+-----+-----+-----+-----+-----+-----+--
+
+4.4.  Broadcast and Multicast Service Controller IPv6 Address Option for
+      DHCPv6
+
+   This DHCPv6 option MUST carry one or more 128-bit IPv6 address(es) of
+   the BCMCS Controller in an operator's network.
+
+      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_BCMCS_SERVER_A    |         option-length         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |    BCMCS Control server-1 address (IPv6 address)              |
+     |                                                               |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |    BCMCS Control server-2 address (IPv6 address)              |
+     |                                                               |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                              ...                              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   option-code: OPTION_BCMCS_SERVER_A (34).
+
+   option-length: Length of the 'BCMCS Control Server IPv6 address'
+   field in octets; variable.
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 6]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+4.5.  Consideration for Client Operation
+
+   For DHCPv4, the client MAY request either or both of the BCMCS
+   Controller Domain Name List and the IPv4 Address options in the
+   Parameter Request List option (code 55) as defined in [RFC2132].
+
+   For DHCPv6, the client MAY request either or both of the BCMCS
+   Controller Domain Name List and the IPv6 Address options in the
+   Options Request Option (ORO) as described in [RFC3315].
+
+   If the client receives both the BCMCS Controller Domain Name List and
+   IPv6 or IPv4 Address options, it SHOULD use the Domain Name List
+   option.  In this case, the client SHOULD NOT use the BCMCS Controller
+   IPv6 or IPv4 Address option unless the server(s) in the BCMCS
+   Controller Domain Name List cannot be resolved or reached.
+
+4.6.  Consideration for Server Operation
+
+   A server MAY send a client either the BCMCS Controller Domain Name
+   List Option or the BCMCS Controller IPv6 Address/IPv4 Address options
+   if the server is configured to do so.
+
+   If a client requests both the options and the server is configured
+   with both types of information, the server MAY send the client only
+   one of the options if it is configured to do so.  In this case, the
+   server SHOULD send the BCMCS Controller Domain Name List option.
+
+   A server configured with the BCMCS Controller IPv6 or IPv4 Address
+   information MUST send a client the BCMCS Controller IPv6 or IPv4
+   Address option if that client requested only the BCMCS Controller
+   IPv6 or IPv4 Address option and not the BCMCS Controller Domain Name
+   List option in the ORO or Parameter Request List option.
+
+   If a client requests for the BCMCS Controller IPv6 or IPv4 Address
+   option and the server is configured only with the domain name(s), the
+   server MUST return the Domain Name List and vice versa.
+
+   The domain names MUST be concatenated and encoded using the technique
+   described in Section 3.3 of "Domain Names - Implementation and
+   Specification" [RFC1035].  DNS name compression MUST NOT be used.
+
+
+
+
+
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 7]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+   The following table summarizes the server's response:
+
+      Client sends in ORO/
+      Parameter Request List   Domain Name List        IPv6/IPv4 Address
+      __________________________________________________________________
+
+      Neither option               SHOULD                  MAY
+      Domain Name List             MUST                    MAY
+      IPv6/IPv4 Address            MAY                     MUST
+      Both options                 SHOULD                  MAY
+
+5.  Security Considerations
+
+   This document does not introduce any new security concerns beyond
+   those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315]
+   specifications.  In the absence of message integrity protection for
+   these options, an attacker could modify the option values to divert
+   requests for broadcast service.
+
+6.  IANA Considerations
+
+   The following option codes for Broadcast and Multicast Service
+   Controller option have been assigned by IANA:
+
+   1.  The BCMCS Controller Domain Name list (Section 4.1) has been
+   assigned a value of 88 from the DHCPv4 option space.
+
+   2.  The BCMCS Controller Domain Name list (Section 4.2) has been
+   assigned a value of 33 from the DHCPv6 option space, and a name of
+   OPTION_BCMCS_SERVER_D.
+
+   3.  The BCMCS Controller IPv4 Address option (Section 4.3) has been
+   assigned a value of 89 from the DHCPv4 option space.
+
+   4.  The BCMCS Controller IPv6 Address option (Section 4.4) has been
+   assigned a value of 34 from the DHCPv6 option space, and a name of
+   OPTION_BCMCS_SERVER_A.
+
+7.  Acknowledgements
+
+   Thanks to the following individuals for their review and constructive
+   comments during the development of this document:
+
+   AC Mahendran, Jun Wang, Raymond Hsu, Jayshree Bharatia, Ralph Droms,
+   Ted Lemon, Margaret Wasserman, Thomas Narten, Elwyn Davies, Pekka
+   Savola, Bert Wijnen, David Kessens, Brian E. Carpenter, and Stig
+   Venaas.
+
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 8]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+8.  Normative References
+
+   [BCMCS]    3GPP2, www.3gpp2.org,
+              http://www.3gpp2.org/Public_html/specs/tsgx.cfm, "X.S0022,
+              Broadcast and Multicast Service in cdma2000 Wireless IP
+              Network.", December 2005.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, 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.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
+              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
+              November 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                     [Page 9]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+Authors' Addresses
+
+   Kuntal Chowdhury
+   Starent Networks
+   30 International Place
+   Tewksbury, MA  01876
+   US
+
+   Phone: +1 214-550-1416
+   EMail: kchowdhury@starentnetworks.com
+
+
+   Parviz Yegani
+   Cisco Systems
+   3625 Cisco Way
+   San Jose, CA  95134
+   US
+
+   Phone: +1 408-832-5729
+   EMail: pyegani@cisco.com
+
+
+   Lila Madour
+   Ericsson
+   8400, Decarie Blvd
+   Town of Mount Royal, Quebec  H4P 2N2
+   CANADA
+
+   Phone: +1 514-345-7900
+   EMail: Lila.Madour@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                    [Page 10]
+
+RFC 4280                 DHCP Options for BMCS             November 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Chowdhury, et al.           Standards Track                    [Page 11]
+