INTERNET-DRAFT Alain Durand, IMAG
November 18, 1997 Laurent Toutain, ENSTb
Expires April 23, 1998
IPv6 traceroute option
<draft-durand-ipv6-traceroute-00.txt>
Status of this Memo
-------------------
This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
This draft expires in February 10, 1998.
1 Abstract
----------
The traceroute program has proven very useful and has been
extensively used in the Internet for measurement and debugging
purposes. However, it only shows the originator to target path
and gives no indication on the reverse path. Source routing may
sometimes be used to find it, but it's very often disable by
intermediary routers.
Another problem occurs when packets do not follow the same routes:
traceroute outputs are very difficult to read.
Other solutions has been proposed to record the route taken by
an IPv4 packet. Originally, IPv4 contains an option in which every
intermediary router can add its address [RFC791]. Unfortunately,
the limitation in size imposed by the options design of IPv4 limits
its use to 9 routers.
In [RFC1393] another strategy was proposed. An new IPv4 option was
created. When a router receives a packet containing this option,
it generates a ICMP Echo message to the source. This technique
couldn't be widely deployed in IPv4 because it needed a change
in every single router to be efficient.
These two methods create less traffic on the network and are more
accurate, since they give the real route taken by packets and are
less sensitive to fluttering. The IPv6 deployment could be the
opportunity to widely deploy a new traceroute mechanism based on
those two methods.
We propose to combine the two previous methods by defining a new
hop-by-hop option and a new ICMP message type to record the direct
path from the originator to the target and the reverse path from
the target to the originator.
2 Underlying concepts
----------------------
Four strategies can be used. The first one is the most efficient
in term of packets carried by the network, but can fails on large
networks or in case of packet loss.
The originating host places a traceroute hop-by-hop option in
an ICMP echo request message sent to the target. Routers process
this option by adding information in the fields of the option.
The target returns an ICMP echo reply to the source using a
traceroute hop-by-hop option initialized with the content of the
traceroute option received in the ICMP echo request message.
Routers on the return path also record information in this option.
The ICMP echo messages payload SHOULD be empty in order to save
space for the traceroute option.
If the minimum MTU is 576 bytes, only 21 routers can be recorded,
but if the minimum MTU is raised to 1 200 bytes, 47 routers could be
recorded within the traceroute option.
In case of large network or small MTU, it could not be possible to
store all the routers information in a single packet. In a second
strategy, the originating packet can include a boundary indication.
Only the routers after this boundary will record information.
This originator will have to specify if this apply to the direct
path or the reverse path. One should notice that fluttering might
disturb measurements.
In case of congestion in heavy loaded networks, the odds of packet
loss are high. As a third strategy, a debugging mode, close to the
[RFC1393] method is specified. Every router receiving the traceroute
hop-by-hop option including a debug flag should send back a ICMP
message to the originator.
A combination of the second and third strategy can be used in a
fourth one.
3. hop-by-hop traceroute option
-------------------------------
The traceroute option (value TBD)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Ptr | Flags | Boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| space to record information |
| |
| |
.......
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value: TBD
Length: option length in 64 bit not including the traceroute option
ID: Identifier randomly chosen by the originator
Ptr: first 64 bit word available to store router information
Flags: U U S D O R P B
B: Backward. gives the direction
0 : forward, originator to target
1: backward, target to originator
P: Partial node
0 : record all information
1 : only record information from router located after
the boundary
R: Reverse record. Only if the P flag is on
0 : boundaries apply to the direct path
1 : boundaries apply to the reverse path
O: Overflow. indicates an overflow in the packet
0 : there is some room left in the option to record information
1 : overflow, routers SHOULD NOT any more information
D: Debug mode
0 : routers SHOULD insert information in the traceroute option
1 : routers SHOULD send an ICMP packet either to the source or
the destination according to the B bit
S: Source route. Only applyes if a source routing option is used
and the D bit is on.
0 : source routing, reverse the source route
1 : source routing and calculate a route
U: Undefined, reserved for future use.
Boundary: applies only in partial mode. Give the lower boundary for
recording. If the HOP LIMIT of the packet is higher than
this value, the router SHOULD NOT record information.
Note:
If the R and B flags have not the same value, routers SHOULD NOT
include any information.
The originator MUST set the B flag to zero and the Hop limit
to 255.
The target MUST turn the B flag and reset the Hop limit to 255.
In the first strategy, the P and the D flag are off.
In the second strategy, the P flag is on and the D flag is off.
In the third strategy, the P flag is off and the D flag is on.
Second and third strategy can be combined by turning the P and D
flag on.
The strategy choice is made by the originator. The target MUST
replicate those strategy bits when building the traceroute option.
4. Information inserted by routers.
-----------------------------------
Routers should include information from the receiving interface
using the following format:
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 | HL | Medium | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the format of the information included by the router,
current type is 1.
HL: the Hop Limit value in the request packet
Medium: the nature of the link, the code is given in [RFC1700]
AS: Autonomous System number
address: a 'meaningfull' IPv6 address of the equipment.
MBZ: MUST BE ZERO
5. ICMP debugging message.
-------------------------
In the debug mode, routers should return this ICMP message to the
originator.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | MBZ | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | HL | Medium | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| |
+ address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID: Identifier randomly value chosen by the originator
HL: Hop Limit value in the received packet
Medium: the nature of the link, the code is given in [RFC1700]
AS: Autonomous System number (optional)
address: a 'meaningful' IPv6 address of the equipment
MBZ: MUST BE ZERO
5. Security consideration
-------------------------
Unlike the original traceroute program, the traceroute option
does not use any UDP port number. This mechanism can go through
firewall if allowed. Router may not return information,
if the traceroute option is not implemented or configured
not to answer.
Authentication option can restrict the use of this mechanism
to specific originators.
6. References
-------------
[RFC791] 1981 Internet Protocol, J. Postel.
[RFC1393] 1393 Traceroute Using an IP Option. G. Malkin.
January 1993.
7. Author addresses
-------------------
Alain Durand
Institut d'Informatique et de Mathematiques Appliquees de Grenoble
IMAG BP 53 38041 Grenoble CEDEX 9 France
Phone : +33 4 76 63 57 03
Fax : +33 4 76 51 49 64
E-Mail: Alain.Durand@imag.fr
Laurent Toutain
Ecole Nationale Superieure de Telecom de Bretagne
2, rue de la chataigneraie 35512 Cesson Sevigne CEDEX France
Phone: +33 2 99 12 70 26
Fax : +33 2 99 12 70 30
E-Mail: Laurent.Toutain@enst-bretagne.fr