Internet DRAFT - draft-bereski-ngtrans-nd-dstm
draft-bereski-ngtrans-nd-dstm
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
<draft-bereski-ngtrans-nd-dstm-01.txt>
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)", <draft-ietf-ngtrans-dstm-07.txt>, 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" <draft-ietf-mobileip-ipv6-15.txt>, July 2001, Work in
Progress.
[DSTMPORTS] Y. Kim, A. Durand, "Ports Option Support in DSTM",
<draft-shin-ngtrans-dstm-ports-00.txt>, 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.
