Effects of ICMPv6 on IKE
draft-arkko-icmpv6-ike-effects-02
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Jari Arkko | ||
| Last updated | 2003-03-07 | ||
| 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
The ICMPv6 protocol provides many functions which in IPv4 were either non-existent or provided by lower layers. IPv6 architecture also makes it possible to secure all IP packets using IPsec, even ICMPv6 messages. IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is hard, particularly with ICMPv6 packets related to Neighbor Discovery. Sound looking policies may easily lead to loops: The establishment of security requires Neighbor Discovery messages which can not be sent since security has not been established yet. The purpose of this draft is to inform system administrators and IPsec implementors in which manner they can handle the ICMPv6 messages. Common understanding of the way that these messages are handled is also necessary for interoperability, in case vendors hardcode such rules in to products.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)