| < draft-jeong-nemo-ro-ndproxy-01.txt | draft-jeong-nemo-ro-ndproxy-02.txt > | |||
|---|---|---|---|---|
| Individual Submission | Internet Draft | |||
| Internet Draft Jaehoon Paul Jeong | Jaehoon Paul Jeong | |||
| Kyeong-Jin Lee | Kyeongjin Lee | |||
| Jung-Soo Park | Jungsoo Park | |||
| Hyoung-Jun Kim | Hyoungjun Kim | |||
| <draft-jeong-nemo-ro-ndproxy-01.txt> ETRI | draft-jeong-nemo-ro-ndproxy-02.txt ETRI | |||
| Expires: April 2004 2 October 2003 | Expires: August 2004 14 February 2004 | |||
| ND-Proxy based Route and DNS Optimizations for | ND-Proxy based Route and DNS Optimizations for | |||
| Mobile Nodes in Mobile Network | Mobile Nodes in Mobile Network | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of Section 10 of RFC2026 except that the right to | all provisions of Section 10 of RFC2026 except that the right to | |||
| produce derivative works is not granted [1]. | produce derivative works is not granted [1]. | |||
| skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| Abstract | Abstract | |||
| This document specifies a mechanism for enabling mobile nodes in IPv6 | This document specifies a mechanism for enabling mobile nodes in IPv6 | |||
| mobile network to perform route optimization. The route optimization | mobile network to perform route and DNS optimizations. The route | |||
| is possible because mobile router relays the prefix of its Care-of | optimization is possible because mobile router relays the prefix of | |||
| address to its mobile nodes by playing the role of ND-proxy. | its care-of address to its mobile nodes by playing the role of ND- | |||
| Through binding updates associated with the network prefix of an | proxy. Through binding updates associated with the network prefix of | |||
| access network, the mobile nodes can perform route optimization. In | an access network, the mobile nodes can perform route optimization. | |||
| addition, this document explains how mobile nodes can optimize its | In addition, this document explains how mobile nodes can optimize its | |||
| DNS name resolution through RA-based DNS discovery. By announcing | DNS name resolution through RA-based DNS discovery. By announcing | |||
| the address of local recursive DNS server, mobile router allows | the address of local recursive DNS server, mobile router allows | |||
| mobile nodes to optimize their DNS name resolution. | mobile nodes using the DNS server to optimize their DNS name | |||
| resolutions without additional overhead of finding DNS server. | ||||
| Conventions used in this document | Conventions used in this document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [2]. | document are to be interpreted as described in RFC 2119 [2]. | |||
| Table of Contents | Table of Contents | |||
| 1. Terminology...................................................2 | 1. Terminology...................................................2 | |||
| 2. Introduction..................................................3 | 2. Introduction..................................................3 | |||
| 3. Overview......................................................3 | 3. Overview......................................................4 | |||
| 4. Neighbor Discovery extension..................................4 | 4. Neighbor Discovery extension..................................5 | |||
| 4.1 RO Prefix Information option format.......................4 | 4.1 RO Prefix Information option format.......................5 | |||
| 4.2 Neighbor Solicitation (NS) message format.................5 | 4.2 Neighbor Solicitation (NS) message format.................6 | |||
| 4.3 DNS Server option format..................................6 | 4.3 DNS Server option format..................................7 | |||
| 5. Mobile Router.................................................8 | 5. Mobile Router.................................................8 | |||
| 5.1 Process of RO Prefix Information option...................8 | 5.1 Process of RO Prefix Information option...................8 | |||
| 5.2 Process of DNS Server option..............................8 | 5.2 Process of DNS Server option..............................9 | |||
| 5.3 Delivery of Data Packets..................................8 | 5.3 Delivery of Data Packets..................................9 | |||
| 6. Mobile Node...................................................9 | 5.4 Movement of Mobile Router.................................9 | |||
| 6.1 Procedure of Route Optimization...........................9 | 6. Mobile Node..................................................10 | |||
| 6.1.1 Generation of a new CoA.............................9 | 6.1 Procedure of Route Optimization..........................10 | |||
| 6.1.2 DAD for the new CoA.................................9 | 6.1.1 Generation of a new CoA............................10 | |||
| 6.1.3 Return Routability and Binding Update..............10 | 6.1.2 DAD for the new CoA................................10 | |||
| 6.2 Procedure of DNS Optimization............................10 | 6.1.3 Return Routability and Binding Update..............11 | |||
| 6.2.1 RDNSS Configuration................................10 | 6.2 Procedure of DNS Optimization............................11 | |||
| 6.2.2 RDNSS Selection....................................10 | ||||
| 7. Security Considerations......................................11 | 7. Security Considerations......................................11 | |||
| 8. Copyright....................................................11 | 8. Copyright....................................................11 | |||
| 9. Normative References.........................................12 | 9. Normative References.........................................12 | |||
| 10. Informative References......................................12 | 10. Informative References......................................12 | |||
| 11. Acknowledgements............................................13 | 11. Acknowledgements............................................13 | |||
| 12. Authors' Addresses..........................................13 | 12. Authors' Addresses..........................................13 | |||
| 1. Terminology | 1. Terminology | |||
| This document uses the terminology described in [3]-[7]. Especially | This document uses the terminology described in [3]-[8]. Especially, | |||
| four important terms are as follows [5][7]: | four important terms are defined as follows [6][8]: | |||
| Multilink Subnet (MS) | Multilink Subnet (MS) | |||
| A collection of independent links, connected by routers, but | A collection of independent links, connected by routers, but | |||
| sharing a common subnet prefix. | sharing a common subnet prefix. | |||
| ND-Proxy | ND-Proxy | |||
| A router proxying and relaying for all nodes on its router-mode | A router proxying and relaying for all nodes on its router-mode | |||
| interfaces except proxy-mode interfaces among its network | interfaces except proxy-mode interfaces among its network | |||
| interfaces. | interfaces. | |||
| Multilink-Subnet Router (MSR) | Multilink-Subnet Router (MSR) | |||
| A router which has interfaces attached to different links in a | A router which has interfaces attached to different links in a | |||
| MS, and which plays the role of ND-Proxy. | MS, and which plays the role of ND-Proxy. | |||
| Recursive DNS Server (RDNSS) | Recursive DNS Server (RDNSS) | |||
| A Recursive DNS Server is a name server that offers the | A Recursive DNS Server is a name server that offers the | |||
| recursive service of DNS name resolution. | recursive service of DNS name resolution. | |||
| 2. Introduction | 2. Introduction | |||
| The basic support of mobile network (NEMO) enables mobile network | Recently, the demand and necessity of network mobility (NEMO) [3] is | |||
| nodes and correspondent nodes to communicate through bi-directional | increasing along with those of host mobility based on Mobile IPv6 | |||
| tunnels. The deeper multi-level network this NEMO gets, the longer | (MIPv6) [9]. The purpose of network mobility is to guarantee the | |||
| the delay becomes by dog-legged routing. This document specifies how | continuity of the sessions of fixed nodes or mobile nodes (MN) within | |||
| to optimize the routes between mobile nodes and correspondent nodes. | mobile networks, such as car, bus, subway train, airplane and | |||
| Also, this document provides a way to optimize DNS name resolution of | submarine. The current solution is based on bi-directional tunnel | |||
| mobile nodes, through the autoconfiguration of recursive DNS server. | between home agent (HA) and mobile router (MR) [3]. The basic | |||
| support protocol of NEMO enables mobile network node (MNN) [7] and | ||||
| correspondent node (CN) to communicate through the bi-directional | ||||
| tunnel. Data exchange between MNN and CN is performed not via | ||||
| optimal routing path, but via the non-optimal path including bi- | ||||
| directional tunnel. MR's HA intercepts all of packets destined to | ||||
| the MNNs and tunnels them to the MR. Also, the MNNs' outbound | ||||
| packets are tunneled in order to pass ingress filtering [3][9]. This | ||||
| mechanism is very simple but it gives up a powerful feature of MIPv6, | ||||
| route optimization (RO) without ingress filtering. In addition, when | ||||
| the mobile network has multiple nested MRs, packet delay between MNN | ||||
| and CN becomes longer because of dog-legged routing and also packet | ||||
| size becomes bigger due to extra IPv6 header attached to packet per | ||||
| level of nesting [10]. | ||||
| When we think over the applicability of NEMO in our daily life, we | ||||
| can forecast that network mobility service will be provided in | ||||
| vehicles, such as bus, subway train and airplane, because most | ||||
| passengers in such vehicles will have hand-held PC or PDA as MN | ||||
| rather than fixed node in near future. Therefore, it is necessary to | ||||
| provide route optimization for such MNs. This document describes a | ||||
| way of optimizing the routes between MNs and CNs, independently of | ||||
| the level of nesting and without the extra IPv6 header. The route | ||||
| optimization mechanism is based on the proxying function of MR, which | ||||
| informs MNs within mobile network of the access network prefix to | ||||
| make a care-of address (CoA) passing ingress filtering, and also | ||||
| relays packets between access router and MN. This proxying for RO is | ||||
| performed through IPv6 Neighbor Discovery (ND), which is called ND- | ||||
| Proxy. | ||||
| 3. Overview | 3. Overview | |||
| +---+ ******************* +---+ | +---+ ******************* +---+ | |||
| |CN1+---* Internet *---+CN2| | |CN1+---* Internet *---+CN2| | |||
| +---+ ******************* +---+ | +---+ ******************* +---+ | |||
| | | | | |||
| | | | | |||
| +-+-+ | +-+-+ | |||
| |AR1| | |AR1| | |||
| skipping to change at page 4, line 5 ¶ | skipping to change at page 4, line 36 ¶ | |||
| +---+ +---+ +---+ +-+-+ | RA(AR1_P) | +---+ +---+ +---+ +-+-+ | RA(AR1_P) | |||
| Router-mode| V | Router-mode| V | |||
| ---+-----+-----+--- Link4 | ---+-----+-----+--- Link4 | |||
| | | | | | | |||
| +-+-+ +-+-+ | +-+-+ +-+-+ | |||
| |MN4| |MN5| | |MN4| |MN5| | |||
| +---+ +---+ | +---+ +---+ | |||
| Figure 1. Multilink Subnet for Route Optimization | Figure 1. Multilink Subnet for Route Optimization | |||
| The route optimization is possible by mobile router's performing ND- | The route optimization is possible by MR's performing ND-Proxy, which | |||
| Proxy, which makes a Care-of Address (CoA) with the prefix advertised | makes a CoA with the prefix advertised by access router and relays | |||
| by access router and delivers the prefix of access network into the | the prefix of access network into the whole mobile network. Each MN | |||
| NEMO. Each mobile node can make its new CoA with router | can make its new CoA with router advertisement message including | |||
| advertisement message including access network prefix and perform the | access network prefix and perform the return routability and binding | |||
| return routability and binding update procedure. As ND-Proxy, the | update procedure. As ND-Proxy, the MR performs neighbor discovery | |||
| mobile router performs neighbor discovery instead of the mobile nodes | for the sake of the MNs within its mobile network. Like this, | |||
| within its NEMO. Like this, through mobile router that performs ND- | through MR that performs ND-Proxy, access network and mobile network | |||
| Proxy, access network and NEMO are configured into a multilink subnet. | are configured into a multilink subnet. Figure 1 shows an example of | |||
| Figure 1 shows an example of a multilink subnet comprised of four | a multilink subnet comprised of four links from Link1 to Link4. Two | |||
| links from Link1 to Link4. Three mobile routers from MR1 to MR3 | MRs, MR1 and MR2, receive the prefix information of access network | |||
| relay the prefix information of access network (AR1_P) that was sent | (AR1_P) that was sent by an access router, AR1 as proxy-mode and | |||
| by an access router, AR1. Let's assume that the mobile nodes MN1 and | relay it to their subnet link as router-mode [6]. Let's assume that | |||
| MN2 move into the mobile network managed by mobile router MR1 like | the MNs, MN1 and MN2, move into the mobile network managed by MR1 | |||
| Figure 1. Also, let's assume that these visiting mobile nodes | like Figure 1. Also, let's assume that these visiting mobile nodes | |||
| communicate with the correspondent nodes, CN1 and CN2, respectively. | (VMN) communicate with the correspondent nodes, CN1 and CN2, | |||
| If these visiting mobiles can get the prefix of access network and | respectively. If these visiting mobiles can get the prefix of access | |||
| make their new CoA, through the binding update with their | network and make their new CoA, through the binding update with their | |||
| correspondent node, they can communicate each other via optimized | correspondent node, they can communicate each other via an optimized | |||
| path. This dissemination of access network's prefix is performed by | path. This dissemination of access network's prefix is performed by | |||
| mobile router which becomes attached to a foreign access network, not | MR which becomes attached to a foreign access network, not its home | |||
| its home network. Likewise, MN3 can optimize the route through MR2. | network. Likewise, MN3 can optimize the route through MR2. MN4 and | |||
| MN4 and MN5 can perform route optimization through MR2 and MR3, too. | MN5 can perform route optimization through MR2 and MR3, too. | |||
| The optimization of DNS name resolution is possible by mobile | The optimization of DNS name resolution is possible by MR's | |||
| router's announcing the address of local recursive DNS server as well | announcing the address of local recursive DNS server as well as the | |||
| as the prefix information of access network. In Figure 1, by DNS | prefix information of access network. In Figure 1, by DNS Server | |||
| Server option included in RA message, MR1 announces the address of | option included in RA message, MR1 announces the address of Recursive | |||
| Recursive DNS Server, RDNSS1, within its mobile network to its | DNS Server, RDNSS1, within its mobile network to its router-mode link, | |||
| router-mode link, Link2. Therefore, mobile nodes within Link2, MN1 | Link2. Therefore, MNs within Link2, MN1 and MN2, can optimize their | |||
| and MN2, can optimize their DNS name resolution by using local DNS | DNS name resolution by using local DNS server, RDNSS1. | |||
| server, RDNSS1. | ||||
| 4. Neighbor Discovery extension | 4. Neighbor Discovery extension | |||
| In order to support the route optimization, ND implementation in MR | ||||
| and MN must be extended to process the prefix information option for | ||||
| RO and that in Local Fixed Node (LFN) within mobile network, which | ||||
| has no mechanism for MIPv6, need no change. | ||||
| 4.1 RO Prefix Information option format | 4.1 RO Prefix Information option format | |||
| The mechanism of this document needs the addition of a new flag | The mechanism of this document needs a new O (Route-optimization) | |||
| within prefix information option for route optimization [3]. When | flag within prefix information option for route optimization [4]. | |||
| this flag is set, it indicates that the prefix included in the option | When this flag is set on, it indicates that the prefix included in | |||
| can be used by mobile nodes within a NEMO for the route optimization. | the option can be used by MNs within a mobile network for route | |||
| Figure 2 shows the format of the modified prefix information option, | optimization. Figure 2 shows the format of the modified prefix | |||
| RO Prefix Information option, which is included in RA message. | information option, RO Prefix Information option, which is included | |||
| in RA message. | ||||
| 0 1 2 3 | 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 | 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 | Prefix Length |L|A|O|Reserved1| | | Type | Length | Prefix Length |L|A|O|Reserved1| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Valid Lifetime | | | Valid Lifetime | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Preferred Lifetime | | | Preferred Lifetime | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 5, line 31 ¶ | skipping to change at page 6, line 15 ¶ | |||
| + + | + + | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 2. Prefix Information Option Format for Route Optimization | Figure 2. Prefix Information Option Format for Route Optimization | |||
| Field: | Field: | |||
| O 1-bit route-optimization flag. When set indicates | O 1-bit route-optimization flag. When set indicates | |||
| that this prefix can be used for the route | that this prefix can be used for the route | |||
| optimization of mobile nodes within NEMO. | optimization of MNs within a mobile network. | |||
| The RO Prefix Information option provides a mobile node with the | The RO Prefix Information option provides an MN with the network | |||
| network prefix of access network and allows it to autoconfigure its | prefix of access network and allows it to autoconfigure its new CoA | |||
| new CoA through stateless address autoconfiguration and to perform | through stateless address autoconfiguration and to perform binding | |||
| binding update. The Prefix Information option appears in RA message | update. The Prefix Information option appears in RA message and MUST | |||
| and MUST be silently ignored for other messages. L (On-link) flag | be silently ignored for other messages. L (On-link) flag MAY be | |||
| MAY be either 0 or 1. Namely, this route optimization can be either | either 0 or 1. Namely, this route optimization can be either on-link | |||
| on-link or off-link model [5]. A (Autonomous address-configuration) | or off-link model [6]. A (Autonomous address-configuration) flag | |||
| flag MUST be 1, indicating IPv6 stateless address autoconfiguration. | MUST be set on, indicating IPv6 stateless address autoconfiguration. | |||
| 4.2 Neighbor Solicitation (NS) message format | 4.2 Neighbor Solicitation (NS) message format | |||
| NS message MUST be extended for Duplicate Address Detection (DAD) for | NS message MUST be extended for Duplicate Address Detection (DAD) for | |||
| the address based on RO prefix of access network. Therefore, there | the address based on RO prefix to be performed in the whole mobile | |||
| is a need to discriminate between the normal NS message and extended | network, not just within a link. Therefore, there is a need to | |||
| NS message for route optimization [3]. Figure 3 shows the format of | discriminate between the normal NS message and extended NS message | |||
| the modified NS message. | for route optimization [4]. Figure 3 shows the format of the | |||
| modified NS message. | ||||
| 0 1 2 3 | 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 | 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 | Code | Checksum | | | Type | Code | Checksum | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |M| Reserved | | |M| Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| + + | + + | |||
| skipping to change at page 6, line 22 ¶ | skipping to change at page 7, line 4 ¶ | |||
| | | | | | | |||
| + + | + + | |||
| | | | | | | |||
| + Target IPv6 Address + | + Target IPv6 Address + | |||
| | | | | | | |||
| + + | + + | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Options ... | | Options ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+- | |||
| Figure 3. Extended Neighbor Solicitation Message Format | Figure 3. Extended Neighbor Solicitation Message Format | |||
| Fields: | Fields: | |||
| M 1-bit multi-hop flag. When set indicates | M 1-bit multi-hop flag. When set indicates | |||
| that this NS message SHOULD be relayed to the other | that this NS message SHOULD be relayed to the other | |||
| links of multilink subnet. | links of a multilink subnet. | |||
| Target IPv6 Address | Target IPv6 Address | |||
| The IPv6 address of the target of the solicitation | The IPv6 address of the target of the solicitation, | |||
| that will be used as CoA. It MUST NOT be a | e.g., CoA. It MUST NOT be a multicast address. | |||
| multicast address. | ||||
| 4.3 DNS Server option format | 4.3 DNS Server option format | |||
| DNS Server option contains the IPv6 address of the recursive DNS | DNS Server option contains the IPv6 address of the recursive DNS | |||
| server. When more than one DNS Server option are advertised, as many | server. When advertising more than one DNS Server option, an RA | |||
| DNS Server options as DNS servers are included in an RA message. | message includes as many DNS Server options as DNS servers. Figure 4 | |||
| Figure 4 shows the format of DNS Server option [7]. | shows the format of DNS Server option [8]. | |||
| 0 1 2 3 | 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 | 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 | Pref | Reserved | | | Type | Length | Pref | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Valid Lifetime | | | Lifetime | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| + + | + + | |||
| | | | | | | |||
| + IPv6 Address of DNS Server + | + IPv6 Address of DNS Server + | |||
| | | | | | | |||
| + + | + + | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 7, line 25 ¶ | skipping to change at page 8, line 7 ¶ | |||
| Fields: | Fields: | |||
| Type 8-bit identifier of the option type (TBD: IANA) | Type 8-bit identifier of the option type (TBD: IANA) | |||
| Option Name Type | Option Name Type | |||
| DNS Server (TBD) | DNS Server (TBD) | |||
| Length 8-bit unsigned integer. The length of the | Length 8-bit unsigned integer. The length of the | |||
| option (including the type and length fields) | option (including the type and length fields) | |||
| in units of 8 octets. The value 0 is invalid. | in units of 8 octets SHOULD be 0x03 (3 x 8 = 24 | |||
| Mobile nodes MUST silently discard a Neighbor | octets). | |||
| Discovery (ND) packet that contains an option | ||||
| with length zero. | ||||
| Pref The preference of a DNS server. A 4-bit unsigned | Pref The preference of a DNS server. A 4-bit unsigned | |||
| integer. A decimal value of 15 indicates the | integer. A decimal value of 15 indicates the | |||
| highest preference. A decimal value of 0 | highest preference. A decimal value of zero | |||
| indicates that the DNS server can not be used. | means unspecified. The field can be used for | |||
| The field can be used for selecting an RDNSS | load balancing of DNS queries with multiple | |||
| among multiple RDNSSes. | RDNSSes according to local policy. | |||
| Valid Lifetime 32-bit unsigned integer. The maximum time, in | Lifetime 32-bit unsigned integer. The maximum time, in | |||
| seconds, over which this DNS server is used for | seconds, over which this DNS server is used for | |||
| name resolution. Mobile nodes should contact the | name resolution. MNs should contact the | |||
| source of this information, mobile router, before | source of this information, MR, before | |||
| expiry of this time interval. A value of all one | expiry of this time interval. A value of all one | |||
| bits (0xffffffff) represents infinity. | bits (0xffffffff) represents infinity. A value | |||
| of zero means that the DNS server must not be | ||||
| used any more. | ||||
| IPv6 Address of DNS Server | IPv6 Address of DNS Server | |||
| Recursive DNS Server's address for DNS name | Recursive DNS Server's address for DNS name | |||
| resolution. | resolution. | |||
| "Pref"=0 SHOULD require a "Valid Lifetime"=0 because the | ||||
| corresponding DNS server SHOULD not be used any more. | ||||
| 5. Mobile Router | 5. Mobile Router | |||
| Mobile router MUST process Prefix Information option for Route | MR MUST process Prefix Information option for Route Optimization and | |||
| Optimization (RO) and DNS Server option for DNS Optimization, which | DNS Server option for DNS Optimization, which may be included in RA | |||
| are included in RA message. | message. | |||
| 5.1 Process of RO Prefix Information option | 5.1 Process of RO Prefix Information option | |||
| Only if the prefix announced by an access router is different from | Only if the prefix announced by an access router is different from | |||
| the prefix of a mobile router's Home Address (HoA), the mobile router | the prefix of an MR's Home Address (HoA), the MR MUST perform the | |||
| MUST perform the role of ND-Proxy and relay the prefix information. | role of ND-Proxy and relay the prefix information. Before MR | |||
| Before mobile router advertises the prefix information through Router | advertises the prefix information through Router Advertisement (RA) | |||
| Advertisement (RA) message, it MUST set route-optimization flag | message, it MUST set O flag indicating that this prefix can be used | |||
| indicating that this prefix can be used for route optimization of | for route optimization of MNs, which are either local mobile nodes | |||
| mobile nodes, which are either local mobile nodes or visiting mobile | (LMN) or VMNs within the mobile network. | |||
| nodes within the mobile network. | ||||
| If a mobile node within a mobile network receives the new prefix | If an MN within a mobile network receives the new prefix information | |||
| information option through RA message and can recognize this option, | option through RA message and can recognize this option, it MAY | |||
| it MAY prefer this new prefix information option to the normal prefix | prefer RO prefix information option to normal prefix information | |||
| information option that contains the mobile network prefix assigned | option that contains the mobile network prefix assigned by the MR's | |||
| by the mobile router's home network. By performing binding update | home network. By performing binding update with the prefix of the | |||
| with the prefix of the access network, the mobile node can optimize | access network, the MN can optimize the routes between its | |||
| the routes between its correspondent nodes and itself. | correspondent nodes and itself. | |||
| ND-Proxy MUST join the solicited-node multicast address(es) that | ND-Proxy MUST join the solicited-node multicast addresses that | |||
| correspond to the IP address(es) assigned to the mobile node for | correspond to the IPv6 addresses assigned to MNs for which it is | |||
| which it is proxying [3]. | proxying for processing ND messages related to the MNs [4]. | |||
| 5.2 Process of DNS Server option | 5.2 Process of DNS Server option | |||
| If mobile router has its own local RDNSS like MR1 and MR2 in Figure 1, | If MR has its own local RDNSS like MR1 and MR2 in Figure 1, it SHOULD | |||
| it SHOULD announce the address of RDNSS to its router-mode link(s). | announce the address of RDNSS to its router-mode link(s). | |||
| If mobile router receives DNS Server option from its proxy-mode | If MR receives DNS Server option from its proxy-mode link(s), it | |||
| link(s), it SHOULD relay the option to its router-mode link(s) | SHOULD relay the option to its router-mode link(s) through its RA | |||
| through its RA message. In case that mobile router has its own local | message. In the case where MR has its own local RDNSS, it announces | |||
| RDNSS, it announces the DNS Server option of its RDNSS with higher | the DNS Server option of its RDNSS with higher precedence than those | |||
| precedence than those of other RDNSSes. | of other RDNSSes. | |||
| 5.3 Delivery of Data Packets | 5.3 Delivery of Data Packets | |||
| After a mobile node gets a new CoA within a mobile network and | After an MN gets a new CoA within a mobile network and performs | |||
| performs binding update associated with the address, the data packets | binding update associated with the address, the data packets of | |||
| of correspondent node toward the mobile node are delivered to the | correspondent node toward the MN can be delivered to the access | |||
| access network to which the NEMO containing the mobile node is | network to which the mobile network containing the MN is attached, | |||
| attached, via optimal path between the mobile and correspondent nodes. | via optimal path between the mobile and correspondent nodes. | |||
| When the access router of the access network receives the data | When the access router of the access network receives the data | |||
| packets, it multicasts normal Neighbor Solicitation (NS) message to | packets toward an MN and there is no neighbor information for the MN, | |||
| the solicited-node multicast address of the destination IPv6 address | it multicasts normal Neighbor Solicitation (NS) message to the | |||
| in order to find out the link-layer address of the destination mobile | solicited-node multicast address of the destination IPv6 address in | |||
| node. The mobile router, knowing the link-layer address of the | order to find out the link-layer address of the destination MN. The | |||
| target, responds to the NS message by returning its own link-layer | MR, knowing the link-layer address of the target, responds to the NS | |||
| address in a unicast Neighbor Advertisement (NA) message as ND-Proxy, | message by returning its own link-layer address in a unicast Neighbor | |||
| which knows the IPv6 addresses and link-layer addresses of mobile | Advertisement (NA) message as ND-Proxy, which knows the IPv6 | |||
| nodes within its mobile network during the DAD of each CoA of each | addresses and link-layer addresses of MNs within its mobile network | |||
| mobile node. | while forwarding their data packets along with neighbor discovery | |||
| related to each destination node. | ||||
| When the access router knows the link-layer address to the | When the access router knows the link-layer address of next-hop | |||
| destination, it forwards the IPv6 data packets to the mobile router | toward the destination MN, it forwards the IPv6 data packets to the | |||
| corresponding to the link-layer address. The mobile router relays | MR corresponding to the link-layer address. The packets are relayed | |||
| the packets to the destination mobile node. In case that the NEMO | to next-hop toward the destination node by MR until the packets | |||
| where the destination node is placed is multi-level, the packets are | arrive at the destination. Like this, in the case where the mobile | |||
| relayed to the destination node by more than one mobile router. | network where the destination node is placed is multi-level, the | |||
| packets may be relayed to the destination node by more than one MR | ||||
| according to the route information in each MR's destination and | ||||
| neighbor caches. | ||||
| 5.4 Movement of Mobile Router | ||||
| When an MR moves into another access network and detects its movement | ||||
| by movement detection algorithm [9], it performs binding update with | ||||
| its HA with a new CoA based on the new access network prefix, and | ||||
| then relays the prefix for RO into its other router-mode interfaces. | ||||
| This allows the MRs and nodes to perform route optimization based on | ||||
| the new access network prefix. When the MR returns to its home | ||||
| network, it deregisters with its HA and advertises RA message that | ||||
| contains RO Prefix Information option for the previous access network | ||||
| prefix with Valid Lifetime and Preferred Lifetime set to zeroes and O | ||||
| flag set on, and also Prefix Information option for MR's mobile | ||||
| network prefix. The RO Prefix Information option SHOULD be | ||||
| advertised at least three times. This RA message allows the MRs and | ||||
| MNs below the MR explicitly to release their current CoA and to use | ||||
| the MR's mobile network prefix in order to configure their addresses | ||||
| according to MIPv6 protocol [9]. | ||||
| 6. Mobile Node | 6. Mobile Node | |||
| Mobile node MUST process Prefix Information option for Route | MN MUST process Prefix Information option for RO and DNS Server | |||
| Optimization (RO) and DNS Server option for DNS Optimization, which | option for DNS Optimization, which are included in RA message. | |||
| are included in RA message. | ||||
| 6.1 Procedure of Route Optimization | 6.1 Procedure of Route Optimization | |||
| For route optimization, mobile node generates a new CoA based on the | For RO, MN generates a new CoA based on the access network prefix and | |||
| access network prefix and performs binding update for the CoA. | performs binding update for the CoA. | |||
| 6.1.1 Generation of a new CoA | 6.1.1 Generation of a new CoA | |||
| Whenever a mobile node receives RA message containing RO prefix | Whenever an MN receives RA message containing RO prefix information | |||
| information option that includes a new network prefix of access | option that includes a new network prefix of access network, it makes | |||
| network, it makes a new CoA. | a new CoA. | |||
| 6.1.2 DAD for the new CoA | 6.1.2 DAD for the new CoA | |||
| The mobile node performs DAD for the new CoA through the extended NS | The MN performs DAD for the new CoA through the extended NS message. | |||
| message. The NS message of DAD for the new address is relayed to the | The NS message of DAD for the new address is disseminated by MRs, | |||
| other links by a mobile router, acting as ND-Proxy, on the link where | acting as ND-Proxy, in the entire mobile network where the MN is | |||
| the mobile node is placed [5]. The mobile router memorizes the DAD | placed [6]. Each MR memorizes the DAD for returning NA message to | |||
| for returning NA message to the sender of the extended NS message. | the originator or relayer of the extended NS message for a while. | |||
| If there is no NA returned and the DAD is successful, the mobile node | If there is no NA returned after DAD timeout, the MN configures the | |||
| configures the verified address as its new CoA in its network | address as its new CoA in its network interface. | |||
| interface. | ||||
| Notice that the DAD for the link-local addresses and global addresses | Therefore, the DAD for the link-local addresses and global addresses | |||
| based on mobile network prefix assigned by home network is performed | based on mobile network prefix assigned by home network is performed | |||
| through normal NS message only within a link and the DAD for the | through normal NS message only within a link and the DAD for the | |||
| global addresses based on access network prefix is performed through | global addresses based on access network prefix is performed through | |||
| extended NS message within a multilink subnet, which is relayed by | extended NS message within a multilink subnet, which is relayed by | |||
| ND-Proxies. | ND-Proxies. | |||
| 6.1.3 Return Routability and Binding Update | 6.1.3 Return Routability and Binding Update | |||
| After configuring the new CoA, the mobile node performs the return | After configuring the new CoA, the MN performs the return routability | |||
| routability and binding update procedure of Mobile IPv6 [8]. If the | and binding update procedure of MIPv6 [9]. If the MN is VMN for the | |||
| mobile node is visiting mobile node (VMN) for the mobile network | mobile network where it is present, or as LMN, moves into another | |||
| where it is present, or as local mobile node (LMN), moves into | link of the mobile network to which its home link belongs, it SHOULD | |||
| another link of the mobile network to which its home link belongs to, | perform binding updates with both its HA and CNs. | |||
| it SHOULD perform binding updates with both its home agent and | ||||
| correspondent nodes. In case that as LMN, the mobile node is present | ||||
| at home link and receives RO prefix information option, namely when | ||||
| the mobile node's HoA and CoA belong to the same link, it SHOULD | ||||
| perform not deregistration with its home agent which is its mobile | ||||
| router simultaneously, but binding updates with both its home agent | ||||
| and correspondent nodes. | ||||
| 6.2 Procedure of DNS Optimization | 6.2 Procedure of DNS Optimization | |||
| The optimization of DNS name resolution is possible by mobile | The optimization of DNS name resolution is possible by MR's | |||
| router's announcing the address of local recursive DNS server as well | announcing the address of local RDNSS along with RO prefix | |||
| as RO prefix information through RA message [7]. The DNS server can | information through RA message like in Section 5.2 [8]. The DNS | |||
| exist either within mobile network or within access network. The | server can exist either within mobile network or within access | |||
| address of recursive DNS server is delivered to mobile nodes through | network. The address of RDNSS is delivered to MNs through DNS Server | |||
| DNS Server option, one of RA options. Especially, visiting mobile | option, one of RA options. Especially, VMNs can optimize their DNS | |||
| nodes will optimize their DNS name resolution effectively by using | name resolutions effectively by using a local RDNSS. | |||
| local recursive DNS server. | ||||
| 6.2.1 RDNSS Configuration | ||||
| The addresses of DNS servers are announced by DNS Server options in | ||||
| RA message. These addresses can be used for recursive DNS service | ||||
| providing DNS name resolution. If mobile node receives DNS Server | ||||
| option, it SHOULD store RDNSS's address in the configuration file for | ||||
| its DNS resolver; i.e., /etc/resolv.conf in UNIX. | ||||
| 6.2.2 RDNSS Selection | ||||
| When mobile node perceives multiple RDNSSes through RA message, it | ||||
| stores the RDNSS addresses in order into the configuration file which | ||||
| its DNS resolver uses for DNS name resolution on the basis of the | ||||
| value of "Pref" field in the DNS Server option. The following | ||||
| algorithm is simply based on the rule of selecting an RDNSS in the | ||||
| order from the most preferred RDNSS, provided that its preference | ||||
| value is not zero. The processing of the DNS Server option received | ||||
| in RA message by a mobile node is as follows: | ||||
| For each DNS Server option: | ||||
| Step (a) : Receive and parse all DNS Server options. | ||||
| Step (b) : Arrange the addresses of RDNSSes in a descending order, in | ||||
| the respect of preference value, namely starting with the | ||||
| biggest value of "Pref" field of the DNS Server option and | ||||
| store them in the configuration file used by resolver for | ||||
| DNS name Resolution (DNS configuration). | ||||
| Step (c) : For each DNS Server option, check the following: If the | ||||
| Value of "Pref" or "Valid Lifetime" field is set to zero, | ||||
| exclude the corresponding RDNSS entry from the list of | ||||
| RDNSSes of DNS configuration in order to let the RDNSS not | ||||
| used any more. | ||||
| Whenever the DNS resolver on the mobile node performs the name | ||||
| resolution, it refers to the address of RDNSS in order from the first | ||||
| RDNSS stored in its DNS configuration. Like this, in case that there | ||||
| are several mobile routers advertising RDNSS in a multilink subnet, | ||||
| "Pref" field is used to select RDNSS. | ||||
| 7. Security Considerations | 7. Security Considerations | |||
| The route optimization and DNS optimization in this document does not | The route optimization and DNS optimization in this document does not | |||
| add any other security problems to the NEMO, Mobile IPv6, or Neighbor | add any other security problems to the NEMO, MIPv6, or ND protocol. | |||
| Discovery (ND) protocols. Security issues regarding the ND protocol | Security issues regarding the ND protocol are being discussed in IETF | |||
| are being discussed in IETF SEND (Securing Neighbor Discovery) | SEND (Securing Neighbor Discovery) working group [11]. | |||
| working group [9]. | ||||
| 8. Copyright | 8. Copyright | |||
| The following copyright notice is copied from RFC 2026 [Bradner, | The following copyright notice is copied from RFC 2026 [Bradner, | |||
| 1996], Section 10.4, and describes the applicable copyright for this | 1996], Section 10.4, and describes the applicable copyright for this | |||
| document. | document. | |||
| Copyright (C) The Internet Society July 12, 2001. All Rights | Copyright (C) The Internet Society July 12, 2001. All Rights | |||
| Reserved. | Reserved. | |||
| skipping to change at page 12, line 31 ¶ | skipping to change at page 12, line 25 ¶ | |||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| 9. Normative References | 9. Normative References | |||
| [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP | [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP | |||
| 9, RFC 2026, October 1996. | 9, RFC 2026, October 1996. | |||
| [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
| Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
| [3] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for | [3] Vijay Devarapalli et al., "Nemo Basic Support Protocol", draft- | |||
| ietf-nemo-basic-support-02.txt, December 2003. | ||||
| [4] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for | ||||
| IP version 6", RFC 2461, December 1998. | IP version 6", RFC 2461, December 1998. | |||
| [4] S. Thomson and T. Narten, "IPv6 Stateless Address | [5] S. Thomson and T. Narten, "IPv6 Stateless Address | |||
| Autoconfiguration", RFC 2462, December 1998. | Autoconfiguration", RFC 2462, December 1998. | |||
| [5] Dave Thaler and Chistian Huitema, "Multi-link Subnet Support in | [6] Dave Thaler and Chistian Huitema, "Multi-link Subnet Support in | |||
| IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, June 2002. | IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, June 2002. | |||
| [6] Thierry Ernst, "Network Mobility Support Terminology", draft- | [7] T. Ernst and H.-Y. Lach, "Network Mobility Support Terminology", | |||
| ietf-nemo-terminology-00.txt, May 2003. | draft-ietf-nemo-terminology-00.txt, May 2003. | |||
| [7] Jaehoon Jeong, Soohong D. Park, Luc Beloeil and Syam Madanapalli, | [8] Jaehoon Paul Jeong et al., "IPv6 DNS Discovery based on Router | |||
| "IPv6 DNS Discovery based on Router Advertisement", draft-jeong- | Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-01.txt, | |||
| dnsop-ipv6-dns-discovery-00.txt, July 2003. | February 2004. | |||
| 10. Informative References | 10. Informative References | |||
| [8] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", | [9] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", | |||
| draft-ietf-mobileip-ipv6-22.txt, May 2003. | draft-ietf-mobileip-ipv6-24.txt, June 2003. | |||
| [9] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, | [10] Pascal Thubert and Marco Molteni, "IPv6 Reverse Routing Header | |||
| "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt, | and its application to Mobile Networks", draft-thubert-nemo- | |||
| June 2003. | reverse-routing-header-03.txt, October 2003. | |||
| [11] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-ietf- | ||||
| send-ndopt-03.txt, January 2004. | ||||
| 11. Acknowledgements | 11. Acknowledgements | |||
| The authors would like to acknowledge the previous contribution of | The authors would like to acknowledge the previous contribution of | |||
| Dave Thaler and Christian Huitema. | Dave Thaler and Christian Huitema for ND-Proxy. | |||
| 12. Authors' Addresses | 12. Authors' Addresses | |||
| Jaehoon Paul Jeong | Jaehoon Paul Jeong | |||
| ETRI / PEC | ETRI / PEC | |||
| 161 Gajong-Dong, Yusong-Gu | 161 Gajeong-dong, Yuseong-gu | |||
| Daejon 305-350 | Daejon 305-350 | |||
| Korea | Korea | |||
| Phone: +82 42 860 1664 | Phone: +82 42 860 1664 | |||
| EMail: paul@etri.re.kr | EMail: paul@etri.re.kr | |||
| Kyeong-Jin Lee | Kyeongjin Lee | |||
| ETRI / PEC | ETRI / PEC | |||
| 161 Gajong-Dong, Yusong-Gu | 161 Gajeong-dong, Yuseong-gu | |||
| Daejon 305-350 | Daejon 305-350 | |||
| Korea | Korea | |||
| Phone: +82 42 860 6484 | Phone: +82 42 860 6484 | |||
| EMail: leekj@etri.re.kr | EMail: leekj@etri.re.kr | |||
| Jung-Soo Park | Jungsoo Park | |||
| ETRI / PEC | ETRI / PEC | |||
| 161 Gajong-Dong, Yusong-Gu | 161 Gajeong-dong, Yuseong-gu | |||
| Daejon 305-350 | Daejon 305-350 | |||
| Korea | Korea | |||
| Phone: +82 42 860 6514 | Phone: +82 42 860 6514 | |||
| EMail: pjs@etri.re.kr | EMail: pjs@etri.re.kr | |||
| Hyoung-Jun Kim | Hyoungjun Kim | |||
| ETRI / PEC | ETRI / PEC | |||
| 161 Gajong-Dong, Yusong-Gu | 161 Gajeong-dong, Yuseong-gu | |||
| Daejon 305-350 | Daejon 305-350 | |||
| Korea | Korea | |||
| Phone: +82 42 860 6576 | Phone: +82 42 860 6576 | |||
| EMail: khj@etri.re.kr | EMail: khj@etri.re.kr | |||
| End of changes. 64 change blocks. | ||||
| 261 lines changed or deleted | 269 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||