From: Philippe Bereski (Philippe.Bereski_at_no.spam)
Date: Wed Nov 14 2001 - 06:44:25 PST
All,
Please find here attached the draft we plan to submit to the next IETF
meeting.
Thanks for all the comments you can made on it.
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.
Best regards,
Damien, Gilles, Philippe.
NGTRANS WG Philippe Bereski
Gilles Diribarne
Damien Galand
Alcatel
Internet Draft
Title:draft-many-ngtrans-ND-DSTM-00.txt
Expires : April 2002 November 2001
Dual Stack deployment using DSTM and neighbour discovery
<draft-many-ngtrans-nd-dstm-00.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. 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)",
<draft-ietf-ngtrans-dstm-04.txt>, 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" <draft-ietf-mobileip-ipv6-14.txt>, July 2000, Work in
Progress.
Author's Address
Philippe Bereski
Alcatel
route de Nozay
91461 Marcoussis
France
(+33) 16963 4436
Philippe.Bereski-at-alcatel.fr
Gilles Diribarne
Alcatel
route de Nozay
91461 Marcoussis
France
(+33) 16963 4645
Gilles.Diribarne-at-alcatel.fr
Damien Galand
Alcatel
route de Nozay
91461 Marcoussis
France
(+33) 16963 4184
Damien.Galand-at-alcatel.fr
Copyright Notice
Placeholder for ISOC copyright.
This archive was generated by hypermail 2.1.7 : Fri Oct 06 2006 - 00:00:26 PDT