Generation of ICMPv6 Echo Replies for Teredo Clients
draft-denis-icmpv6-generation-for-teredo-01
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Last updated | 2009-09-16 | ||
| Stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
pdf
htmlized
bibtex
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-denis-icmpv6-generation-for-teredo-01.txt
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
(teemu.savolainen@nokia.com)
Remi Denis-Courmont
(remi.denis-courmont@nokia.com)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)