Individual Submission Y. Noisette Internet Draft France Telecom R&D draft-noisette-v6ops-unmannet-isp-reqts-00.txt September 2002 Expires: March 2003 ISP requirements for IPv6 unmanaged networks < draft-noisette-v6ops-unmannet-isp-reqts-00.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document proposes to identify the elementary network functions required to automatically deploy an IPv6 home network, i.e. with the minimum (and ideally not a single) intervention from any administrator or any user. The next generation Internet Protocol, IPv6, is expected to being deployed in environments such as homes and SOHOs. However, most of the people making use of the Internet at home don't have enough knowledge to set up on their own the network and services. Therefore, this document exposes the requirements necessary to ease such a deployment, from an ISP point of view. Contents 1. Introduction 2. Conventions used in this document 3. Definitions and context limitations 3.1 Definitions 3.2 Context limitations 4. Addressing scheme 4.1 Hosts addressing on the LAN 4.2 Prefix advertisement 5. Routing 5.1 Routing performed by the HAD 5.2 Access using a bridge and degenerated case 6. Name <-> Address resolution 6.1 Setting a host name 6.2 Name <-> Address resolution for hosts inside the home network 6.3 Resolution for hosts outside the home network 6.4 Reverse DNS 6.5 Accessing host from the outside 7. Multicast 8. Transition aspects 9. Security Considerations 10. To Do's 11. Acknowledgements 12. References 13. Authors' Addresses 14. Full Copyright 1. Introduction This document proposes to identify the elementary network functions required to automatically deploy an IPv6 home network, i.e. with the minimum (and ideally not a single) intervention from any administrator or any user. The next generation Internet Protocol, IPv6 [RFC 2460], is expected to being deployed in environments such as homes and SOHOs. Indeed, thanks to the large address space offered, it is now conceivable that each device in the house gets at least one global and unique address from and to which it will be accessible. However, most of the people making use of the Internet at home don't have enough knowledge to set on their own the network and services that will enable them to have an entire domestic network at their disposal. Therefore, this document exposes the requirements necessary to ease such a deployment, from an ISP point of view. This document only deals with defining the requirements for IPV6 deployment in such environments, notably by identifying what are the expected features an unmanaged home network has to rely on. When possible, it will point to some conceivable and foreseen solutions and the possible hurdles that can be encountered. The aim of this document is not to select the best mechanism for a use or another, neither to define a new protocol or a network service. It intends however to ease the identification of the missing elements, which could lead to new specifications in the future. This work only deals with layer 3 and upper layers functionalities and services. Among the tackled subjects, the triptych addressing - routing - naming is considered, but the document isn't limited to these features, though these ones are the basis of IP networking. Many other ones will have their role in the home network, for different reasons, either for privacy reasons (security), or the future development and use of services (multicast), or consideration of the existing IPv4 infrastructure... 2. Conventions used in this document 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 [RFC 2119]. 3. Definitions and context limitations 3.1 Definitions The following definitions are relevant for the rest of the document: * IP subnet: a single logical IP network that may span multiple link layer networks. All IP hosts on the IP subnet communicate without any layer 3 forwarding device (e.g. router). * bridge: a networking device that connects two link layer networks by using only link-layer protocols (e.g. Ethernet). * multilink subnet: a collection of independent links, connected by a router, but sharing a common subnet prefix. 3.2 Context limitations The document assumes that the home network is connected to an ISP. However, the characteristics of this connection may vary from one user to another, and especially: * The access link between the unmanaged network and the ISP can be either static, i.e. a permanent connection, or dynamically established, i.e. a dial-up or ISDN connection. * The network can be connected by means of a dedicated device (gateway or router), which will be further referenced as the Home Access Device or HAD. Another possibility is to use a bridge. Finally, in a degenerated case, an unmanaged network can consist in a single host, directly connected to an ISP. In a first step, the home network itself is supposed to be a "flat" network, i.e. a single IP subnet on the LAN side, with no other layer 3 device intervening in the architecture. In the case this subnet is a multi-link subnet, the considerations tackled in [MULTILINK] will apply. The layer 2 technologies used to interconnect the different equipments in the house (Bluetooth, PLC...) are outside the scope of this document. Multihoming considerations are not tackled in this version and are left for further study. By default, this document will focus on the case of a network connected to an ISP thanks to a router or gateway (the HAD), with a dynamically established connection. Unless stated otherwise, the requirements will apply also to the other cases. When necessary, considerations will be exposed about the requirements for any other specific case. Therefore the network can look like the example given on figure 1 below. [home node] [home node] [home node] [home node] | | | | | | | | +---------------------+-------.........--------+-----------------+ | | Single IP subnet | +--------------------+ | home access device | | HAD | +--------------------+ | | | +-----+ | ISP | | | +---+-----+---+ | | | Internet | | | Figure 1: Home network 4. Addressing scheme A first requirement to set up an IPv6 home network is that any device connected in the subnet must get at least one IPv6 address. The way by which a device will get it (them) without intervention from the user must be defined. This is the purpose of this paragraph. Many kind of addresses with different scopes can coexist in an IPv6 network. Only the addresses that are likely to be used within the context of an unmanaged home network will be discussed here. This restriction doesn't cover addresses that are required by default on a node (loopback, all-nodes multicast, solicited-node multicast addresses, ...). Therefore: * Unicast addresses with site-local scope won't be discussed as more work is needed in this area. Definition of site boundaries, dual-sited devices, among others, are subjects that need clarifications. * Anycast addresses are kept for further study as the use of these addresses is still under discussion in the IETF. However, the advantages of using such addresses to deploy services has already been perceived. * Multicast addresses from either scope are considered in the paragraph dedicated to multicast. 4.1 Hosts addressing on the LAN For any host connected to the network, a link-local address at least is automatically configured on each interface. This is one of the features offered by IPv6, stateless autoconfiguration of addresses [RFC 2462]. In an unmanaged network, those link-local addresses may be used by devices to communicate within the authorized scope, i.e. one link of the home network. This scope may be extended to more links in case of multi-link subnet [MULTILINK]. These addresses suit perfectly in so far as communications are limited to the home network. This won't certainly be the case all the time, as hosts are expected be able to communicate with other hosts outside the home, when connected to an ISP. Therefore, the way hosts will acquire global addresses is to be considered. Moreover, these global unicast addresses may be used by hosts for their communications inside the house, instead of link-local addresses. Global-unicast addresses can be configured manually, but in our scenario, autoconfiguration will be preferred. Therefore, global-unicast addresses will be configured automatically as described in [RFC 2462]. This process requires however that a prefix is advertised by some means on the IP subnet. This topic is tackled below. Requirements: * when connected to an ISP, a global prefix MUST be advertised on the subnet which will be used by hosts to automatically configure at least one global-unicast address 4.2 Prefix advertisement One way to learn global prefixes is by means of Router Advertisements. These ones are sent periodically by routers, or solicited by nodes thanks to Router Solicitation messages. Thus, in the case of an unmanaged home network, one strong hypothesis is that a device has to run a routing process to send RAs among other features. This device can be either the HAD, if any, or the ISP's router, to which the home is connected. 4.2.1 HAD performs router advertisements We assume in the following that the HAD is a router and performs Prefix Advertisement. The question then is how it will learn the prefixes it has to announce in the RAs. By default, prefixes have to be manually configured on the router, but that's exactly what we want to avoid in our scenario. Therefore, a feature has been considered which is intended to answer this particular issue: automatic prefix delegation. The purpose of this feature is to enable a router connected to the network to discover and learn automatically, and without human intervention, what prefix(es) it will be able to use on its interfaces. The requirements for such a mechanism are defined in details in [PD-REQ], and many propositions have already been made in order to handle this issue ([APD2], [DHCP-PD],[PD]...). As already said, using another layer 3 device is outside scope of this document at this stage. This leads to consider that a single IPv6 prefix, that won't be further distributed, can serve the home network. The size of the prefix can be /64 but also /48 or other, depending on the ISP choice, though a /64 is intended to be enough. Requirements: * if present, the HAD MUST implement a prefix delegation mechanism that will enable it to learn a prefix to advertise 4.2.2 Access using a bridge and degenerated case In this case, the ISP CPE advertises the prefix. The way this prefix is configured depends on the ISP choices. It can be either manually configured, or learnt by a delegation mechanism. Requirements: * if the home subnet is directly connected to the ISP, the ISP's CPE MUST advertise a global-unicast prefix 4.2.3 Dynamically established connections In this case, the prefix advertised on the home network may change overtime when the user connects to the ISP. Though renumbering can be considered as a solution, it should be more convenient that a client gets the same prefix delegated each time he will connect. Requirements: * a stateful prefix delegation mechanism MUST be used in case of dynamically established connections 5. Routing In order to let hosts on the home subnet be able to communicate with hosts from the outside, the network must provide some routing features, which will enable the traffic to be forwarded. The routing must be considered from two different points of view: * How the outgoing traffic will reach its destination? By outgoing traffic, we mean any traffic whose source is inside the home network and whose destination is outside it. * How a host inside the home network will be reachable from the outside? As already mentioned, we consider in a first step that the home network is a single subnet. Therefore, no forwarding is necessary when hosts from the house are communicating with each other. 5.1 Routing performed by the HAD By default, all traffic that needs to reach any address outside the home network has to be forwarded to the ISP to which the HAD is attached. We can identify some possibilities to achieve this: * a static route can be self-configured on the access device, which will set a default route to the next hop materialized by the ISP CPE. * another solution would be to activate a routing protocol on the access device's interfaces, which will enable the routes to be exchanged with the ISP. This kind of feature was tackled in the first version of [APD] for instance, but no real solution exists today. This implies however that a new mechanism has to be defined, which will allow routers to negotiate the routing protocol to activate. * A default routing protocol can also be imposed by the ISP. This last solution is difficulty conceivable, as it will compel either: * The client to activate himself the routing protocol chosen by the ISP he is connected to. This solution goes towards what we expect to deploy in this document. * The access device is configured by default to activate a given routing protocol. This is difficultly possible as it restricts the functionalities of the HAD. Requirements: * a mechanism MUST be defined to allow the automatic configuration of a static route on a router OR/AND * a mechanism MUST be defined to allow the negotiation between routers of the routing protocol to activate on the access interface * these two mechanisms MUST be secured * the HAD MUST announce itself (and its address) as the default gateway on the home network 5.2 Access using a bridge and degenerated case If case a bridge is used, or in the degenerated case, no routing process is required in the home. Requirements: * the ISP CPE MUST announce itself (and its address) as the default gateway on access link of the home network * the ISP CPE MUST ensure the forwarding of any traffic to and from the home network 6. Name <-> Address resolution This paragraph is dedicated to the resolution of Name to Address and vice versa, and how it is to be used within the context of an unmanaged home network. It covers the main following requirements: * hosts in the house MUST get a name * hosts inside the house MUST be able to resolve their names * a host in the house MUST be able to resolve the name of an external host * an external host MUST be able to resolve the name of a host inside the house As stated in [LLMNR], one assumption here is that if the network has a HAD, then the network either has a DNS server or the HAD can function as a DNS proxy. An example is a HAD implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of IPv6 hosts on the local network. In the degenerated case, all information required, registration... etc will be managed as it is today. 6.1 Setting a host name The complete name is built by concatenation of a friendly name with a domain name. The way hosts get their friendly name is outside the scope of this document. The user can for instance enter the name when the device is switched on for the first time. The manufacturer can also configure it statically and by default or rely on other technologies (UPnP, OSGi...). The domain name is compulsory for hosts to set their name. Beside manual configuration, a means by which hosts will acquire the domain name in use on the network MUST then be specified. 6.1.1 Make use of a private domain name A first solution is that hosts on a home network make use of a dedicated domain name, which would be used by anyone, but whose scope would be limited. This solution was tackled in [HOMEDNS] but was the approach was too restrictive. [PRIVDNS] proposes a similar but more open solution. It defines a new domain name, "private.arpa.". This proposition allows devices to construct a fully qualified domain name for use locally, and corrals the automatically configured names in the global DNS namespace. [PRIVDNS] imposes however a DNS server (or at least a proxy) in the home, and therefore in our scenario, an automatic registration of the hosts. Moreover, it introduces some conditions when hosts are to be accessed from the outside. This topic is tackled in section 6.5. Requirements: * a private fully-qualified domain name MUST be dedicated for unmanaged networks * this domain name MUST be consistent with the DNS system * the diffusion of the names MUST be strictly limited to the scope where they are meaningful and won't introduce any incoherence 6.1.2 Make use of a public domain name Another conceivable solution is that the client gets his own personal domain name, which would be used in his house. This possibility keeps the coherence of the DNS system safe, but implies many constraints on ISPs which would have to deal with the attribution of a correct domain name to their customers. There would also be precedence issues, as many mister Doe would like to get their domain (.doe.hom for instance). Also, domain names are not free, and sold for a certain amount of time only, each user is obliged to re-conduct his domain name before it expires. Moreover, this implies that the domain name has to be learnt by some means on the network, and announced to all the devices on it. This is conceivable if a DNS server or a proxy is available. A protocol has however to be defined so that the HAD will receive the domain name to use once this one will be bought. Requirements: * A mechanism or process MUST ensure the correct configuration and spread of the domain name in the home network 6.2 Name <-> Address resolution for hosts inside the home network 6.2.1 Dynamic connection with no DNS service on the home network In the case of a dynamic connection, the network won't always be connected to the ISP. If no DNS service is available on the home network, a mechanism MUST ensure the resolution of Name <-> Address. One proposed solution is to send a request to a special link-local (multicast) address derived from the name. This solution is tackled in [LLMNR]. It notably implies that each connected node is supposed to listen to the special address derived from its name, and answers any request sent to this particular address. This might be a bit difficult to enable any IPv6 device in the house to do so, as some could be really simple elements. However, this solution avoids the use of a DNS server. Another proposition is based on the addition of new ICMP messages for node information queries [NODEDNS] and relies almost on the same features (use of a link-local multicast address based on the required name...). A set of documents has also been proposing a solution for name resolution in zeroconf environments [Z-LKUP] and [Z-REVLK]. They also make use of multicast. Requirements: * a mechanism for Name<->Address resolution MUST be available when the home network is disconnected from the ISP and no DNS service is available * hosts MUST rely on a DNS service when it becomes available 6.2.2 A DNS service is available In this case, the home network or the ISP (in so far as the connection is up. If it is down, we come back to point 6.2.1) provides the DNS service. These two solutions raise the following issues: * First, the hosts in the house must discover the DNS server. There is ongoing effort in this area, and only one at the moment [DNSDISC] provides an acceptable solution in an unmanaged network. * Second, hosts MUST register to the DNS server/proxy. Once again, some mechanisms have been proposed to the Internet community to answer this situation. For instance Dynamic DNS [RFC2136] provides this feature. Other solutions have been put forward, like [AUTOREG1] and [AUTOREG2]. Both use an architecture where both a resolver/detector and a registrar are used. The resolver/detector has to be on the home network subnet, in so far as it listens to DAD messages. The registrar can be either situated in the house or at the provider side. One drawback if the DNS service is provided by the ISP is that it implies the connection to the ISP is up. Moreover, this would lead to generate traffic outside the house, which could quite easily be kept inside the user's home. Finally, if a fully-qualified private domain name is used in the home, ISP would have to deal with it. Therefore, it might be more conceivable that a DNS server/proxy is running on the user's subnet. Requirements: * a mechanism MUST allow hosts to discover a DNS server (whether this server is located in the home or in the ISP backbone) * if a HAD is present on the home network, it SHOULD run a DNS server or proxy * an automatic registration process in the DNS MUST be available for hosts * if the DNS is provided by the ISP and a fully-qualified private domain name is used, the ISP DNS service must ensure the correct handling and protection of the different home networks records. 6.3 Resolution for hosts outside the home network Another requirement for a subnet attached to an ISP is that hosts on that subnet must be able to resolve names of hosts situated outside the house. Like for hosts inside the house, the name-address resolution for hosts situated outside the house can also be performed either by a DNS server/proxy situated inside the house, outside the house or both. Once again, one point to answer will be how the devices inside the house will discover the DNS server. [DNSDISC] provides a good solution applicable if the DNS server(s) are situated either on the ISP and/or the home side. This solution implies however the good definition and limitation of the site as this mechanism uses site-local addresses for the discovery. If the resolution is to be performed by a home DNS server/proxy, then this one will need to rely on the ISP DNS servers for the entries which won't be present in its cache. It will then have to forward the request to its counterparts on the ISP side. Requirements: * a mechanism MUST allow hosts to discover a DNS server (whether this server is located in the home or in the ISP backbone) * if a DNS server/proxy is present in the home, it MUST forward any request for which it has no answer to the ISP DNS. Therefore, a mechanism MUST allow the home server/proxy to learn the address of the ISP server 6.4 Reverse DNS Either the ISP or the client's DNS server can perform reverse DNS, even if the second solution seems easier if the registration process is to be automatic as required in this document. In the case a private domain name is used, this information might be considered as irrelevant (need further study). Requirements: * reverse DNS MUST be performed by either the ISP or the home server (if any) * a mechanism MUST allow the automatic registration of the PTR records 6.5 Accessing host from the outside Finally, hosts inside the house have to be reachable in some way by hosts situated outside. This requires the resolution of their name into one of their global-unicast address when others try to contact them. 6.5.1 Public domain name used in the home If the domain name used in the home is public, this feature, together with reverse DNS, can be performed by either the ISP or the client's DNS server, even if the second solution seems easier if the registration process is to be automatic as required in this document. Requirements: * name-address resolution request for host located in the home MUST be performed by either the ISP or the home server (if any) 6.5.2 Private domain name used in the house [HOMEDNS] provides a solution when a private domain name is used. In this solution, the access to hosts inside the house is performed thanks to the house DNS server which is asked for any request where the suffix is ".$pvt". Therefore, this solution behaves like a "DNS-NAT" as all hosts are hidden behind a single public point, which is the DNS server name. Just like a NAT today, this ensures some kind of protection, as the home network hosts can't be accessed by their name unless one knows the home DNS server name. And even then, some security mechanism is required in the transmission. This solution could be also adapted and applied within the context proposed in [PRIVDNS]. However, this proposition needs more discussion and improvements. For instance, if someone wants to run a server, that he wants to be accessible from outside, he needs to register it with a public name explicitly to his ISP, or give access to it explicitly, with the setting the authorization required. Requirements: * when a private domain name is used in the home, a mechanism MUST ensure that hosts inside the home network are reachable from the outside * this mechanism MUST be secured 7. Multicast Multicast is a key feature, on which many services may rely in the near future. Therefore, enabling multicast in the home network could be an important aspect in the forthcoming years, as soon as operators and content providers will ship more and more content delivery services based on this technology. One might assume that multicast is a mandatory feature in the home network. There are two main points that are to be ensured to make the multicast service available: * On the house subnet, a multicast protocol dedicated for hosts to router communications, Multicast Listener Discovery version 2 [MLDv2] for instance, MUST be automatically activated. This operation could be done quite easily if manufacturers make the routing process active by default on the HAD. * On the access link, another multicast protocol MUST be activated, for instance PIM-SM [PIM], that will enable the home network to use the multicast infrastructure provided by the ISP to reach the multicast services the user needs. The activation of PIM-SM MUST also intervene without the intervention of the user. This operation can be done if the manufacturers set it as a default process the access device must run when starting up. Some parameters might need to be provided, like the RP (Rendez-vous Point). These parameters may be provided by the ISP among other elements, or configured by default in the access device. Multicast deployment can also be restricted if some NBMA technologies are deployed inside the home network. This discussion is out the scope of this document. Requirements: * on the house subnet, a multicast protocol dedicated for hosts to router communications MUST be activated * on the access link, another multicast protocol MUST be activated enable the home network to use the multicast infrastructure provided by the ISP 8. Transition aspects In this document, we consider that the home network is IPv6 only. Any question on this topic should find an answer in the work initiated by the dedicated Design Team within the ngtrans working group, whose scope is defined in [TRS-ZCNF], and whose work is now part of the v6ops WG [V6OPS]. Therefore, the selected hypothesis is that the unmanaged home network only contains IPv6-only hosts. However, this doesn't prevent these hosts from initiating or receiving communication to or from IPv4-only hosts or servers. In this case, the transition mechanism used should be provided by the ISPs network or implemented in the HAD. As an example, an ISP could deploy NAT-PT in its network to enable its IPv6 client to carry on accessing IPv4-only web servers. To be more precise, the requirements are the following: Requirements: * the ISP MUST deploy mechanisms or provide devices to ensure an IPv6 host in the house can access an external IPv4 host and vice-versa * the ISP MUST deploy mechanisms to ensure a host in the house can contact any external IPv6 host, even if the path goes across an IPv4 cloud and vice-versa 9. Security Considerations This document doesn't introduce any new security threat in itself, as it doesn't define any new protocol or feature. However, it points out and underlines some aspects related to security, which are mentioned below. Security is a very important feature for the home network, as anyone dreads that a malicious person could enter his/her intimacy. Attacks can take many forms that are to be prevented: * Traffic exchanged inside the house or with the outside can be caught * Someone can gain control on devices inside the house * Denial of service attacks can be performed on a client's gateway, DNS server... * ... The IPv6 specification includes the mandatory support for the IPSec mechanism. Notably [IPV6NODE] imposes that the support of these mechanisms in any IPv6 node. This decision makes it possible to reduce significantly the threats in so far as IPSec is really used and as the required element are furnished to the hosts (what about Ipv6 node requirements). For instance, devices may need a PKI infrastructure, certificates... or others. In an unmanaged network, it is expected that the client won't have to do anything in this aim. However, unmanaged networks MUST NOT be any less secure than any other networks. This consideration overrides the goal of allowing systems to obtain configuration automatically. The paragraph "Security considerations" of [ZEROCONF] provides much elements on this topic, related to zeroconf environments. Some mechanisms quoted in this document already provide some clues to secure the traffic exchanges or the processes engaged, but the support of IPSec is the minimum expected from any IPv6 device. Therefore, in case there are no other mechanisms to rely on for security, IPSec should be available to assume this role. 10. To Do's The possible remaining work could comprise: * Use of anycast addresses in the house * Use of site-local addresses in the house * Multi-subnet home network (impact on forwarding, addressing,...) * Multi-router home network (impact on forwarding, addressing,...) * Multi-homing * Quality of service * Mobility * Service discovery 11. Acknowledgements The author would like to acknowledge the work of A. Williams, Jun-ichiro itojun Hagino, B. Haberman, D. Thaler, B. Aboba among others for the important work they lead and on which this document heavily relies. Thanks also to S. Auvray, L. Beloeil and D. Binet who have reviewed this draft. 12. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC 2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC 2463] A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)Specification", RFC 2463, December 1998. [APD] B. Haberman and J. Martin, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6), draft-haberman-ipngwg-auto -prefix-02.txt, February 2002, work in progress [PD] N. Lutchansky, "IPv6 Router Advertisement Prefix Delegation Option", draft-lutchann-ipv6-delegate-option-00.txt, February 2002, work in progress [DHCP-PD] O. Troan and R. Droms, "IPv6 Prefix Options for DHCPv6", draft- troan-dhcpv6-opt-prefix-delegation-00.txt, February 2002, work in progress [HOMEDNS] Tomohide Nagashima, "Technique of DNS use at home network", draft- tomohide-tech-homedns-00.txt, July 2001, work in progress [AUTOREG1] H. Kitamura, "Domain Name Auto-Registration for Plugged-in IPv6 Nodes", draft-kitamura-ipv6-name-auto-reg-02.txt", July 2002, work in progress [AUTOREG2] S.Gopinath Rao and K. Ettikan, "IPv6 Hostname auto- registration Procedure", draft-gopinath-ipv6-hostname-auto-reg- 01.txt, May 2002, work in progress [DNSDISC] D. Thaler and Jun-ichiro itojun Hagino, "IPv6 Stateless DNS Discovery", draft-ietf-ipv6-dns-discovery-04.txt, March 2002, work in progress [NODEDNS] M. Crawford, "IPv6 Node Information Queries", draft- ietf-ipngwg-icmp-name-lookups-09.txt, May 2002, work in progress [LLMNR] L. Esibov, B. Aboba and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-10.txt, March 2002, work in progress [MLDv2] R. Vida, L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-02.txt, January 2002, work in progress [PD-REQ] S. Miyakawa, "Requirements for IPv6 prefix delegation", , June 2002, work in progress [Z-LKUP] Jun-ichiro itojun Hagino, "Name resolution in zeroconf environment using ICMPv6 node information query", , June 2002, work in progress [Z-REVLK] Jun-ichiro itojun Hagino, "Use of ICMPv6 node information query for reverse DNS lookup", < draft-itojun-ipv6-nodeinfo-revlookup- 00.txt>, June 2002, work in progress [TRS-ZCNF] C. Huitema, "Unmanaged Networks Transition Scope", , June 2002, work in progress [MULTILINK]D. Thaler, C. Huitema, "Multi-link subnet support in IPv6", , June 2002, work in progress [PRIVDNS] A. Williams, "A locally scoped DNS namespace", , July 2002, work in progress [DHCPv6DNS]R. Droms, T. Narten, B. Aboba, "Using DHCPv6 for DNS Configuration in Hosts", , March 2002, work in progress [IPV6NODE] J. Loughney, "IPv6 node requirements", , July 2002, work in progress [ZEROCONF] A. Williams, "Zeroconf IP host requirements", , August 2002, work in progress [PIM] http://www.ietf.org/html.charters/pim-charter.html [V6OPS] http://www.ietf.org/html.charters/v6ops-charter.html 13. Authors' Addresses Yoann Noisette yoann.noisette@rd.francetelecom.com 14. Full Copyright Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.