NGTRANS WG Philippe Bereski Damien Galand G‰rard Gastaud Alcatel Gilles Diribarne UDcast Internet Draft Title:draft-bereski-ngtrans-nd-dstm-01.txt Expires : August 2002 February 2002 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. As stated in [DSTM] : "In DSTM, a mechanism is needed to perform the address allocation process. This can be decoupled in two functions: the management of the IPv4 address pool and the communication protocol between server and clients. A number of mechanisms, like DHCPv6, can perform these functions. The choice of the method to be used is out of scope and will be described in other documents." The aim of this document is to propose such a mechanism where a router, using extensions to neighbour discovery [ND], can manage this allocation process. It is worth to mention that the idea to entrust to a router the management of a pool of addresses is already widely used in NAT. Index 1. Introduction 1.1 Scope of the document 1.2 IPv6 DSTM Terminology [Borrowed from [DSTM]] 2. Using neighbour discovery for DSTM 2.1 Communication initiated by a DSTM Node 2.2 Communication initiated by a IPv4 only Host 2.3 Tunneling of new ND messages 2.4 DSTM requirements related to tunneling for DSTM Nodes and servers 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 Annex A: Provision for port range management Changes 00->01: Following remarks issued during IETF 52nd SLC meeting, - add section 1.2 - complete section 2.3, add section 2.4 - update draft accordingly to draft-ietf-ngtrans-dstm-07.txt - Add an annex for port range management [DSTMPORTS] 1. Introduction 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 is available. The aim of this document is to show how a TEP 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 DSTM Node. In particular, it does not describe the communication between the V4 host and the DSTM Node after the 4over6 interface has been configured. 1.2 IPv6 DSTM Terminology [Borrowed from [DSTM]] DSTM Domain The network areas on an Intranet where IPv6 nodes use DSTM to assure IPv4 communication. An IPv4 address allocation server may be deployed inside the domain to manage an IPv4 address pool. IPv4 routing access may not be maintained within a DSTM domain. DSTM Server A process in charge of managing the IPv4 address space that will be allocated to DSTM Nodes. Tunnel End Point (TEP) Destination of IPv6 flows containing IPv4 packets. It assures the forwarding function between the DSTM domain and a given IPv4 network. 4over6 Tunnelling Encapsulation of IPv4 packets over IPv6. Used for carrying IPv4 flows from one node to another in a DSTM Domain. DSTM Client A process on a DSTM Node who manages the temporary IPv4 address allocated by the DSTM Server. DSTM Node A node that implements both IPv4 and IPv6 stacks, 4over6 tunnelling and is a DSTM client. A DSTM node generates only IPv6 packets on the network. 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 DSTM Host 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. There is a need for a dialog between the DSTM Node and the DSTM server, similarly to the dialog in the neighbour discovery process. This section shows this dialog when the communication is initiated by a DSTM 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 DSTM Node, X6 will be the IPv6 address of this host and X4 the IPv4 address Y will designate a DSTM server. Z will designate an IPv4-only host and Z4 its address. ==> means an IPv6 packet --> means an IPv4 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 DSTM Node DNS DSTM Node DSTM server V4 host X6 Y6/Y4 Z4 | | | |. . . . . . . .> Z | - DSTM Node asks the DNS for an AAAA for Z |<. . . . . . . error | - the DNS answers with an error |. . . . . . . .> Z | - DSTM Node asks for the A RR for Z |<. . . . . . . . Z4 | - the answer is Z4 | | | - The application sends its first IPv4 | | | packet which arrives to the 4over6 | | | interface not yet configured. DSTM Node | | | needs an IPv4 address (first use). |+=+=+=+=+>| | - DSTM Node queries the DSTM server for an | | | IPv4 address using an encapsulated RS | | | request. |<+=+=+=+=+| | - The DSTM server provides a temporary | | | IPv4 address and the TEP address with an | | | encapsulated RA answer to DSTM Node. | <=====| | - The DSTM server sends dynamic update to | | | DNS with the temporary IPv4 address of | | | the DSTM Node for further IPv4 initiated | | | communications | | | - The 4over6 now fully configured interface | | | can send the IPv4 encapsulated in IPv6 packet | | | to the TEP. As specified in [ND] RA/RS packets have a local link scope. To overpass this packets exchanged between the DSTM server and the DSTM Node are encapsulated in IPv6 packets. 2.2 Communication initiated by a IPv4 only node DNS DSTM Node DSTM server V4 host X6 Y6/Y4 Z4 | | | | < . . . . . . . | - Z4 asks the DNS for an A RR for "X" | +=+=+>| | - the DNS only finds a IPv6 address. It | | | generates itself the RS request that DSTM | | | host makes in the case of communication | | | described in 2.1. |<+=+=+=+=+| | - DSTM server allocates a temporary IPv4 | | | address, choose a TEP and sends both with | | | an encapsulated RA to the DSTM Node. | <+=+=+| | - DSTM server 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 DSTM Node | | | through the TEP. Because DNS just generates itself to DSTM server a request for a temporary IPv4 address as issued by DSTM Node, the case of communication initiated by a IPv4 only nodes is managed in exactly the same way it is when initiated by a DSTM 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 DSTM server and the DSTM host are encapsulated in IPv6 packets. DSTM Node DSTM server | | |+=+=+=+=+>| - RS packet encapsulated in IPv6 packet, | | IPv6 packet fields: | | Sender address: The IPv6 address of the interface | | of DSTM Node that can be routed to DSTM server. | | Destination address: The IPv6 address of DSTM | | server that can be routed from DSTM Node | | Payload: The RS packet. (See chapter 3.1 for its | | detailed format). |<+=+=+=+=+| - RA packet encapsulated in IPv6 packet, | | IPv6 packet fields: | | Sender address: The IPv6 address of DSTM server | | that can be routed to DSTM Node. | | Destination address: The IPv6 address of the | | DSTM Node that can be routed from DSTM server. | | Payload: The RA packet. (See chapter 3.2 for its | | detailed format). The tunnel between DSTM server and DSTM Node (and reciprocally between DSTM Node and DSTM server) is "degenerated" (tunnel entrance and exit coincide with the endpoints of the traffic beeing tunneled). So it does not have any security problem. There is no need for any manual configuration of the TEP addresses. They are known from the encapsulated packet. The tunneling can be automatic for the host and the DSTM server . 2.4 DSTM requirements related to tunneling for DSTM Nodes and servers Current implementations of IPv6, in hosts and routers, do not manage the automatic tunneling. A DSTM capable interface MUST implement the following characteristics: Case of the host: MUST encapsulate DSTM RS packets (see 3.1) sent to the DSTM server. MUST decapsulate any 6over6 packet and accept DSTM RA packets (see 3.2) sent to it by the DSTM server. Case of the DSTM server: MUST encapsulate DSTM RA packets (see 3.2) sent to a DSTM host. MUST decapsulate any 6over6 packet and accept DSTM RS packets (see 3.1) sent to it by a DSTM Node. The way encapsulation and decapsulation are performed, is implementation dependent. It is also implementation dependent to decide if an interface is always "DSTM capable" or if it must be declared "DSTM capable" by an administrator. 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 "DSTM 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DSTM Node IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The IPv6 address of the interface of the DSTM 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 DSTM IPv6 address The IPv6 address of the DSTM Node requesting a temporary IPv4 address. If DSTM Node has several IPv6 address, the one that can be routed from DSTM server MUST be used. 3.2 RA for IPv4 address allocation [borrowed from RFC2461] The present draft specifies a new option called "DSTM", sent out by DSTM server 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 server. The router MUST send this RA only on response to a Router Solicitation with option "DSTM 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 DSTM Node 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-15.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 Server. 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 DSTM Node and the IPv6 address of the TEP that can be different from the DSTM server. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 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 DSTM Node by the DSTM server. IPv6 address: The address of the TEP that will be used by the DSTM Node. This address MAY be the same as the DSTM server address if DSTM server acts also as a TEP. Since RA packets sent by DSTM server to DSTM Node are encapsulated into IPv6 packets, the standard MTU rules apply. 3.3 Request of Dual Stack Node to renew the lease As specified in [DSTM], 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 Server that MAY limit the number of association for a single IPv4 host. 5. Conclusion The use of neighbor discovery messages extensions allows an implementation of DSTM servers on a router. This simple mechanism, when implemented in DSTM router and DSTM host, will make DSTM a very simple to deploy and to operate, general purpose transition mechanism. 6. References [DSTM] Jim Bound, Laurent Toutain, Octavio Medina, Francis Dupont, Hossam Afifi, Alain Durand, "Dual Stack Transition Mechanism (DSTM)", , February 2002, 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 2001, Work in Progress. [DSTMPORTS] Y. Kim, A. Durand, "Ports Option Support in DSTM", , February 2002, Work in progress. Annex A: Provision for port range management If the proposal [DSTMPORTS] is accepted by the working group, we propose to add the port range at end of the RA and RS options. New RA option: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port start | Port end | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port Start: 16-bit unsigned integer. First free port number of a contiguous set of free port numbers ending at Port End. MBZ if not implemented. If zero, Port End MBZ too. Port End: 16-bit unsigned integer. Last free port number of a contiguous set of free port numbers starting at Port Start. MBZ if not implemented. If zero, Port Start MBZ too. New RS option: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DSTM Node IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port start | Port end | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port Start: 16-bit unsigned integer. First free port number of a contiguous set of free port numbers ending at Port End. MBZ if not implemented. If zero, Port End MBZ too. Port End: 16-bit unsigned integer. Last free port number of a contiguous set of free port numbers starting at Port Start. MBZ if not implemented. If zero, Port Start MBZ too. Author's Address Philippe Bereski Alcatel route de Nozay 91461 Marcoussis France (+33) 16963 4436 Philippe.Bereski@alcatel.fr Gilles Diribarne UDCAST 24, Route des Dolines BP 355 06906 SOPHIA ANTIPOLIS Phone: +33 4 93 00 16 60 Email: Gilles.Diribarne@udcast.com Gerard Gastaud Alcatel 10 rue Latecoere BP 57 78141 Velizy Cedex France E-mail: gerard.gastaud@alcatel.fr Damien Galand Alcatel route de Nozay 91461 Marcoussis France (+33) 16963 4184 Damien.Galand@alcatel.fr Copyright Notice Placeholder for ISOC copyright.