Network Working Group S. Sugimoto Internet-Draft Ericsson Expires: August 31, 2006 February 27, 2006 Using Mobile IPv6 for Home LAN Access draft-sugimoto-mip6-homelan-access-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In this document, we propose to relax forwarding rule of the Mobile IPv6 home agent. In addition to utilizing link-local scope home address, mobile node may request home agent to bypass specific link- local scope multicast traffic which may be of its interest. The extensions allow mobile node to seamlessly access the home network through link-local communication. Modifications to mobility signals for home registration are made in order to realize the extensions. This document also provides a set of requirements and guidelines for target usage scenario and implications to Mobile IPv6 system design. Sugimoto Expires August 31, 2006 [Page 1] Internet-Draft MIPv6 Home LAN Access February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 7 4.1. Home Registration . . . . . . . . . . . . . . . . . . . . 7 4.2. Virtual Home Interface . . . . . . . . . . . . . . . . . . 10 4.3. Link-local Home Address . . . . . . . . . . . . . . . . . 11 4.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 11 5. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 12 5.1. Processing Binding Update with S-bit Set . . . . . . . . . 12 5.2. Forwarding Link-Local Scope Traffic for Mobile Node . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Case Study: UPnP Network and Mobile IPv6 . . . . . . 17 A.1. Sending Service Discovery Request . . . . . . . . . . . . 17 A.2. Replying to Service Discovery Request . . . . . . . . . . 18 A.3. Sending Service Presence Announcement . . . . . . . . . . 18 A.4. Hearing Service Presence Announcement . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Sugimoto Expires August 31, 2006 [Page 2] Internet-Draft MIPv6 Home LAN Access February 2006 1. Introduction Mobile IPv6 [RFC3775] provides global mobility support for IPv6 host. The mobile node acquires session continuity and constant reachability with its permanent IP address called home address. Scope of Mobile IPv6 is by default global (SHOULD for site-local, MUST NOT for link- local). This is mainly because link-locally scoped care-of address and home address are useless in a sense that they are not reachable from global Internet. In addition, forwarding all the link-local traffic to the mobile node may generate considerably large volume of traffic and may be harmful for the mobile node who only has scarce networking resource. However, link-local communication on the home link may be of interest for the mobile node in some scenarios. In Home LAN environment, auto-configuration of IP devices (aka zero-config) is highly needed. In this respect, usability of link-local address is high because it allows configuration without network infrastructure or stateful network management mechanism (e.g. DHCPv6). There is high demand on seamless and secure remote-access to the network inside the home (Home LAN). In this draft, we propose to extend Mobile IPv6 protocol so that it can coordinate well with existing frameworks designed for Home LAN environment which has dependency on link-local communication. Sugimoto Expires August 31, 2006 [Page 3] Internet-Draft MIPv6 Home LAN Access February 2006 2. Problem Statement In Home LAN environment, link-local scope communication has significant meaning in the aspects of network configuration and service discovery. In IPv6, link-local address is a handy IP address for the node in a sense that it becomes ready right after the network interface is activated. Thanks to its handiness, link-local address is used for auto-configuration and service discovery mechanisms. However, use of link-local address is, by definition, limited within a specific link. This is problematic for applications which may frequently or continuously use link-local scope address for communication or service discovery mechanism. Such limitation makes it difficult for the users to seamlessly access his/her Home LAN from visited network. For example, it may be necessary for the user to re-configure or restart the application once he/she leaves the Home LAN and visits another network or vice versa. UPnP[UPnP.Annex-A] is a framework for connecting various digital devices over IP in plug-and-play fashion. SSDP [SSDP] is one of key components of UPnP, which is a mechanism for service discovery. SSDP depends much on multicast mechanism (in link-local scope) of IPv6 in terms of sending advertisement message to multiple receivers within a limited realm. For instance, SSDP announcement is advertised to a specific link-local scope multicast. It is expected that all UPnP devices subscribe to the multicast address and be able to receive the message. Therefore, in order for the IP devices to take advantage of SSDP, capability of link-local communication is necessary. It should be noted that providing session continuity for link-local communication is not the intention of this document, but this document rather intends to allow mobile node to enjoy services which is inherently limited inside the home network. Sugimoto Expires August 31, 2006 [Page 4] Internet-Draft MIPv6 Home LAN Access February 2006 3. Usage Model In this section, descriptions about usage model and some assumptions on network configuration are given. Today, it is common that people has broadband Internet access at his/ her home. In most cases, there is relatively small local area network built inside the home. Typically a home router is equipped with a minimum set of network components such as DHCP, NAT, and DNS etc. A home router normally serves as a gateway to the external network so that multiple IP devices could acquire network connectivity to the global Internet. In such environment, accessibility to the resource stored in IP devices that are attached to the home network is important. It is likely that users want to access the home network from visited network in secure and seamless manner. For example, user may want to listen to music on his/her laptop by streaming the music data stored in audio streaming server located at home. We assume that Mobile IPv6 home agent is installed inside Home LAN at the border between the external (global Internet) and internal network. The basic prerequisite is that the home agent has a global connectivity to the Internet either by IPv4 or IPv6. Commonly deployed scenario today would be that the home router has IPv6 global connectivity to the upstream ISP as IPv6 is not widely deployed yet. Although the home agent is installed inside the Home LAN, this does not necessarily mean that the user is required to be responsible for operation of the home agent. Management and maintenance of the home agent shall be done by the ISP with which the user has commercial contract. In particular, the IP address assignment to the egress interface of the home agent must be topologically consistent with the network configuration of the upstream ISP. When AAA mechanism is employed, AAA server must be maintained by the upstream ISP. Followings are assumptions and prerequisite of the target network scenario: o The home agent has both egress and ingress interfaces. o The home agent has global IPv4/IPv6 connectivity with its egress interface. o The home agent also serves as a security gateway for the Home LAN. It is assumed that the home agent and mobile node establish IPsec tunnel in along with IP-in-IP tunnel as specified in [RFC3776]. Sugimoto Expires August 31, 2006 [Page 5] Internet-Draft MIPv6 Home LAN Access February 2006 o The home agent has a single IP subnet on its ingress interface, which is regarded as a home network in Mobile IPv6 context. It may be possible that the IP subnet consists of multiple links which are connected across L2 switch or repeater. The home agent may be equipped with additional ingress interfaces, but they are not regarded as home network but normal IP subnets. ~~ || ______________||____ / \ / \ /------------------------\ ___________ _____ | Home I/F | ( ) ( ) +------+/ | ( )---( ISP )----|HA/SGW|--+ | ( Internet ) (_____) / /+------+ | | /( ) / / | -------+------ | / (___________) / / +------------------+ / / / Home LAN +--+/___________________________/ / |MN|_____________________________/ +--+ MIPv6 Tunnel (IP-in-IP & IPsec) In contrast to home agent, there is few technical assumptions on mobile node. The node is normal mobile node as defined in [RFC3775] except that it should provide a virtual interface which is associated with binding association with the home agent. We call the interface "virtual home interface" in the rest of this document. Sugimoto Expires August 31, 2006 [Page 6] Internet-Draft MIPv6 Home LAN Access February 2006 4. Mobile Node Operation In this section, additional procedures necessary for mobile node are described as complementary information to the default operations defined in Section 11 of [RFC3775]. 4.1. Home Registration In order for the mobile node to utilize link-local scope home address, it needs to explicitly request the home agent to extend mobility support to the link-local scope. There are two aspects of the mobility support in the link-local scope; the first is to utilize link-local home address, and the second is to remotely subscribe to given link-local multicast address. Link-local Scope Home Address (S) - The Link-local Scope Home Address bit (S-bit) in a flag of Binding Update and Binding Acknowledgment messages indicates that the mobile node requests home agent to proxy link-local scope home address. Figure 1 illustrates the Binding Update message which contains S-bit extension. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Binding Update message with S-bit. When S-bit is set in the Biding Update message, the mobile node MAY insert Alternate Interface Identifier option in the message if it wants to register an interface identifier which is different from the lower 64-bit of the global home address. If the mobile node receives Binding Acknowledgment message from the home agent with error status 134 (Duplicated Address Detection failed) in response to the Binding Update message with S-bit and Alternate Interface Identifier option, it SHOULD avoid further use of prohibited interface identifier. It is important not to confuse meaning of L-bit and S-bit. As specified in [RFC3775], L-bit is used when the mobile node requests Sugimoto Expires August 31, 2006 [Page 7] Internet-Draft MIPv6 Home LAN Access February 2006 its home agent to protect link-local address which has same interface identifier as its home address. On the other hand, S-bit is used by the mobile node to declare the interest of receiving IP traffic destined to its link-local home address. Table 1 clarifies the use of L-bit and S-bit. If S-bit is not set, operations of mobile node and home agent must fall into the normal operation of Mobile IPv6 (case A, C). When S-bit is set, treatment of link-local home address may dependent on the status of L-bit; If both L-bit and S-bit are set (case D), generation of link-local home address should be done by referring to lower 64-bit of (global scope) home address of the mobile node. When L-bit is not set (case B), lower 64-bit of link-local address should be copied from the Alternate Interface Identifier option. Table 1: Clarification on Use of L-bit and S-bit +------+-------+-------+--------------------------------------------+ | Case | L-bit | S-bit | Link-local home address | +------+-------+-------+--------------------------------------------+ | A | 0 | 0 | None. (fall into normal Mobile IPv6 | | | | | operation) | | | | | | | B | 0 | 1 | Refer to Alternate Interface Identifier | | | | | option for the lower 64-bit of the | | | | | link-local home address. | | | | | | | C | 1 | 0 | None. (fall into normal Mobile IPv6 | | | | | operation) | | | | | | | D | 1 | 1 | Refer to lower 64-bit of global scope home | | | | | address for the lower 64-bit of the | | | | | link-local home address. | +------+-------+-------+--------------------------------------------+ Figure 2 illustrates the format of Alternate Interface Identifier option. Sugimoto Expires August 31, 2006 [Page 8] Internet-Draft MIPv6 Home LAN Access February 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Interface Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Alternate Interface Identifier option Type - TBD. Length - 8-bit integer. Length of the mobility option in octets. Set to 8. Interface Identifier - Specified by the mobile node which will be used for the lower 64-bit of the link-local home address for the mobile node. Figure 3 illustrates the format of Link-local Scope Multicast Address option. The mobility option can be used by the mobile node and home agent to exchange information for specifying which link-local scope multicast address is of mobile node's interest. Mobile node MAY include Link-local Scope Multicast Address option in the Binding Update message with S-bit set. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved | Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-local Scope Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Link-local Scope Multicast Address option Type - TBD. Sugimoto Expires August 31, 2006 [Page 9] Internet-Draft MIPv6 Home LAN Access February 2006 Length - Length of the mobility option. Set to 20. Protocol - 8-bit integer. Sender MAY optionally specify protocol number to explicitly request target protocol. By default, it should be set to 0. Reserved - Sender must initialize reserved field by filling zero. Receiver must ignore the reserved field. Port Number - 16-bit integer. Sender MAY optionally specify port number of the target traffic. This value is used by the home agent to identify the target traffic. In such case, the multicast traffic destined to the address and port number specified in the Link-local Scope Multicast Address option. 4.2. Virtual Home Interface Mobile node MAY facilitate virtual network interface called "virtual home interface." Concept of virtual home interface is based on the concept of home link which is defined in [RFC3775]. In [RFC3775], mobile node is considered to be virtually connected to its home link all the time. Virtual home interface is an instance of the network interface which is always associated with the home link. IPv6 Socket API [RFC3493] gives instructions how to access network resource on the IPv6 node. It also specifies how the network interface can be distinguished to receive or send IP datagram. In this respect, there should be no exception made for the virtual home interface. That is, a unique interface index (a small positive integer) in along with literal expression of interface name (e.g. "mip0") should be assigned to a virtual home interface. Application should be able to access virtual home interface with standard Socket API. The virtual home interface is, by nature, tied to to the binding association between the mobile node and its home agent. Hence, the interface must be activated only when there is a valid home registration entry at the home agent except the case when the mobile node returns home. The virtual home interface should be remain active when the mobile node performs home de-registration when it returns home. It should be noted that the concept of virtual home interface has been occasionally discussed on the mailing list of Mobile IPv6 working group. This document provides specific usage of virtual home interface for the Home LAN environment. Specific implementation technique to realize virtual home interface Sugimoto Expires August 31, 2006 [Page 10] Internet-Draft MIPv6 Home LAN Access February 2006 is outside the scope of this document. 4.3. Link-local Home Address A link-local home address is a link-locally scoped unicast address assigned on the virtual home interface of the mobile node. Mobile node MAY request home agent to utilize link-local home address by specifying S-bit and (if necessary) Alternate Interface Identifier option in the home registration Binding Update message. In respect of source address selection, the rules specified by IPv6 scoping architecture [RFC4007] must be followed without any exception. Hence, link-local home address MUST NOT be used for communication with the nodes outside the home network. Link-local home address MUST NOT be set as an address in a Home Address Destination option. In other words, route optimization MUST NOT be performed over the link-local home address with any node. 4.4. Returning Home When the mobile node utilizes the link-local home address, it should remain usable even when the mobile node returns home. Handling of virtual home interface and link-local address is a bit tricky. As the binding association between the mobile node and home agent is dissolved when the mobile node returns home, state of virtual home interface should be updated so that link-local communication via the interface may continue to flow on the network interface which is physically attached to the home link. It is also important to note that the choice of physical network interface by the mobile node in returning home may not be deterministic. Mobile node may choose different network interface in each attempt. Therefore, a care is needed in management of virtual home interface and link-local scope home address when the mobile node returns home. How this is implemented is outside the scope of this draft. Sugimoto Expires August 31, 2006 [Page 11] Internet-Draft MIPv6 Home LAN Access February 2006 5. Home Agent Operation In this section, additional procedures necessary for home agent are described as complementary information to the default operations defined in Section 10 of [RFC3775]. 5.1. Processing Binding Update with S-bit Set When the home agent receives home registration Binding Update message with S-bit set, it should perform normal verification of the message as specified in Section 10.3.1 of [RFC3775]. If the home agent happens to create a new binding cache entry for the mobile node, it should generate a link-local address for the mobile node. Formulation of the link-local address should be done in accordance with the state of L-bit, S-bit and Alternate Interface Identifier option (see Table 1). When generation of link-local home address for the mobile node is done, the home agent must verify uniqueness of the address on the home link by performing Duplicated Address Detection. If uniqueness of the IP address is verified, the home agent sends Binding Acknowledgment message to the mobile node with successful error status (less than 128). If the DAD for claimed link-local address fails, the home agent must indicate the failure by including error status 134 in the Binding Acknowledgment message. In either case, the home agent MUST set S-bit in the Binding Acknowledgment message if it was set in the Binding Update message. If the Link-local Scope Multicast Address option is included in the Binding Update message, the home agent MUST update its local policy database according to the contents of the option. When the home agent detects that the mobile node had specified invalid link-local scope multicast address in the Binding Update message, it should sends Binding Acknowledgment indicating the violation of the local policy of the home agent. The error status code is TBD (administratively prohibited). 5.2. Forwarding Link-Local Scope Traffic for Mobile Node In this document, we propose to relax forwarding rule of the home agent in a way that traffic which is destined to or sent by link- local scope home address of the mobile node and specific link-local multicast address are bypassed to the mobile node. However, it should be noted that above rules are basically exceptions. It is very important to assure that unnecessary link- local scope traffic is never forwarded through the Mobile IPv6 tunnel. Home agent and mobile node MUST NOT inject any of following Sugimoto Expires August 31, 2006 [Page 12] Internet-Draft MIPv6 Home LAN Access February 2006 IP packets to the bi-directional tunnel: o IP packet which is sent to all-node multicast address (ff02::1) o IP packet which is sent to all-router multicast address (ff02::2) o IP packet which contains NDP messages With regard to IP packet sent from/to the link-local scope home address of the mobile node, home agent MAY forward the packet through the bi-directional tunnel between the mobile node. With regard to the IP packet sent from/to the link-local scope multicast address which was requested by the mobile node, home agent MAY tunnel the packet through the bi-directional tunnel between the mobile node. It should be noted that any other traffic sent from/to link-local scope multicast address MUST NOT be injected to the bi- directional tunnel. Sugimoto Expires August 31, 2006 [Page 13] Internet-Draft MIPv6 Home LAN Access February 2006 6. Security Considerations As this draft extends Mobile IPv6 protocol to allow home agent to forward some link-local traffic to the mobile node, security threats to the home network should be carefully considered. As specified in scoped architecture of IPv6[RFC4007], link-local IPv6 traffic is, by definition, limited within a physical link to which the network interface is attached. However, once the link-local traffic is tunneled across the IP networks, a third party node which happens to be on the path between the mobile node and home agent may have a chance to eavesdrop the tunneled data. This is a kind of off- path eavesdropping and may lead to exposing network internals of the home network to adversary. Designers of application that run on Home LAN environment might not have sufficient sense of crisis in terms of data confidentiality counting on assumption that local network is secured by other means (Layer 2 encryption etc.). As security risk for such application may be greatly increased by bypassing link-local traffic across IP networks. Therefore, data confidentiality of the tunnel is conceived necessary. IPsec ESP tunnel with non-null encryption MUST be leveraged between the mobile node and its home agent. The home agent MUST NOT accept the Binding Update message with S-bit if there is no IPsec tunnel established with the mobile node. Hence, security policy should be properly configured on the mobile node and home agent to enforce the security requirement. Sugimoto Expires August 31, 2006 [Page 14] Internet-Draft MIPv6 Home LAN Access February 2006 7. Conclusion In this draft, we specified extensions to Mobile IPv6 protocol which allows mobile node to utilize link-local scope home address. Additionally, mobile node may request home agent to bypass specific link-local scope multicast traffic over the Mobile IPv6 tunnel. These extensions allow mobile node to seamlessly access the IP devices connected to the home network where link-local communication has more significance compared to other normal network environment. Sugimoto Expires August 31, 2006 [Page 15] Internet-Draft MIPv6 Home LAN Access February 2006 8. Acknowledgments This document was greatly inspired by technical discussion with Hirokazu Naoe. Author thankfully acknowledges his contribution to this document. 9. References [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005. [SSDP] Goland, Y., Cai, T., Leach, P., Gu, Y., and S. Albright, "Simple Service Discovery Protocol/1.0 Operating without an Arbiter", draft-cai-ssdp-v1-03 (work in progress), October 1999. [UPnP.Annex-A] "UPnP Device Architecture V1.0 Annex A - IP Version 6 Support", UPnP Forum Technical Document none, September 2004. Sugimoto Expires August 31, 2006 [Page 16] Internet-Draft MIPv6 Home LAN Access February 2006 Appendix A. Case Study: UPnP Network and Mobile IPv6 If a mobile node takes part in UPnP network on Home LAN, it is desirable that the node can continuously enjoy the UPnP services provided by other IP devices regardless of its location. At the same time, the mobile node may be requested by other IP devices to provide certain service. In order to achieve such seamless (in terms of location independency) accessibility to the network resource within UPnP network, Mobile IPv6 can be applied to the Home LAN environment; miscellaneous UPnP devices are connected to the home network including the mobile node who can be "control point" or "device" in UPnP context. In UPnP, Simple Service Discovery Protocol [SSDP] is used for service discovery. SSDP runs over UDP/IP. A control point performs Service Discovery Request to locate specific service which may be available on the UPnP network. In case of IPv6, a dedicated IPv6 multicast address ff02::c is used for the service discovery query and service announcement. Link-local scope is the default scope for IPv6 operation in UPnP. A.1. Sending Service Discovery Request Figure 4 illustrates the message flow of service discovery attempted by the mobile node which is away from home. The mobile node initially performs home registration, by sending a Binding Update message with S-bit set and Link-local Multicast Address option specifying ff02::c, UDP, and 1900 in the address, protocol, and port number field, respectively. Mobile node may additionally subscribe to multicast group with different scope than link-local: subnet scope (ff03::c), administrative scope (ff04::c), and site-local scope (ff05::c), respectively. The home agent assigns link-local home address for the mobile node and updates its local policy so that requested link-local multicast traffic shall be bypassed between the mobile node and home link. When the mobile node initiates an SSDP service discovery request, it sends a request message to designated multicast address (ff02::c) and port number (1900). The Service Discovery Request message is tunneled to the home agent and will be forwarded to the home link. In this example, UPnP devices on the home link, namely Device-A and Device-B hear the Service Discovery Request message. As the Device-B has capability to provide requested service, it responds with Service Discovery Response. Note that the response should be directly sent to the requester; the destination IP address and port number are taken by source IP address and port number of the request message. Sugimoto Expires August 31, 2006 [Page 17] Internet-Draft MIPv6 Home LAN Access February 2006 Figure 4: Mobile node performs service discovery UPnP UPnP MN HA Device-A Device-B | BU(S-bit=1) | | | |------------------>| | | | BA(S-bit=1) | | | |<------------------| | | | | | | | Service Discovery Request | | |==================>|----------------->| | | |------------------------------------>| | | Service Discovery Response | |<==================|<------------------------------------| | | | | A.2. Replying to Service Discovery Request Mobile node may receive SSDP service discovery request message and make a response. In such case, the node plays a role of "device" in UPnP context registering its available services to the control point by SSDP. Once the presence of the device is registered to the control point, device is subsequently referred to by the IP address which was included in the search response message. Hence, it is essential that mobile node can facilitate link-local home address. The mobile node may happen to register its link-local home address due to some reasons (e.g. no global IP address is available at the point of time). Accordingly, the node establish a binding association with its home agent when it visits different IP subnet. In such case, registering link-local home address which is assigned on virtual home interface can persist to be reachable regardless of the mobile node's location thanks to the mobility support provided by Mobile IPv6. A.3. Sending Service Presence Announcement Mobile node may send service presence announcement in order to declare its service even from the foreign network. A.4. Hearing Service Presence Announcement Mobile node may hear service presence announcement sent by other UPnP devices on the home network. Sugimoto Expires August 31, 2006 [Page 18] Internet-Draft MIPv6 Home LAN Access February 2006 Author's Address Shinta Sugimoto Ericsson Research Japan Nippon Ericsson K.K. Koraku Mori Building 1-4-14, Koraku, Bunkyo-ku Tokyo 112-0004 Japan Phone: +81 3 3830 2241 Email: shinta.sugimoto@ericsson.com Sugimoto Expires August 31, 2006 [Page 19] Internet-Draft MIPv6 Home LAN Access February 2006 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 (2006). 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. Sugimoto Expires August 31, 2006 [Page 20]