Internet Engineering Task Force T. Savolainen Internet-Draft Nokia Intended status: Standards Track J. Kato Expires: March 21, 2011 NTT September 17, 2010 Improved DNS Server Selection for Multi-Homed Nodes draft-savolainen-mif-dns-server-selection-04 Abstract A multi-homed node can be connected to multiple networks that may utilize different DNS namespaces. The node often receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When the multi-homed node needs to utilize DNS, it has to choose which of the servers to contact to. This document describes a policy based method for selecting DNS server for both forward and reverse DNS lookup procedures with help of DNS suffix and IPv6 prefix information received via DHCPv6. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 21, 2011. Copyright Notice Copyright (c) 2010 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 Savolainen & Kato Expires March 21, 2011 [Page 1] Internet-Draft MIF and DNS server selection September 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Problem description for local namespaces with multi-homed nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Fully qualified domain names with limited scopes . . . . . 4 2.2. Network interface specific IP addresses . . . . . . . . . 4 3. Improved DNS server selection procedure . . . . . . . . . . . 6 3.1. DNS server selection option . . . . . . . . . . . . . . . 7 4. Example of a node behavior . . . . . . . . . . . . . . . . . . 9 5. Scalability considerations . . . . . . . . . . . . . . . . . . 12 6. Considerations for network administrators . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9.1. Suffix matching example . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Best Current Practice for DNS server selection . . . 15 A.1. Search list option for DNS forward lookup decisions . . . 15 A.2. More specific routes for reverse lookup decision . . . . . 15 A.3. Longest matching prefix for reverse lookup decision . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Savolainen & Kato Expires March 21, 2011 [Page 2] Internet-Draft MIF and DNS server selection September 2010 1. Introduction A multi-homed node faces several problems over single-homed node as is described in [I-D.ietf-mif-problem-statement]. This document studies in detail the problems local namespaces may cause for multi- homed nodes in the IPv4 and IPv6 domains and provides a solution. The node may be implemented as a host, or as a router such as Consumer Premises Equipment. When multiple namespaces are visible for a node, some DNS servers have information other servers do not have. Because of that, a multi-homed node cannot assume every DNS server is able to provide any piece of information, but instead the node must be able to ask right server for the information it needs. An example of an application that benefits from multi-homing is a web browser that commonly accesses many different destinations and should be able to dynamically communicate over different network interfaces. However, as the IPv4 is being phased out and often uses NATs to achieve similar functions, this document describes a solution only for the IPv6 domain. In deployments where multiple namespaces are present, selection of the correct destination and source addresses for the actual IP connection is usually crucial as well, as the resolved destination's IP address may be only usable on the network interface over which it was resolved on. Hence solution described in this document is assumed to be often used in combination of tools delivering source and destination address selection policies. 1.1. Requirements Language 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]. 2. Problem description for local namespaces with multi-homed nodes This chapter describes two host multi-homing related local namespace scenarios for which the procedure described in chapter 3 provides a solution. Essentially the same challenges may be faced by Consumer Premises Equipment as is described in [I-D.troan-multihoming-without-nat66]. Savolainen & Kato Expires March 21, 2011 [Page 3] Internet-Draft MIF and DNS server selection September 2010 2.1. Fully qualified domain names with limited scopes A multi-homed host may be connecting to one or more networks that are using local namespaces. As an example, the host may have simultaneously open a wireless LAN (WLAN) connection to public Internet, cellular connection to an operator network, and a virtual private network (VPN) connection to a corporate network. When an application initiates a connection establishment to an FQDN, the host needs to be able to choose the right network interface for making a successful DNS query. This is illustrated in the figure 1. An FQDN for a public name can be resolved with any DNS server of any network interface, but for an FQDN of corporation's or operator's service's local name the host would need to be able to correctly select the right network interface for the DNS resolution, i.e. do interface selection already before destination's IP address is known. +---------------+ | DNS server w/ | | Corporate +------+ | public + |----| Intranet | | | corporation's | | | |===== VPN =======| local names | | | | +---------------+ +----+ | MIF | | FW | | host | +----+ | | +---------------+ | | |----- WLAN ------| DNS server w/ |----| Public | | | public names | | Internet | | +---------------+ +----+ | | | FW | | | +---------------+ +----+ | |---- cellular ---| DNS server w/ | | +------+ | public + | | Operator | operator's |----| Intranet | local names | | +---------------+ Split DNS and locally scoped names illustrated Figure 1 2.2. Network interface specific IP addresses In the second problem an FQDN as such is valid and resolvable via different network interfaces, but to different and not necessarily globally reachable IP addresses, as is illustrated in the figure 2. This is a problem when a host is single-homed, but for multi-homed host this results in additional challenges: the host's source and Savolainen & Kato Expires March 21, 2011 [Page 4] Internet-Draft MIF and DNS server selection September 2010 destination address selection mechanism must ensure the destination's IP address is only used in combination with source IP addresses of the network interface the name was resolved on. +--------------------| | +------+ IPv6 | DNS server A |------| IPv6 | |-- interface 1 --| saying Peer is | | | | | at: 2001:0db8:0::1 | | | MIF | +--------------------+ +------+ | host | | Peer | | | +--------------------+ +------+ | | IPv6 | DNS server B | | | |-- interface 2 --| saying Peer is | | +------+ | at: 2001:0db8:1::1 |------| IPv6 +--------------------+ | Split DSN and different IP addresses for an FQDN on interfaces 1 and 2. Figure 2 Similar situation can happen when IPv6 protocol translation is used in combination with AAAA record synthesis proceduce [I-D.ietf-behave-dns64]. A synthesised AAAA record is guaranteed to be valid only on a network interface it was synthesized on. Figure 3 illustrates a scenario where the peer's IPv4 address is synthesized into different IPv6 addresses by DNS servers A and B. The same problem can happen in the IPv4 domain as well if A record synthesis is done, for example as described in Bump-In-the-Stack [RFC2767]. For a related problem for dual-stack hosts in a network with DNS64, where IPv4 should be prioritized over synthesized IPv6, please see [I-D.wing-behave-dns64-config]. Savolainen & Kato Expires March 21, 2011 [Page 5] Internet-Draft MIF and DNS server selection September 2010 +-------------------| +-------+ +------+ IPv6 | DNS server A |----| NAT64 | | |-- interface 1 --| saying Peer is | +-------+ | | | at: A_Pref96:IPv4 | | | MIF | +-------------------+ | +------+ | host | IPv4 +---| Peer | | | +-------------------+ | +------+ | | IPv6 | DNS server B | | | |-- interface 2 --| saying Peer is | +-------+ +------+ | at: B_Pref96:IPv4 |----| NAT64 | +-------------------+ +-------+ AAAA synthesis results in interface specific IPv6 addresses. Figure 3 A more complex scenario is an FQDN, which in addition to resolving into network interface specific IP addresses, identifies on different network interfaces completely different peer entities with potentially different set of service offering. In even more complex scenario, an FQDN identifies unique peer entity, but one that provides different services on its different network interfaces. The solution described in this document is not able to tackle these higher layer issues. In fact, some of the problems may be solvable only by user intervention. A thing worth noting is that interface specific IP addresses can cause problems also for a single-homed host, if the host retains its DNS cache during movement from one network interface to another. After the interface change a host could have both positive and negative DNS cache entries invalid for the new network interface. Because of this the cached DNS information should be considered network interface local instead of node global. 3. Improved DNS server selection procedure This chapter documents a procedure a (stub / proxy) resolver may utilize for DNS server selection in face of multiple namespaces. Essentially, the resolver shall dynamically build for each DNS query a priority list of DNS servers it will try to contact to. The resolver shall cycle through the list until a positive reply is received, or until all selected DNS servers have been contacted or timed out. (DISCUSS: What about those DNS servers that instead of negative answer always return positive reply with an IP address of some default HTTP server, which purpose is just to say 'authenticate' Savolainen & Kato Expires March 21, 2011 [Page 6] Internet-Draft MIF and DNS server selection September 2010 or 'page not found'? Maybe DNSSEC would help here, i.e. roll through DNS servers until one provides a response that can be validated?) To prioritize DNS servers in an optimal way, the resolver should ask with DHCPv6 which DNS servers are most likely able to successfully serve forward lookup requests matching to specific DNS suffixes or reverse (PTR record) lookup requests matching to specific IPv6 prefixes. A resolver lacking more explicit information shall assume that all information is available from any DNS server of any network interface. Additionally, the resolver may utilize any other information it may have, e.g. possible user's preferences, node's general preferences between network interfaces, differences on trust levels of network interfaces (see Security Considerations), or any other piece of information. When a resource record is to be resolved, the resolver MUST give highest precedence to the DNS servers explicitly known to serve matching suffixes or prefixes. A node may need to remember the interface used for successfuly query in order to be able to improve source address selection. For the scenario where an FQDN maps to same service but different IP addresses on different network interfaces, the source address selection algorithm must be able to pick a source address from the network interface that was used for DNS resolution. When local namespace are present a negative reply from a DNS server implies only that the particular DNS server was not able to serve the query. However, it is not probable that the secondary DNS servers on the same network interface, on a same administrative domain, would be able to serve either. Therefore, the next DNS server resolver contacts should be from another network interface. 3.1. DNS server selection option A DHCPv6 option described below is used to inform nodes which DNS server should be contacted when initiating forward or reverse DNS lookup procedures. Savolainen & Kato Expires March 21, 2011 [Page 7] Internet-Draft MIF and DNS server selection September 2010 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_DNS_SERVER_SELECT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-recursive-name-server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |prf| Reserved | | +-+-+-+-+-+-+-+-+ DNS suffixes and prefixes | | (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_DNS_SERVER_SELECT (TBD) option-len: Lenght of the option in octets DNS-recursive-name-server: An IPv6 address of a DNS server prf: DNS server preference: 01 High 00 Medium 11 Low 10 Reserved - MUST NOT be sent Reserved: Flags reserved for the future. MUST be set to zero. DNS suffixes and prefixes: The list of DNS suffixes for forward DNS lookup and prefixes for reverse DNS lookup the DNS server has special knowledge about. Field MUST be encoded as specified in section "Representation and use of domain names" of [RFC3315]. Additionally, special suffix of "." is used to indicate capability to resolve global names. Lack of "." suffix on the list indicates DNS server has only local information. Prefixes for reverse mapping are encoded as defined for ip6.arpa [RFC3152]. DHCPv6 option for explicit DNS suffix configuration Figure 4 The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the Savolainen & Kato Expires March 21, 2011 [Page 8] Internet-Draft MIF and DNS server selection September 2010 related DNS server has particular knowledge of (i.e.. local namespaces). The option can occur multiple times in a single DHCPv6 message, if multiple DNS servers are to be configured. A node can prioritize DNS servers with help of preference field. IPv6 prefixes should cover all the DNS suffixes configured in this option. Prefixes should be as long as possible to avoid collision with information received on other option instances or with options received from DHCPv6 servers of other network interfaces. Overlapping IPv6 prefixes are interpreted by a node so that the resolver can use multiple DNS servers for queries mathing the prefixes. As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply. For backwards compatibility reasons the DHCPv6 message containing OPTION_DNS_SERVER_SELECT also likely contains OPTION_DNS_SERVERS option. In case both options contain the same IPv6 addresses, only one copy of the IPv6 address of DNS server shall be added to the DNS server list. In the case of a DNS server replying negatively to a question having matching suffix, it will be for implementation to decide whether to consider that as a final response, or whether to ask also from other DNS servers. The implementation decision may be based, for example, on deployment or trust models. 4. Example of a node behavior Figure 5 illustrates node behavior when it initializes two network interfaces for parallel usage and learns DNS suffix and prefix information from DHCPv6 servers. Savolainen & Kato Expires March 21, 2011 [Page 9] Internet-Draft MIF and DNS server selection September 2010 Application Node DHCPv6 server DHCPv6 server on interface 1 on interface 2 | | | | +-----------+ | (1) | | open | | | | interface | | | +-----------+ | | | | (2) | |---option REQ-->| | |<--option RESP--| | | | | +-----------+ | (3) | | store | | | | suffixes | | | +-----------+ | | | | | +-----------+ | (4) | | open | | | | interface | | | +-----------+ | | | | | (5) | |---option REQ------------------->| | |<--option RESP-------------------| | | | | | +----------+ | | (6) | | store | | | | | suffixes | | | | +----------+ | | | | | | Illustration of learning DNS suffixes Figure 5 Flow explanations: 1. A node opens its first network interface 2. The node obtains DNS suffix and IPv6 prefix information for the new interface 1 from DHCPv6 server 3. The node stores the learned DNS suffixes and IPv6 prefixes for later use 4. The node opens its seconds network interface 2 5. The node obtains DNS suffix, say 'example.com', and IPv6 prefix information, say '8.b.d.0.1.0.0.2.ip6.arpa' for the new interface Savolainen & Kato Expires March 21, 2011 [Page 10] Internet-Draft MIF and DNS server selection September 2010 2 from DHCPv6 server 6. The node stores the learned DNS suffixes and prefixes for later use Figure 6 below illustrates how a resolver uses the learned suffix information. Prefix information use for reverse lookups is not illustrated, but that would go as the figure 6 example. Application Node DHCPv6 server DHCPv6 server on interface 1 on interface 2 | | | | (1) |--Name REQ-->| | | | | | | | +----------------+ | | (2) | | DNS server | | | | | prioritization | | | | +----------------+ | | | | | | (3) | |------------DNS resolution------>| | |<--------------------------------| | | | | (4) |<--Name resp-| | | | | | | Example on choosing interface based on DNS suffix Figure 6 Flow explanations: 1. An application makes a request for resolving an FQDN, e.g. 'private.example.com' 2. A node creates list of DNS servers to contact to and uses configured DNS server information and stored DNS suffix information on priorization decisions. 3. The node has chosen interface 2, as from DHCPv6 it was learned earlier that the interface 2 has DNS suffix 'example.com'. The node then resolves the requested name using interface 2's DNS server to an IPv6 address 4. The node replies to application with the resolved IPv6 address Savolainen & Kato Expires March 21, 2011 [Page 11] Internet-Draft MIF and DNS server selection September 2010 5. Scalability considerations The size limitations of DHCPv6 messages limit the number of suffixes and prefixes that can be carried in a configuration option. Including the suffixes and prefixes in a DHCPv6 option is best suited for deployments where relatively few carefully selected suffixes and prefixes are adequate. 6. Considerations for network administrators Network administrators deploying private namespaces should assist advanced hosts in the DNS server selection by providing information described in this memo for nodes. To ensure nodes' source and destination IP address selection also works correctly, network administrators should also deploy related technologies for that purpose. The solution described herein is best for selecting a DNS server having knowledge of some namespaces. The solution is not able to make the right decision in a scenario where same name points to different services on different network interfaces. Network administrators are recommended to avoid overloading of namespaces in such manner. 7. Acknowledgements The author would like to thank following people for their valuable feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo Bagnulo, Stuart Cheshire, Lars Eggert, Tomohiro Fujisaki, Peter Koch, Suresh Krishnan, Ted Lemon, Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler, Margaret Wasserman, Dan Wing, and Dec Wojciech. This document was prepared using xml2rfc template and the related web-tool. 8. IANA Considerations This memo includes a new DHCPv6 option that requires allocation of a new code point. 9. Security Considerations An attacker may try to lure traffic from multi-homed host to his Savolainen & Kato Expires March 21, 2011 [Page 12] Internet-Draft MIF and DNS server selection September 2010 network by advertising DNS suffixes and prefixes attacker wishes to intercept or deny service of. The node's security should not be based on correct functionality of DNS server selection. Use of DNSSEC is recommended to mitigates risks of forgery. Additionally nodes may employ heuristics to more wisely prioritize network interfaces with conflicting policies. The prioritization may, for example, be based on trust level of a network interface over which policy was learned from. To avoid problem of attacker advertising suffix with wide scope (such as .com) or intentionally narrow scope (such as mail.example.com), the node may want to first match suffixes of highest priority interface and if such match is found, consider information from other interface as lower priority. 9.1. Suffix matching example In this example a host has three interfaces (in decreasing order of priority): 1. Managed tunnel interfaces (such as VPN) considered most trustworthy. Advertises suffix 'example.com' 2. Cellular network advertising default suffix '.' 3. WLAN hotspot with attacker advertising suffixes 'mail.example.com' and '.com' When a host resolves name 'mail.example.com', it will notice the highest priority interface has matching non-default suffix. As the 'example.com' matches to 'mail.example.com', the tunnel interface will be used. Simple longest matching or shortest matching rules would have resulted in the host using attackers network. When a host resolves name 'example2.com', it will find highest matching non-default prefix from WLAN hotspot. While it would have been safer to use cellular network's DNS server, security level is not decreased from what any single interface node would have. The multi-homed host may also choose to always use the most trustworthy interface it has for DNS queries. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Savolainen & Kato Expires March 21, 2011 [Page 13] Internet-Draft MIF and DNS server selection September 2010 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001. [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. 10.2. Informative References [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-10 (work in progress), July 2010. [I-D.ietf-mif-problem-statement] Blanchet, M. and P. Seite, "Multiple Interfaces Problem Statement", draft-ietf-mif-problem-statement-07 (work in progress), August 2010. [I-D.troan-multihoming-without-nat66] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", draft-troan-multihoming-without-nat66-01 (work in progress), July 2010. [I-D.wing-behave-dns64-config] Wing, D., "DNS64 Resolvers and Dual-Stack Hosts", draft-wing-behave-dns64-config-02 (work in progress), February 2010. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. Savolainen & Kato Expires March 21, 2011 [Page 14] Internet-Draft MIF and DNS server selection September 2010 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007. Appendix A. Best Current Practice for DNS server selection On some split-DNS deployments explicit policies for DNS server selection are not available. This section describes ways for hosts to mitigate the problem by utilizing possibly existing indirect information elements as hints. The approach to ask everything from everyone remains always as last resort option. A.1. Search list option for DNS forward lookup decisions A host can learn the special DNS suffixes of attached network interfaces from DHCP search list options; DHCPv4 Domain Search Option number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. The host behavior is very similar as is illustrated in the example at section 3.3. While these DHCP options are not intented to be used in DNS server selection, they may be used by the host for smart DNS server prioritization purposes in order to increase likelyhood of fast and successful DNS query. Overloading of existing DNS search list options is not without problems: resolvers would obviously use the DNS suffixes learned from search lists also for name resolution purposes. This may not be a problem in deployments where DNS search list options contain few DNS suffixes like 'example.com, private.example.com', but can become a problem if many suffixes are configured. A.2. More specific routes for reverse lookup decision [RFC4191] defines how more specific routes can be provisioned for hosts. This information is not intented to be used in DNS server selection, but nevertheless a host can use this information as a hint about which interface would be best to try first for reverse lookup procedures. A DNS server configured via the same interface as more specific routes is likely more capable to answer reverse lookup questions than DNS server of an another interface. The likelyhood of success is possibly higher if DNS server address is received in the same RA [RFC5006] as the more specific route information. A.3. Longest matching prefix for reverse lookup decision A host may utilize the longest matching prefix approach when deciding which DNS server to contact for reverse lookup purposes. Namely, the host may send a DNS query to a DNS server learned over an interface Savolainen & Kato Expires March 21, 2011 [Page 15] Internet-Draft MIF and DNS server selection September 2010 having longest matching prefix to the address being queried. This approach can help in cases where ULA [RFC4193] addresses are used and when the queried address belongs to a host or server within the same network (for example intranet). Authors' Addresses Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 FINLAND Email: teemu.savolainen@nokia.com Jun-ya Kato NTT 9-11, Midori-Cho 3-Chome Musashino-Shi TOKYO, 180-8585 JAPAN Email: kato@syce.net Savolainen & Kato Expires March 21, 2011 [Page 16]