IPDVB Working Group M. Stiemerling Internet-Draft NEC Expires: August 15, 2005 February 14, 2005 Problem Statement: IP Address Configuration for IPDVB draft-stiemerling-ipdvb-config-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Future IPDVB networks will require a more powerful IP address configuration management as currently provided in such networks. Current discussions within the IPDVB working group have shown that the future usage scenarios and requirements for dynamic configuration of IP addresses are not yet clear defined. This memo identifies the problem space for IP address resolution and configuration in IPDVB networks. Stiemerling Expires August 15, 2005 [Page 1] Internet-Draft IPDVB Address Configuration February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Configuration Scenarios . . . . . . . . . . . . . . . 4 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 IP configuration available . . . . . . . . . . . . . . . . 6 3.2 Complete Bootstrap . . . . . . . . . . . . . . . . . . . . 6 4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Stiemerling Expires August 15, 2005 [Page 2] Internet-Draft IPDVB Address Configuration February 2005 1. Introduction Future IPDVB networks will require a more powerful IP address configuration management as currently provided in such networks. Current discussions within the IPDVB working group have shown that the future usage scenarios and requirements for dynamic configuration of IP addressesare not yet clear defined. This memo identifies the problem space for IP address resolution and configuration in IPDVB networks. The IPDVB working group has defined a new encapsulation scheme to transport IP over DVB (MPEG2 based) networks, the so-called Ultra-lightweight Encapsulation [1]. This scheme assumes that IP addresses have been already mapped to DVB identifiers (NPA, Network Point of Attachment) or NPAs have been mapped to IP addresses (reverse address resolution) vice versa . Another issues concerns the assignment of IP addresses to DVB receivers. Whereas today IP addresses are statically to those receivers, future deployments may require a more flexible IP address assignment as known from today's LAN, for instance, via DHCP [3]. Assigning IP addresses dynamically opens the space for further auto-configuration of DVB receivers, such as DNS server addresses or additional service layer information. This memo is a problem statement only and is intended to start discussions within the IPDVB working group. Comments and discussions should be sent to the IPDVB's mailing list at ipdvb@erg.abdn.ac.uk Section 2 introduces the network configuration for IPDVB networks. Section 3 describe two scenarios in detail. The document concludes with Section 4 listing similar areas of interest. The terminology used throughout this memo is defined in [2] Stiemerling Expires August 15, 2005 [Page 3] Internet-Draft IPDVB Address Configuration February 2005 2. Network Configuration Scenarios The basic assumption for IPDVB networks with respect to IP address receiver configuration and address resolution is the number of possible receivers (hosts) within a single IP subnetwork. It is assumed that future IPDVB networks may extend to 1*10E5 receivers but also may be limited to 10 or less receivers. Where the number of hosts per sub-network in IPv4 networks, IPv6 networks can logically extend to a large number of hosts. Such an IPv6 IPDVB network could comprise easily of 1*10E5 receivers, but the number can even break down to only a few hosts, e.g., 10 or smaller. This possible number of hosts should be consider when describing scenarios and later the solution. Figure 1 sketches a typical configuration of DVB receivers with an additional uplink, separate from DVB. This uplink could be, but is not limited to, ISDN, DSL, or cellular networks based. ,-----. DVB uplink / DVB \ *##################( Network ) # \ / +----*------+ `--.--' | Network | | | Provider +-<-+ v DVB downlink +-----------+ | | | +-----v------+ +--<<--+ DVB | uplink | Receiver | +------------+ Figure 1: Basic configuration scenario The uplink from DVB receiver to network provider can be bidirectional and not as shown unidirectional only. Figure 1 shows a typical scenario of an installation used to replace or substitute DSL deployments in areas where DSL cannot be provided, for instance. Figure 2 shows a scenario where the DVB receiver is connected via DVB only and the DVB link is used bidirectional. Such a configuration will be used on ships while being on sea and only DVB-S is available. Stiemerling Expires August 15, 2005 [Page 4] Internet-Draft IPDVB Address Configuration February 2005 ,-----. DVB link / DVB \ *##################( Network ) # \ / +----*------+ `--.--' | Network | | | Provider | | DVB link +-----------+ | +-----+------+ | DVB | | Receiver | +------------+ Figure 2: DVB only configuration scenario A scenario common to today's DVB broadcast usage is depicted in Figure 3. DVB receivers are using IP based transmission but receive the data via broadcast only. Such DVB receivers do not have the ability to interact with any other entity and can be configured by a push mechanism only. ,-----. DVB link / DVB \ *#######>>>########( Network ) # \ / +----*------+ `--.--' | Network | | | Provider | v DVB link +-----------+ v | +-----+------+ | DVB | | Receiver | +------------+ Figure 3: DVB based IP broadcast Stiemerling Expires August 15, 2005 [Page 5] Internet-Draft IPDVB Address Configuration February 2005 3. Scenarios 3.1 IP configuration available This section considers scenarios where DVB receivers have IP addresses already configured and only additional configuration information is required. This configuration of DVB receivers, for example, may be either pre-configured by the service provider or be configured by users. Figure 1 shows such a configuration example. The DVB receiver will obtain its basic IP address configuration via the non DVB uplink (most likely via ISDN and PPP). This scenario requires only additional configuration to be loaded at the DVB receivers. Possible things to configure: o IP service information, such as DNS server, proxies, etc o multicast configuration and routing information o broadcast configuration ("open bitstream" without any registration, DVB receivers just receive IP streams) o security configuration, e.g., keys, policies. 3.2 Complete Bootstrap Future scenarios may require a complete bootstrap of DVB receivers without any pre-configuration available on the IP level. Those DVB receivers may be pre-configured to known a basic DVB configuration, such as PID assignment for system information tables (SI tables). Such a receiver would need to retrieve first an IP address and learn about its IP environment (netmask, IP next hop, ...). Figure 2 shows such a scenario where a DVB receiver (and transmitter) would be installed aboard a ship and would function as a gateway between the ship's network and the DVB network. Stiemerling Expires August 15, 2005 [Page 6] Internet-Draft IPDVB Address Configuration February 2005 4. Related Work Configuration of DVB, or more general MPEG2 based, networks is tackled in several other environments with different prerequisites. IP over Cable Data Networks (IPDCN) working group is working in this area and is specifying several MIB modules with respect to MPEG2 network configuration. DVB itself has defined several mechanism to configure receivers, such as system information tables (SI tables), or within MHP. Configuration of IP hosts is focus of the Network Configuration (NETCONF) working group, Dynamic Host Configuration (DHC) working group, and defined in several RFC documents (IPV6 neighbor discovery, IPv4 Address Resolution Protocol (ARP)). Stiemerling Expires August 15, 2005 [Page 7] Internet-Draft IPDVB Address Configuration February 2005 5. Conclusions This memo is first attempt to solve the questions on how future IPDVB networks can deal with IP address resolution and address configuration. Open questions are: o What are the configuration scenarios? o What exactly should be configured? o How to configure? o Who is in control of the receiver? The operator is in control of the receiver in the case of MHP. Users running a DVB PC adaptor have full control over their receiver and network operators running their routers on DVB network a likely not to give away control over their equipment. During the first discussions at the 61st IETF some differences between IPDVB and other network configuration techniques have been noted. The NETCONF approach is made for single router configuration and is not intended to configure thousands of host at the same time. IPCDN on the other hand considers 1*10e3 hosts per cable head end to be configured. IPDVB must consider up to 1*10e5 hosts per segment, see Section 2. This must be definitely taken into account when designing a solution. This memo is neither accurate nor complete at this point of time and should trigger the discussions within the IPDVB working group. Feed back to this memo is welcome. Stiemerling Expires August 15, 2005 [Page 8] Internet-Draft IPDVB Address Configuration February 2005 6. Security Considerations Security considerations are to be done in future revisions of this document. Stiemerling Expires August 15, 2005 [Page 9] Internet-Draft IPDVB Address Configuration February 2005 7. References 7.1 Normative References [1] Fairhurst, G. and B. Collini-Nocker, "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks", draft-fair-ipdvb-ule-02 (work in progress), November 2003. [2] Montpetit, M., "A Framework for transmission of IP datagrams over MPEG-2 Networks", draft-ietf-ipdvb-arch-03 (work in progress), January 2005. 7.2 Informative References [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993. Author's Address Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 EMail: stiemerling@netlab.nec.de URI: http://www.stiemerling.org/ipdvb Stiemerling Expires August 15, 2005 [Page 10] Internet-Draft IPDVB Address Configuration February 2005 Appendix A. Acknowledgments Parts of this work are a product of the Enthrone project supported in part by the European Commission under its Sixth Framework Programme. It is provided as is and without any express or implied warranties, including, without limitation, the implied warranties of fitness for a particular purpose. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Enthrone project or the European Commission. Stiemerling Expires August 15, 2005 [Page 11] Internet-Draft IPDVB Address Configuration February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stiemerling Expires August 15, 2005 [Page 12]