Generation of ICMPv6 Echo Replies for Teredo Clients
draft-denis-icmpv6-generation-for-teredo-01
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Teemu Savolainen , Remi Denis-Courmont | ||
Last updated | 2009-09-16 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
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
Teredo uses return routing to discover the closest Teredo relay corresponding to any given peer. Discovery is achieved by sending an ICMPv6 Echo Request and waiting for the appropriate relay to forward the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make Teredo clients assume that the peer is unreachable. This document identifies two scenarios where a stateful middlebox can detect the lack of ICMPv6 Echo Reply and craft one for the Teredo client in order to avoid possibly erroneous peer unreachability assumptions.
Authors
Teemu Savolainen
Remi Denis-Courmont
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)