Extending ICMP for Node Identification
draft-intarea-extended-icmp-nodeid-00
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Bill Fenner , Reji Thomas | ||
| Last updated | 2024-09-26 | ||
| Replaces | draft-fenner-intarea-extended-icmp-hostid | ||
| Replaced by | draft-ietf-intarea-extended-icmp-nodeid | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-intarea-extended-icmp-nodeid | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where each interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6).
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)