NGTRANS WG Philippe Bereski Gilles Diribarne Damien Galand Alcatel Internet Draft Title:draft-bereski-ngtrans-nd-dstm-00.txt Expires : April 2002 November 2001 Dual Stack deployment using DSTM and neighbour discovery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Today IPv6 nodes are generally dual stacked. With its automatic configuration of tunnel end points, [DSTM] is an appealing transition mechanism, provided that an efficient dynamic allocation of IPv4 address process is available. The aim of this document is to show how a border gateway using extensions to neighbour discovery [ND] can manage this allocation process. Index 1. Introduction 1.1 Scope of the document 2. Using neighbour discovery for DSTM 2.1 Communication initiated by a Dual Stack Host 2.2 Communication initiated by a IPv4 only Host 2.3 Tunneling of new ND messages 3. Format of new ND messages 3.1 RS for IPv4 address solicitation 3.2 RA for IPv4 address allocation 4. Security issues 5. Conclusion 6. References 1. Introduction Today IPv6 nodes are generally dual stacked. With its automatic configuration of tunnel end points (TEP), [DSTM] is an appealing transition mechanism provided that an efficient dynamic allocation of IPv4 address is available. The aim of this document is to show how a border gateway using extensions to neighbour discovery can manage this allocation process. This document proposes 2 adaptations for ICMPv6 RA/RS messages. 1.1 Scope of the document This document does not aim at redefining DSTM itself. It only aims at defining a process based on ICMPv6 messages to manage the temporary allocation of IPv4 address to a dual stack host. 2. Using neighbour discovery for DSTM DSTM defines that if IPv4 routing is not supported in the DSTM domain, IPv4 is tunnelled over IPv6 from the Dual Stack Host (DSH) to the TEP which de-encapsulates and then forwards packets over IPv4 external network. A DSTM server is responsible for managing the TEPs and maintaining a pool of IPv4 addresses. The TEP is generally the Y6/Y4 border gateway, and this gateway must keep track of the association of the IPv6 and IPv4 addresses. So, it makes sense to consider that the border gateway itself is the DSTM server. There is a need for a dialog between the Dual Stack Node and the border router gateway, similarly to the dialog in the neighbour discovery process. Handling a pool of addresses is a function that is already accepted for mechanisms as NAT-PT. This section shows this dialog when the communication is initiated by a Dual Stack Node or by a IPv4 only node. In the examples below, the following notation, borrowed from [DSTM] will be used: X will designate an IPv6 host with a dual stack, X6 will be the IPv6 address of this host and X4 the IPv4 address Y will designate a DSTM border router at the boundary between an IPv6 DSTM domain and an IPv4-only domain. Z will designate an IPv4-only host and Z4 its address. ==> means an IPv6 packet --> means an IPv4 packet ++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet +=> means a tunneled IPv6 packet is encapsulated in an IPv6 packet ..> means a DNS query or response. The path taken by this packet does not matter in the examples "a" means the DNS name of a host 2.1 Communication initiated by a Dual Stack Node DNS X6 Y6/Y4 Z4 | | | |. . . . . . . .> Z | - X6 asks the DNS for an AAAA for "Z" |<. . . . . . . error | - the DNS answers with an error |. . . . . . . .> Z | - X6 asks for the A RR for "Z" |<. . . . . . . . Z4 | - the answer is Z4 | | | - The application sends its first IPv4 | | | packet which arrives to the Dynamic | | | Tunneling Interface (DTI). | | | - X6 needs an IPv4 address (first use) |+=+=+=+=+>| | - X6 queries the Y6/Y4 router server for an | | | IPv4 address using RS request. |<+=+=+=+=+| | - The Y6/Y4 router provides a temporary | | | IPv4 address with a RA answer to | | | the6 node and cache the association. | <=====| | - The Y6/Y4 router sends dynamic update to | | | DNS with the temporary IPv4 address of X6 | | | for further IPv4 initiated communications |+++++++++>| | - The DTI sends the IPv6 packet to the TEP. | |--------->| - Y de-encapsulates the IPv4 packet from the | | | IPv6 packet then sends the IPv4 packet to | | | the destination Z4. As specified in [ND] RA/RS packets have a local link scope. To overpass this, packets exchanged between the Y6/Y4 router and the Dual Stack Host are encapsulated in IPv6 unicast packets. When Z responds, the IPv4 packet returns back through Y. Y, having cached the association between the IPv4 and the IPv6 address of X, is able to send the IPv4 packet back to X, encapsulating it in IPv6. 2.2 Communication initiated by a IPv4 only node DNS X6 Y6/Y4 Z4 | | | | < . . . . . . . | - Z4 asks the DNS for an A RR for "X" | +=+=+>| | - the DNS only finds a IPv6 address. It | | | proxies for X6 by sending the RS request | | | that X6 makes in the case of communication | | | described in 2.1. |<+=+=+=+=+| | - Y6/Y4 router allocates a temporary IPv4 | | | address, sends it with a RA to the | | | X6 node and caches the association. | <+=+=+| | - Y6/Y4 router sends a dynamic update to | | | DNS with X6 IPv4 temporary address. | . . . . . . . . > | - DNS answers the A RR to Z4 | |<---------| - Z4 can now send its packets to X6 through | | | Y6/Y4 router that's ready to encapsulate | | | them. |<+++++++++| | - Y6/Y4 router encapsulates IPv4 packets | | | into IPv6 for delivery to X6. |+++++++++>| | - When Y6 answers Z4, its DTI sends the | | | IPv6 packets to the TEP. | |--------->| - Y de-encapsulate the IPv4 packet from the | | | IPv6 packet then sends the IPv4 packet to | | | the destination Z4. Because DNS just proxies to Y6/Y4 router a request for a temporary IPv4 address as issued by X6, the case of communication initiated by a IPv4 only nodes is managed in exactly the same way it is when initiated by a Dual Stack Node. 2.3 Tunneling of ND messages As specified in [ND] RA/RS ICMP packets have a local link scope. To overpass this, packets exchanged between Y6/Y4 router and the Dual Stack Host are encapsulated in IPv6 unicast packets. X6 Y6/Y4 | | |+=+=+=+=+>| - RS packet encapsulated in IPv6 unicast packet. | | IPv6 unicast packet fields: | | Sender address: The IPv6 unicast address of | | the interface of X6 that can be routed to Y6/Y4. | | Destination address: The IPv6 unicast | | address of Y6/Y4 that can be routed from X6. | | Payload: The RS packet. (See chapter 3.1 for its | | detailed format). | | |<+=+=+=+=+| - RA packet encapsulated in IPv6 unicast packet. | | IPv6 unicast packet fields: | | Sender address: The IPv6 unicast address | | of Y6/Y4 that can be routed to X6. | | Destination address: The IPv6 unicast address | | interface of X6 that can be routed from Y6/Y4. | | Payload: The RA packet. (See chapter 3.2 for its | | detailed format). 3. Format of new ND messages 3.1 RS for IPv4 address solicitation [ borrowed from RFC 2461] The present draft specifies a new option called "DSH mapping request". 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 | Reserved MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DSH IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The IPv6 address of the interface of the X6 node Destination Address Typically the all-routers multicast address. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type 133 Code 0 Checksum The ICMP checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Option Fields: Type XX (TBD) Length 128 bits DSH IPv6 address The IPv6 address of the X6 host requesting a temporary IPv4 address. If DSH has several IPv6 address, the one that can be routed from Y6/Y4 MUST be used. 3.2 RA for IPv4 address allocation [borrowed from RFC2461] The present draft specifies a new option called "DSTM", that routers send out in a Router Advertisement message. To ease the management of this option, the document also specifies a "D" bit in the ICMP header of the RA messages indicating that the router acts as a DSTM border gateway. Routers MUST send this RA only on response to a Router Solicitation with option "DSH mapping request". 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|D| Res. | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address Typically the source address of an invoking Router Solicitation. This is the Ipv6 address of the DSH sent in the triggering RS packet. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type 134 Code 0 Checksum The ICMP checksum. See [ICMPv6]. Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router). M 1-bit "Managed address configuration" flag. When set, hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is described in [ADDRCONF]. O 1-bit "Other stateful configuration" flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [ADDRCONF]. H According to draft-ietf-mobileip-ipv6-14.txt, the Home Agent (H) bit is set to value 1 in a Router Advertisement to indicate that the router sending this Router advertisement is also functioning as a Mobile IP home agent on this link. Else this bit MUST be set to 0 D The bit D is set to 1 to indicate in a Router Advertisement that the router sending this router advertisement is also functioning as a DSTM border gateway. Else this bit MUST be set to 0. Res A 4-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The maximum value corresponds to 18.2 hours. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. Reachable Time 32-bit unsigned integer. The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm. A value of zero means unspecified (by this router). Retrans Timer 32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm A value of zero means unspecified (by this router). As possible in [ND], this draft proposes a new option called "DSTM". Format of the "DSTM" option : This document proposes to specify a new option field to hold the IPv4 temporary address associated to the requesting DSH and the IPv6 address of the TEP that can be different from the DSTM gateway. The format of the DSTM option is as follows: 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 | Reserved MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (TBD) Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value of 4 is mandatory. Nodes MUST silently discard an ND packet that contains a DSTM option with length different from 4. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the IPv4 and IPv6 addresses are valid for the purpose of the DSTM association. A value of all one bits (0xffffffff) represents infinity. Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the IPv4 and IPv6 addresses are prefered for the purpose of the DSTM association. A value of all one bits (0xffffffff) represents infinity. IPv4 address: The temporarily IPv4 address allocated to the DSH by the DSTM border gateway. IPv6 address: The address of the TEP that will be used by the DSH. This address is generally the DSTM border gateway, but MAY be different. Since RA packets send by Y6/Y4 to X6 are encapsulated into IPv6 packets, the standard MTU rules apply. There is no need to send multiple fragments of RA packet. 3.3 Request of Dual Stack Node to renew the lease Before expiration of an initial lease, the node just send a "normal" RS to IPv6/V4 router. It's the responsibility of the router to issue a new lease with a "normal" RA with a new duration. The router MAY use an exponential allocation duration to limit the RS/RA traffic. 4. Security issues By the virtue of authentication headers in RA/RS messages, communication in the IPv6 network are safe. Nevertheless, there is a risk of deny of service if a malicious IPv4 node initiates lot of connections to IPv6 node. This risk is mitigate by the reuse of the same temporary IPv4 address by the IPv6 node for all its simultaneous communications with several IPv4 nodes. To be successful such an attack must be conducted by a single IPv4 node against several different IPv6 nodes. This can be avoided by the DSTM gateway that MAY limit the number of association for a single IPv4 host. 5. Conclusion We showed that when collocating the DSTM server in the Y6/Y4 router, we end up with a simple symmetric mechanism for communications issued from IPv4 only node or from Y6/Y4 Dual Stack Node. In using RA/RS messages we do not introduce huge burden on the router or on the IPv6 node. This simple mechanism, when implemented in Y6/Y4 router and IPv6 node, will make DSTM a very simple to deploy and to operate, general purpose transition mechanism. 6. References [DSTM] Jim Bound, Laurent Toutain, Francis Dupont, Hossam Afifi, Alain Durand, "Dual Stack Transition Mechanism (DSTM)", , January 2001, Work in Progress. [ND] Narten, Nordmark, Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998. [ADDRCONF] Thomson, S and T. Narten IPv6 Address Autoconfiguration RFC 2462, December 1998. [ICMPv6] Conta A and S Deering "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification " RFC 2463, December 1998. [IPv6] S Deering and R Hinden " Internet Protocol Version 6 (IPv6) Specification " RFC 2460, December 1998. [MOBV6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6" , July 2000, Work in Progress. Author's Address Philippe Bereski Alcatel route de Nozay 91461 Marcoussis France (+33) 16963 4436 Philippe.Bereski@alcatel.fr Gilles Diribarne Alcatel route de Nozay 91461 Marcoussis France (+33) 16963 4645 Gilles.Diribarne@alcatel.fr Damien Galand Alcatel route de Nozay 91461 Marcoussis France (+33) 16963 4184 Damien.Galand@alcatel.fr Copyright Notice Placeholder for ISOC copyright.