One document matched: draft-ietf-ipngwg-icmp-00.txt
Network Working Group A. Conta (Digital Equipment Corporation)
INTERNET-DRAFT S. Deering (Xerox PARC)
December 1994
ICMP for the Internet Protocol Version 6 (IPv6)
draft-ietf-ipngwg-icmp-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."
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited.
Abstract
This document specifies a set of Internet Control Message Protocol
(ICMP) messages for use with version 6 of the Internet Protocol
(IPv6). The Internet Group Management Protocol (IGMP) messages
specified in RFC-1112 have been merged into ICMP, for IPv6, and are
included in this document.
Conta & Deering Expires in six months [Page 1]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
Table of Contents
1. Introduction.......................................3
2. ICMP for IPv6......................................3
3. ICMP Error Messages................................7
3.1 Destination Unreachable Message.............7
3.2 Packet Too Big..............................9
3.4 Time Exceeded Message.......................10
3.5 Parameter Problem Message...................12
4. ICMP Non-Error Messages............................13
4.1 Echo Message................................13
4.2 Echo Reply Message..........................14
4.3 Group Membership Message....................16
5. References.........................................18
6. Acknowledgements...................................19
7. Security Considerations............................19
Conta & Deering Expires in six months [Page 2]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
1. Introduction
The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6
uses the Internet Control Message Protocol (ICMP) as defined for IPv4
[RFC-792], with a few changes. The Internet Group Membership
Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised
and has been absorbed into ICMP for IPv6.
This document describes the format of a set of control messages used
in ICMP for IPv6. This document does not describe the procedures
that use these messages to achieve functions like Neighbor Discovery
and Path MTU Discovery; these procedures are described in companion
documents ([IPv6-DISC], and respectively [RFC-1191]). Terminology
defined in the IPv6 specification [IPv6] and the IPv6 Routing and
Addressing specification [IPv6-ADDR] applies to this document as
well.
2. ICMP for IPv6
IPv6 ICMP is used by IPv6 nodes to report errors encountered in
processing packets, and to perform other internet-layer functions,
such as diagnostics (ICMP "ping"), neighbor discovery, and multicast
membership reporting. IPv6 ICMP is an integral part of IPv6 and MUST
be implemented by every IPv6 node.
ICMP messages are grouped into two classes.
ICMP error messages, such as:
Destination Unreachable
Packet Too Big
Time Exceeded
Parameter Problem
ICMP non-error messages, such as:
Echo
Echo Reply
Group Membership Query
Group Membership Report
Group Membership Termination
Advertisment
Solicitation
Conta & Deering Expires in six months [Page 3]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
This document defines the message formats for the following IPv6 ICMP
messages:
ICMP error messages:
Destination Unreachable (see section 3.1)
Packet Too Big (see section 3.2)
Time Exceeded (see section 3.3)
Parameter Problem (see section 3.4)
ICMP non-error messages:
Echo (see section 4.1)
Echo Reply (see section 4.2)
Group Membership (see section 4.3)
Other documents may define other ICMP messages. For example [IPv6-
DISC] defines in detail the format of the following IPv6 ICMP
messages:
Advertisment
Redirect
Solicitation
Every IPv6 ICMP message is preceded by an IPv6 header and zero or
more IPv6 extension headers. The ICMP header is identified by a Next
Header value of 1 in the immediately preceding header.
The IPv6 ICMP messages have the following general 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Body |
| |
The type field indicates the type of the message. Its value
determines the format of the remaining data.
The code field depends on the message type. It is used to create an
additional level of message granularity.
The checksum is the 16-bit one's complement of the one's complement
sum of the IPv6 Source Address, the IPv6 Destination Address, the
IPv6 Payload Length, the IPv6 Next Header Type, and the entire ICMP
message starting with the ICMP message type. (The rationale for this
Conta & Deering Expires in six months [Page 4]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
checksum computation is described in [IPv6]). For computing the
checksum, the checksum field is set to zero.
Implementation Notes:
An application that sends ICMP messages has to fill in both the
Source and Destination IPv6 Addresses in the IPv6 header before
calculating the checksum. If the node has multiple source addresses,
it is necessary to make an appropriate selection, based on the
destination address, TClass, and flow id. This requires the
implementation of a function:
source_ipv6_address = get_source_address (
destination_ipv6_address,
TClass,
flow-id
)
The following rules are suggested for implementing this mapping:
(a) If the remote Internet address lies on one of the (sub)nets to
which the node is directly connected, a corresponding source
address may be chosen, unless the corresponding interface is
known to be down.
(b) The route cache may be consulted, to see if there is an active
route to the specified destination network through any network
interface; if so, a local IPv6 address corresponding to that
interface may be chosen.
If the route cache does not contain information about static
routes or default routers, then consult similarly:
(c) The table of static routes, and
(d) The table of default routers. As default routers may be
associated with a preference, chose the highest preference
router.
Implementations MUST observe the following rules when processing IPv6
ICMP messages (from [RFC-1122]):
(a) If an IPv6 ICMP message of unknown type is received, it MUST
be silently discarded.
(b) Every IPv6 ICMP error message (the first four messages in
Conta & Deering Expires in six months [Page 5]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
the above list) includes as much of the IPv6 offending
(invoking) packet (the packet that causes the error) as will
fit without making the error message packet exceed 576
octets.
In case the ICMP packet that would result exceeds the size
of 576 octets, then truncate the ICMP packet to a size of
576 octets. If the ICMP packet contains a pointer to a bad
parameter and the ICMP message had to be truncated, the
pointer may point beyond the end of the ICMP message if the
bad parameter was in the part of the ICMP message that had
to be truncated.
(c) In those cases where the Internet layer is required to pass
a IPv6 ICMP error message to the transport layer, the IPv6
Transport Protocol MUST be extracted from the original
header (contained in the body of the IPv6 ICMP error
message) and used to select the appropriate transport
protocol entity to handle the error.
(d) An IPv6 ICMP error message MUST NOT be sent as a result of
receiving:
(d.1.)an IPv6 ICMP error message, or
(d.2.)a packet destined to an IPv6 multicast address (an
exception to this rule is the Packet Too Big Message -
Section 3.2 - to allow Path MTU discovery to work for
IPv6 multicast), or
(d.3.)a packet sent as a link-layer multicast, or
(d.4.)a packet sent as a link-layer broadcast, or
(d.5.)a packet whose source address does not uniquely identify
a single node -- e.g., the IPv6 Unspecified Address, or
an IPv6 multicast address.
(e) Finally, to each sender of an erroneous data packet, an IPv6
node MUST limit the rate of ICMP error messages sent. One
could limit the rate based on not sending more than N ICMP
error messages per second to a certain destination. For such
an implementation a value of <TBD> for N is recommended.
The following sections describe the message formats for the above
IPv6 ICMP messages.
Conta & Deering Expires in six months [Page 6]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
3. ICMP Error Messages
3.1. Destination Unreachable Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
| as will fit without ICMP packet |
| exceeding 576 octets |
| |
IPv6 Fields:
Source Address
The IPv6 address of the node that composes
(sends) the ICMP message.
Destination Address
The IPv6 address of the node to which the
ICMP message is sent.
IPv6 ICMP Fields:
Type 3
Code 0 - intermediate router unreachable
1 - destination address unreachable (last hop)
2 - unused
3 - port unreachable
4 - unused
5 - unused
6 - destination router or prefix unkown
7 - destination address unknown (last hop)
8 - source node isolated
9 - communication with intermediate router
administratively prohibited
10 - communication with destination node
administratively prohibited (last hop)
Unused This field is unused for all code values.
Conta & Deering Expires in six months [Page 7]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
It must be initialized to zero by the sender
and ignored by the receiver.
Description
A Destination Unreachable SHOULD be sent by a router in response to a
packet which it cannot forward either because the next router
destination address is unreachable (code 0), the node destination
address is unreachable (code 1), the next router destination address
is unknown (code 6), the node destination address is unknown (code
7), or if the router is administratively prohibited from forwarding
packets to the destination of the IPv6 packet either to a router
(code 11), or to the final destination which is a node (code 12).
A host SHOULD generate a Destination Unreachable message in response
to a packet when the transport protocol indicated by the Next Header
Type field (such as UDP) is unable to demultiplex the packet (code 3)
but has no protocol mechanisms to inform the sender.
NOTE:
The distinction between node or router for messages with code <0, or
1>, <6, or 7>, <9, or 10> is made by the ICMP packet generator based
on whether the packet is being forwarded to an intermediate router
(the packet is en route) or to its final destination node (last hop).
Also the distinction between messages with code <0, or 1>, and <6, or
7>is made by the ICMP packet generator based on whether the packet is
unreachable because of a link-level problem, or because the
destination is not in the route cache.
Upper layer notification
A node receiving the ICMP Destination Unreachable message MUST notify
the upper layer.
Conta & Deering Expires in six months [Page 8]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
3.2. Packet Too Big Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
| as will fit without ICMP packet |
| exceeding 576 octets |
| |
IPv6 Fields:
Source Address
The IPv6 address of the node that composes
(sends) the ICMP message.
Destination Address
The IPv6 address of the node to which the
ICMP message is sent.
IPv6 ICMP Fields:
Type TBD
Code 0
MTU The 32-bits of this field contain the next hop's link
Maximum Transmission Unit.
Description
A Packet Too Big MUST be sent by a router in response to a packet
which it cannot forward because the packet is larger than the MTU of
the outgoing link.
A node sending packets that cannot be forwarded by a router due to
the packets exceeding the MTU of the next-hop link will receive from
that router the ICMP Packet Too Big message, reporting the MTU of
that next-hop link.
The node SHOULD store that PMTU information and use it for subsequent
packets sent to the same destination. Using this mechanism, if the
Conta & Deering Expires in six months [Page 9]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
packets are traversing several networks (forwarded by several
routers), a node may receive several ICMP Packet Too Big messages
until the PMTU to the final destination is learned. It is up to the
transport or application protocol to make sure that packets lost
because of inadequate PMTU are retransmitted.
The minimum legal value of the next-hop MTU field in a "packet too
big" message (code 4) received by an IPv6 node is 68 octets. While
IPv6 requires all links in the Internet to have an MTU of 576 octets
or greater, the smaller minimum legal value is required to allow Path
MTU discovery to work correctly when IPv6 packets are undergo
translation to IPv4 packets (see Section 5 in [IPv6-SIT]).
Upper layer notification
An incoming Packet Too Big message MUST be passed to the transport
layer.
3.3. Time Exceeded Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
| as will fit without ICMP packet |
| exceeding 576 octets |
| |
IPv6 Fields:
Source Address
The IPv6 address of the node that composes
(sends) the ICMP message.
Destination Address
The IPv6 address of the node to which the
ICMP message is sent.
IPv6 ICMP Fields:
Conta & Deering Expires in six months [Page 10]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
Type 11
Code 0 - hop limit exceeded in transit
1 - fragment reassembly time exceeded
Unused It must be initialized to zero by the sender
and igmored by the receiver.
Description
If a router receives a packet with a Hop Limit of zero, or a router
decrements a packet's Hop Limit to zero, it discards the packet and
sends an IPv6 ICMP Time Exceeded message with code 0. This indicates
either a routing loop or too small an initial Hop Limit value.
IPv6 systems are expected to avoid fragmentation by implementing Path
MTU discovery. However, IPv6 defines an end-to-end fragmentation
function for backwards compatibility with existing higher-layer pro-
tocols and IPv4-to-IPv6 translation.
From [RFC-1122], the IPv6 layer within IPv6 hosts MUST implement
reassembly of IPv6 fragments. There MUST be a reassembly timeout.
The reassembly timeout SHOULD be a fixed value. It is recommended
that this value lie between 60 and 120 seconds. If the timeout
expires, the partially-reassembled datagram MUST be discarded. If the
fragment with offset zero was received, the destination host SHOULD
also send an IPv6 ICMP Time Exceeded message with code 1.
Upper layer notification
An incoming Time Exceeded message MUST be passed to the transport
layer.
Conta & Deering Expires in six months [Page 11]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
2.5. Parameter Problem Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
| as will fit without ICMP packet |
| exceeding 576 octets |
| |
IPv6 Fields:
Source Address
The IPv6 address of the node that composes
(sends) the ICMP message.
Destination Address
The IPv6 address of the node to which the
ICMP message should be sent.
IPv6 ICMP Fields:
Type 12
Code 0 means Pointer field indicates incorrect parameter.
1 means unrecognized Next Header type
2 means unrecognized IPv6 option
Pointer identifies the octet offset within the
invoking packet where an error was detected.
The pointer will point beyond the end of the ICMP packet,
if the parameter in error is beyond what can fit in the
576-byte limit of an ICMP error message.
Description
If an IPv6 node processing a packet finds a problem with the parame-
ters in the IPv6 header or extension headers such that it cannot com-
plete processing the packet, it MUST discard the packet and SHOULD
Conta & Deering Expires in six months [Page 12]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
send an ICMP Parameter Problem message.
Upper layer notification
A node receiving this ICMP message MUST notify the upper layer.
4. ICMP Non-Error Messages
4.1. Echo Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
IPv6 Fields:
Source Address
The IPv6 address of the node that composes
(sends) the ICMP message.
Destination Address
The IPv6 address of the node to which the
ICMP message should be sent.
IPv6 ICMP Fields:
Type 8 - Echo Message
Code 0
Identifier If code = 0, some identifier to match echo messages
with echo replies. May be zero.
Sequence Number If code = 0, a sequence number to aid in matching
echo messages with echo replies. May be zero.
Description
Every node MUST implement an ICMP Echo server function that receives
Conta & Deering Expires in six months [Page 13]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
Echo Requests and sends corresponding Echo Replies. A node SHOULD
also implement an application-layer interface for sending an Echo
Request and receiving an Echo Reply, for diagnostic purposes.
An Echo Reply SHOULD be sent in response to an Echo message sent to
an IPv6 multicast address. The source address of the reply MUST be a
unicast address belonging to the interface on which the multicast
Echo message was received.
The source address of an Echo Reply sent in response to a unicast
Echo message MUST be the same as the destination address of that Echo
message.
Upper layer notification
A node receiving this ICMP message MUST notify the upper layer.
Implementation Note:
An application that sends ICMP Echo messages has to fill in both the
Source and Destination IPv6 Addresses in the ICMP header before
calculating the checksum. Please see the Implementation Note in
Section 2.
4.2. Echo Reply Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
IPv6 Fields:
Source Address
The IPv6 address of the node that composes
(sends) the ICMP message.
Destination Address
The IPv6 address of the node to which the
ICMP message should be sent.
Conta & Deering Expires in six months [Page 14]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
IPv6 ICMP Fields:
Type 0 - Echo Reply Message
Code 0
Identifier If code = 0, some identifier to match echo messages
with echo replies. May be zero.
Sequence Number If code = 0, a sequence number to aid in matching
echo messages with echo replies. May be zero.
Description
Every node MUST implement an ICMP Echo server function that receives
Echo Requests and sends corresponding Echo Replies. A node SHOULD
also implement an application-layer interface for sending an Echo
Request and receiving an Echo Reply, for diagnostic purposes.
An Echo Reply SHOULD be sent in response to an Echo message sent to
an IPv6 multicast address. The source address of the reply MUST be a
unicast address belonging to the interface on which the multicast
Echo message was received.
The source address of an Echo Reply sent in response to a unicast
Echo message MUST be the same as the destination address of that Echo
message.
The data received in the ICMP Echo message MUST be returned entirely
and unmodified in the ICMP Echo Reply message. However, if the Echo
Reply would exceed the path MTU of the path back to the Echo
requestor, then the Echo Reply message MUST be truncated to the path
MTU size and sent.
Upper layer notification
Echo Reply messages MUST be passed to the ICMP user interface, unless
the corresponding Echo Request originated in the IP layer.
Implementation Note:
An application that sends ICMP ECHO messages has to fill in the ICMP
header both the Source and Destination IPv6 Addresses before
calculating the checksum. See the Implementation Note in Section 2.
Conta & Deering Expires in six months [Page 15]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
4.3. Group Membership Messages
The ICMP Group Membership Messages have 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Multicast |
+ +
| Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Fields:
Source Address
The IPv6 address of the node that composes (sends) the
ICMP message.
Destination Address
The IPv6 address of the node to which the ICMP message
is sent.
IPv6 ICMP Fields:
Type TBD - Group Membership Query
TBD - Group Membership Report
TBD - Group Membership Termination
Code In Query messages, the Code field specifies the
maximum time that responding Reports may be delayed.
In Report and Termination messages, the Code field
is initialized to zero by the sender and ignored by
receivers.
Unused Initialized to zero by the sender; ignored by receivers.
Conta & Deering Expires in six months [Page 16]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
Multicast Address
The address if the multicast group about which the
message is being sent. In Query messages, the Multicast
Address field may be zero, implying a query for all
groups.
Description
The ICMP Group Membership messages are to convey information about
multicast group membership from nodes to their neighboring routers.
The details of their usage is given in [RFC-1112].
4.4. Solicitation and Advertisment
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Body |
+ +
| |
Type 33 - solicitation
34 - advertisment
[IPv6-DISC] defines in detail this ICMP message header format.
5. References
[IPv6]R. Hinden, "Internet Protocol Version 6 Specification",
Internet Draft, <DRAFT-HINDEN-IPNG-IPV6-SPEC-00.TXT>. October
1994
[IPv6-ADDR]
R. Hinden. IP Next Generation Addressing Architecture.
Internet Draft <DRAFT-HINDEN-IPNG-ADDR-00.TXT>. October 1994.
Conta & Deering Expires in six months [Page 17]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
[IPv6-DISC]
W. A. Simpson "Neighbor Discovery", Internet Draft, <DRAFT-
SIMPSON-IPV6-DISCOV-FORMATS-01.TXT>, November 1994
[IPv6-SIT]
R.Gilligan, E. Nordmark, "Simple Internet Transition
Overview", Internet Draft, <DRAFT-GILLIGAN-IPV6-SIT-OVERVIEW-
01.TXT>, November 1994
[RFC-792]
J. Postel, "Internet Control Message Protocol", RFC 792.
[RFC-1112]
S. Deering, "Host Extensions for IP Multicasting", RFC 1112.
[RFC-1122]
R. Braden, "Requirements for Internet Hosts - Communication
Layers", RFC 1122.
[RFC-1191]
J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191.
[RFC-1256]
S. Deering, "ICMP Router Discovery", RFC 1256.
[TRANS-MECH]
R. Gilligan, E. Nordmark. IPv6 Transition Mechanisms for Hosts
and Routers. Internet Draft <draft-gilligan-ipv6-trans-
mechanisms-00.txt>. November 1994.
6. Acknowledgements
The document is derived from the "ICMP and IGMP for SIPP" document
published as a draft by Ramesh Govindan and Steve Deering in March
1994.
Extensive review information and feedback was provided by Robert Elz,
Conta & Deering Expires in six months [Page 18]
INTERNET-DRAFT ICMP for IPv6 December 3, 1994
Jim Bound, and others.
7. Security Considerations
Security considerations are not discussed in this memo.
Authors' Addresses:
Alex Conta Stephen Deering
Digital Equipment Corporation Xerox Palo Alto Research Center
110 Spitbrook Rd 3333 Coyote Hill Road
Nashua, NH 03062 Palo Alto, CA 94304
+1-603-881-0744 +1-415-812-4839
email: conta@zk3.dec.com email: deering@parc.xerox.com
| PAFTECH AB 2003-2026 | 2026-04-23 06:20:25 |