[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

     Network Working Group                                       Jari Arkko
     INTERNET-DRAFT                                                Ericsson
     Category: Standards Track
     <draft-arkko-icmpv6-ike-effects-01.txt>
     23 June 2002
     
     
     
                  Effects of ICMPv6 on IKE and IPsec Policies
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft and is in full conformance with all
     provisions of Section 10 of RFC2026. Internet-Drafts are working docu¡
     ments  of  the  Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also distribute  work¡
     ing documents as Internet-Drafts.
     
     Internet-Drafts  are draft documents valid for a maximum of six months
     and may be updated, replaced, or made obsolete by other  documents  at
     any  time.   It  is  inappropriate to use Internet-Drafts as reference
     material or to cite them other than as work in progress.
     
     The   list   of   current   Internet-Drafts   may    be    found    at
     http://www.ietf.org/ietf/1id-abstracts.txt
     
     The  list  of  Internet-Draft  Shadow  Directories  may  be  found  at
     http://www.ietf.org/shadow.html.
     
     The distribution of this memo is unlimited.  It is  filed  as  <draft-
     arkko-icmpv6-ike-effects-00.txt>,  and   expires July 9, 2001.  Please
     send comments to the author or to  IPsec  and/or  IPNG  working  group
     mailing lists.
     
     2.  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 mes¡
     sages.  IPsec architecture has a Security Policy Database that  speci¡
     fies which traffic is protected, and how. It turns out that the speci¡
     fication of policies in the presence of ICMPv6 traffic is hard.  Sound
     looking  policies may easily lead to loops: The establishment of secu¡
     rity requires ICMPv6 messages  which  can't  be  sent  since  security
     hasn't  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.
     
     
     
     
     
     
     
     J. Arkko                                                      [Page 1]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     3.  Introduction
     
     This draft is a re-submission of an earlier Internet Draft from Febru¡
     ary 2001.  It is intended as an input paper for  the  Secure  Neighbor
     Discovery (SEND) BOF.
     
     The  ICMPv6  protocol  [3]  provides many functions which in IPv4 were
     either non-existent or provided by lower layers.  For  instance,  IPv6
     implements  address  resolution  using  an IP packet, ICMPv6 Neighbour
     Solicitation message [1]. In contrast, IPv4 uses an ARP message  at  a
     lower layer.
     
     IPv6  architecture  makes  it  possible to secure all IP packets using
     IPsec [6], even ICMPv6  messages  and  even  to  multicast  addresses.
     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 not easy. For instance,
     a simple policy of protecting all traffic between  two  hosts  on  the
     same network would trap even address resolution messages, leading to a
     situation where IKE can't establish a Security  Association  since  in
     order  to  send  the  IKE  UDP  packets one would have had to send the
     Neighbour Solicitation Message, which would have required an SA.
     
     The purpose of this draft is to inform system administrators and IPsec
     implementors in which manner they can handle the ICMPv6 messages. Sys¡
     tem administrators do not want to study  the  IPv6  specifications  in
     order  to  understand  how  they  shall configure their routers. IPsec
     implementors want to understand what kind of policies they  can  offer
     with respect to the ICMPv6 messages.
     
     Common  understanding  of  the  way that these messages are handled is
     also very much necessary for interoperability, as some vendors may  be
     hardcoding  some of the low-level policy operations in their products.
     If the rules between two vendors' products are incompatible for a par¡
     ticular  message  we may end with the sender sending cleartext and the
     receiver requiring IPsec, causing the packet to be dropped and  possi¡
     bly all connectivity between the two nodes lost.
     
     4.  ICMPv6 Tasks
     
     In  IPv6,  ICMP  has  several tasks, and many of these tasks are over¡
     loaded on a few central message types such as the Neighbour  Discovery
     message.   In  this  chapter we explain the tasks and their effects in
     order to understand better how the messages should be treated.
     
     4.1.  Path MTU Discovery
     
     Path MTUs are dynamically determined by IPv6 in order to optimize  the
     size of the packets sent to a particular destination [5].
     
     The  ICMPv6 Packet Too Big messages are used as a part of the Path MTU
     Discovery procedure [3].
     
     
     
     
     
     J. Arkko                                                      [Page 2]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     4.2.  Error Notification
     
     ICMPv6 handles basic error situations of the IP layer, such as finding
     out that a particular destination isn't available.
     
     The  Destination  Unreachable,  Packet Too Big, Parameter Problem, and
     Time Exceeded messages are a part of the error handling procedure [3].
     Note that the Packet Too Big message also plays a role in the Path MTU
     Discovery procedure.
     
     4.3.  Informational Notifications
     
     For debugging and network analysis purposes, ICMPv6 includes  informa¡
     tional  messages  [3].  These message are necessary also in IPsec con¡
     texts and over IPsec tunnels due to the complex nature of some  tunnel
     setups.
     
     The Echo Request and Echo Reply messages are used solely for this pur¡
     pose.
     
     4.4.  Router and Prefix Discovery
     
     Router and prefix discovery is a part of the Neighbour Discovery  pro¡
     tocol [1], which in turn is a part of the ICMPv6.  The main purpose of
     the router discovery is to find neighboring routers that  are  willing
     to  forward  packets on the behalf of hosts. Prefix discovery involves
     determining which destinations are local for an  attached  link.  This
     information is used both by the address autoconfiguration process, and
     routing. Typically, address autoconfiguration and  other  tasks  can't
     proceed at all until the router discovery process has run.
     
     The Router Solicitation and Router Advertisement messages are used for
     this and only this purpose.
     
     4.5.  Address Autoconfiguration
     
     Address autoconfiguration is another part of the  Neighbour  Discovery
     protocol  [1].  It's  purpose  is to automatically assign addresses to
     interfaces. It comes in two variants, stateless and statefull. In this
     document  we  consider  only  the stateless autoconfiguration aspects.
     Obviously, no higher layer traffic can be sent until all participating
     nodes have addresses. This includes also IKE UDP traffic.
     
     The  Neighbour  Solicitation  and  Advertisement messages are used for
     this purpose, among other things. Furthermore, Router and Prefix  Dis¡
     covery  and  Duplicate Address Detection have an effect to the Address
     Autoconfiguration tasks.
     
     4.6.  Duplicate Address Detection
     
     As a part of the stateless address autoconfiguration procedure,  nodes
     check  for  duplicate  addresses  prior  to assigning an address to an
     interface [2]. This procedure uses the same messages as the  Neighbour
     Discovery protocol [1]. Since the rules outlined in [2] forbid the use
     
     
     
     J. Arkko                                                      [Page 3]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     of an address for both sending and receiving packets until it has been
     found unique, no higher layer traffic is possible until this procedure
     has completed.
     
     The Neighbour Solicitation and Advertisement messages  are  used  also
     for this purpose.
     
     4.7.  Address Resolution
     
     In  address  resolution,  nodes  determine the link-layer address of a
     local destination given only the destination's IP address [1].  Again,
     no  higher  level traffic can proceed until the sender knows the hard¡
     ware address of the destination or the next hop router.
     
     The Neighbour Solicitation and Advertisement messages  are  used  also
     for this purpose.
     
     4.8.  Neighbor Reachability Detection
     
     Hosts  monitor  the  reachability of local destinations and routers in
     the Neighbour Unreachability procedure, which is a part of the  Neigh¡
     bour  Discovery  protocol  [1]. No higher level traffic can proceed if
     this procedure flushes out  neighbour  cache  entries  after  (perhaps
     incorrectly) determining that the peer is not reachable.
     
     The  Neighbour  Solicitation  and Advertisement messages are used also
     for this purpose.
     
     4.9.  Redirect
     
     In the Redirect procedure, a router informs a host of a better  first-
     hop  node  to  reach a particular destination [1]. It is a part of the
     Neighbour Discovery protocol. As routers forward packets regardless of
     them  being sent first to the wrong place, communications can still be
     established without the ability to process Redirect messages.
     
     The Redirect message is used solely for the Redirect procedure.
     
     4.10.  Router Renumbering
     
     This procedure [4] allows address prefixes on routers to be configured
     and  reconfigured  in  the  similar  manner  as Neighbor Discovery and
     Address Autoconfiguration works for  hosts.  Incorrect  processing  or
     blocking  of  messages  related  to this procedure may render a node's
     address sets invalid, thereby preventing further communications.
     
     The Router Renumbering message is used solely for the Router Renumber¡
     ing procedure.
     
     5.  Factors Affecting the Policy Rules
     
     
     
     
     
     
     
     J. Arkko                                                      [Page 4]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     5.1.  Nature of the Addresses
     
     ICMPv6 messages are sent using various kinds of source and destination
     address types. The source address is usually a  unicast  address,  but
     during  address  autoconfiguration  message exchanges, the unspecified
     address :: is also used as  a  source  address  [2].  The  destination
     address can be either a well known multicast address, a generated mul¡
     ticast address such as the solicited-node multicast address, or a uni¡
     cast  address. While many ICMPv6 messages use multicast addresses most
     of the time, some also use unicast addresses sometimes. For  instance,
     the  Neighbour  Solicitation  messages  are  usually sent to multicast
     addresses, but the Neighbour Advertisement messages are also  sent  to
     unicast  addresses  when  sent  as  a  response  to a node that has an
     address.
     
     IPsec [6] can be used for the protection of both unicast and multicast
     traffic. However, in order to automatically negotiate mutually accept¡
     able security associations and to refresh keys, IKE [7]  needs  to  be
     used.   IKE  is only capable of negotiating SAs for unicast communica¡
     tions.
     
     Obviously, policies MUST  be  configured  so  that  multicast  traffic
     doesn't require dynamic SAs. However, while this is a necessary condi¡
     tion it is not sufficient to make sure that that IKE works. The  poli¡
     cies  MUST  also exclude unicast traffic which is contains ICMPv6 mes¡
     sages required before UDP can work between the two nodes.
     
     5.2.  Network Topology
     
     ICMP traffic has different implications for hosts and  security  gate¡
     ways.  In  general,  security  gateways  SHOULD carry all ICMP traffic
     related to the protected traffic in the same  tunnel  as  the  traffic
     itself.  For instance, when an ICMPv6 Packet Too Big message is gener¡
     ated on the unprotected segment  of  a  packet's  path,  that  message
     should relayed through the tunnel to ensure that the sender recognizes
     the MTU problem.
     
     Between hosts similar rules apply. However, messages  related  to  the
     establishment of communication between the hosts - such as for address
     resolution - MUST NOT be passed through the tunnel at least  when  the
     tunnel does not exist yet and IKE would be needed to establish it.
     
     Note  that  the  distinctions  in network topology are more due to the
     actual network architecture than the selected IPsec mode, be it tunnel
     or transport.
     
     ICMPv6  messages can be classified according to whether they are meant
     for end-to-end communications or communications within a  link.  There
     are  also messages that we classify as 'any-to-end', which can be sent
     from any point within a path back to the source, typically to announce
     an error in processing the original packet.  For instance, the address
     resolution messages are solely for local communications  [1],  whereas
     the Destination Unreachable messages are any-to-end in nature. End-to-
     end and any-to-end messages MUST always  be  passed  through  tunnels.
     
     
     
     J. Arkko                                                      [Page 5]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     Local  messages may be passed through IPsec process under certain con¡
     ditions.
     
     5.3.  Role in Estaliblishing Communications
     
     ICMPv6 messages can also be classified according  to  their  role  for
     establishing  communications  between  two  nodes. For the purposes of
     this discussion, the relevant issue is whether  or  not  the  messages
     must  be  passed  through  before IKE can use UDP packets to negotiate
     SAs. For instance, address autoconfiguration, duplicate address detec¡
     tion,  and  address  resolution obviously MUST be completed before UDP
     packets can be passed.
     
     Neighbour reachability detection is also  capable  of  disrupting  IKE
     communications. The reference [1] states the following:
     
        In some cases (e.g., UDP-based protocols and routers
        forwarding packets to hosts) such reachability information
        may not be readily available from upper-layer protocols.
        When no hints are available and a node is sending packets
        to a neighbor, the node actively probes the neighbor using
        unicast Neighbor Solicitation messages to verify that the
        forward path is still working.
     
     This  means that unless the IKE implementation explicitly handles for¡
     ward progress notifications towards the IPv6 stack, the stack can  not
     know  about  the  reachability towards the other host. Since the hosts
     may be using tunnel mode and other address in the inner  packets  than
     the regular addresses on the hosts, the stack can not learn of forward
     progress through regular IPsec AH or ESP packets.
     
     Therefore, neighbour reachability MUST also be allowed to  work  inde¡
     pendent of IKE SA establishment.
     
     As IKE messages may contain certificates, it is quite possible that an
     MTU limit may be exceeded somewhere within the network.   If  this  is
     possible  in  a given network, the policies MUST allow ICMP Packet Too
     Big messages to be received. Note that  these  messages  may  well  be
     received  either  in  the  clear,  on  manually  configured SAs, or on
     dynamic SAs. If the router generating the Packet Too Big message  does
     not yet have an SA with the original host, it can initiate IKE negoti¡
     ations to create one. In case that this new negotiation fails  due  to
     reaching  another  MTU  limit, other routers may be involved along the
     way. But ultimately the process reaches the closest  router  to  which
     the MTU is known and will not cause any ICMP error messages.
     
     5.4.  Protecting the Infrastructure versus Communications
     
     IPsec  can  be  used  to  protect the end-to-end communications or the
     underlying control messages (such as ICMPv6). It can even be  used  to
     protect both. Since many of the control messages are sent to multicast
     addresses, if IPsec is used then manual SA configuration MUST be  per¡
     formed instead of IKE-based SA negotiation.
     
     
     
     
     J. Arkko                                                      [Page 6]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     As  we have talked about some messages in some situations having to be
     independent of IKE, it does not necessarily imply that  they  have  to
     passed through in the clear. Instead, systems MAY use manually config¡
     ured IPsec SAs to protect e.g. all ICMPv6  communications  within  one
     network.  (Note that setting these manual SAs up requires some care as
     discussed in [8].)
     
     A plausible security policy configuration could therefore be one where
     all ICMPv6 messages within the local network must be protected by man¡
     ual SAs, and all other communications must be protected by IKE-negoti¡
     ated SAs.
     
     6.  Analysis of the ICMPv6 Messages
     
     
     6.1.  Destination Unreachable
     
     The ICMPv6 type of this message is 1.
     
     This  message  is  always sent between unicast addresses [3]. It is an
     end-to-end message  Destination Unreachable is never a  relevant  mes¡
     sage  for  establishing  dynamic SAs, unless advanced failover schemes
     rely on the knowledge to quickly determine unreachable IKE peers.
     
     6.2.  Packet Too Big
     
     The ICMPv6 type of this message is 2.
     
     This message is also always sent between unicast addresses [3] even if
     might  be  sent as a response to a multicast message. It is an end-to-
     end message.
     
     Packet Too Big has, however, a role  in  establishing  communications.
     End-to-end communications, that is.  In order to pass through long IKE
     packets, Packet Too Big responses from the network MUST be considered.
     Therefore,  it  MUST be possible for policies to be configured so that
     such messages can be received.  Note that as dicussed previously,  the
     Packet Too Big messages themselves can be protected in various ways.
     
     6.3.  Time Exceeded
     
     The ICMPv6 type of this message is 3.
     
     This  message is also always sent between unicast addresses [3] and is
     an end-to-end message. Like Packet Too Big,  it  too  has  a  role  in
     establishing  end-to-end  communications  under certain special situa¡
     tions.
     
     6.4.  Parameter Problem
     
     The ICMPv6 type of this message is 4.
     
     This message is similar to Packet Too Big in the sense  that  it  uses
     only  unicast  messages  even  if  it could be sent as a response to a
     
     
     
     J. Arkko                                                      [Page 7]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     multicast packet. It's role is also end-to-end. While  in  theory  its
     role  in  establishing communications is similar to Packet Too Big and
     Time Exceeded, in practise it is hard to see the kind of IKE and  IPv6
     stack version problem that could result in this message being sent.
     
     6.5.  Echo Request
     
     The ICMPv6 type of this message is 128.
     
     Echo  Request  uses  unicast addresses as source addresses, but may be
     sent to any legal IPv6 address, even multicast and  anycast  addresses
     [3].  Echo Requests run end-to-end but never have a role in establish¡
     ing communications.
     
     6.6.  Echo Reply
     
     The ICMPv6 type of this message is 129.
     
     Echo Reply is similar to Echo Request in other respects, but uses only
     unicast addresses.
     
     6.7.  Redirect
     
     The ICMPv6 type of this message is 137.
     
     The  Redirect message is always sent between unicast addresses [1]. It
     is only used for local purposes, not for end-to-end communications. It
     isn't  strictly necessary in order to establish communications. Never¡
     theless, it can be viewed as a logical add-on to the Neighbour Discov¡
     ery  messages  such  as  Router  Advertisement,  and as such SHOULD be
     treated in a similar manner.
     
     6.8.  Router Solicitation
     
     The ICMPv6 type of this message is 133.
     
     This message uses either the unspecified address or an unicast address
     as  a source address. The destination address is typically a multicast
     address. This message is always used only local. Since  address  auto¡
     configuration  and  routing  depend  on the ability of the routers and
     address prefixes to be found, this message is required before any com¡
     munications  can  be  established.   Therefore,  this  message MUST be
     allowed to work independent of IKE SA establishment.
     
     6.9.  Router Advertisement
     
     The ICMPv6 type of this message is 134.
     
     This message has always a unicast source address, but the  destination
     address  can  be  either  a  unicast  or a multicast address. Like the
     solicitation message, the advertisement is also link  local  only  and
     required  for establishing any communications. Therefore, this message
     MUST be allowed to work independent of IKE SA establishment.
     
     
     
     
     J. Arkko                                                      [Page 8]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     6.10.  Neighbour Solicitation
     
     The ICMPv6 type of this message is 135.
     
     The source address of this message is either a unicast address or  (if
     Duplicate  Address  Detection  is in progress) the unspecified address
     [1, 3].  The  destination  is  either  a  multicast  address,  unicast
     address,  or an anycast address. Neighbour Solicitation and Advertise¡
     ment messages are used for multiple purposes:  address  autoconfigura¡
     tion,  duplicate address detection, and reachability detection. In all
     these roles they act only  locally  on  the  link,  and  getting  them
     through  is  required  before  any  communications can be established.
     Therefore, this message MUST be allowed to work independent of IKE  SA
     establishment.
     
     6.11.  Neighbour Advertisement
     
     The ICMPv6 type of this message is 136.
     
     The  source address of this message is a unicast address, and the des¡
     tination is either a unicast or a multicast address. Like the  solica¡
     tion  message,  this message is link local only and is required before
     any communications can be established.  Therefore, this  message  MUST
     be allowed to work independent of IKE SA establishment.
     
     6.12.  Router Renumbering
     
     The  ICMPv6  type  of this message is 138.  The code is 0 for a Router
     Renumbering Command, 1 for a Router Renumbering Result, and 255 for  a
     Sequence Number Reset [4].
     
     These  messages  are sent from a unicast address to either a multicast
     or a unicast address. The message are not solely link local, they  are
     used  for end-to-end purposes such as having a central management sta¡
     tion renumber all routers in a corporate network. As a result  of  the
     RR  procedure,  automatically configured addresses and prefixes may be
     changed. However, it is expected that a transition period exists where
     both  addresses are still acceptable, making it possible to still pro¡
     ceed with IKE negotiations to create SAs for the RR procedure.  We can
     therefore  assume  that the procedure MAY use manual or dynamic SAs as
     desired by the system administrators.
     
     7.  Summary
     
     Based on the above, the ICMPv6 messages can be classified as follows:
     +-------------------+------------+-----------------+
     | MESSAGE           | ROLE       | USE IKE?        |
     +-------------------+------------+-----------------+
     | Dest Unreachable  | Any-to-End | MAY(1,2)        |
     +-------------------+------------+-----------------+
     | Packet Too Big    | Any-to-End | MAY(1,3)        |
     +-------------------+------------+-----------------+
     | Time Exceeded     | Any-to-End | MAY(1,3)        |
     +-------------------+------------+-----------------+
     
     
     
     J. Arkko                                                      [Page 9]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     | Parameter Problem | End-to-End | MAY(4)          |
     +-------------------+------------+-----------------+
     | Echo Request      | End-to-End | MAY(4)          |
     +-------------------+------------+-----------------+
     | Echo Reply        | End-to-End | MAY(4)          |
     +-------------------+------------+-----------------+
     | Redirect          | Link Local | SHOULD NOT(5)   |
     +-------------------+------------+-----------------+
     | Router Solicit    | Link Local | MUST NOT(6)     |
     +-------------------+------------+-----------------+
     | Router Advert     | Link Local | MUST NOT(6)     |
     +-------------------+------------+-----------------+
     | Neighbour Solicit | Link Local | MUST NOT(6)     |
     +-------------------+------------+-----------------+
     | Neighbour Advert  | Link Local | MUST NOT(6)     |
     +-------------------+------------+-----------------+
     | Router Renumbering| End-to-End | MAY(4)          |
     +-------------------+------------+-----------------+
     
     
     Explanations:
     
     (1) These error messages have an end-to-end nature but may  be  gener¡
     ated by intermediate routers as well.
     
     (2)  This  MAY  have  to be considered by implementations that wish to
     base failover decisions on the Unreachable message.
     
     (3) These messages have an impact on the success of IKE messages  e.g.
     when  certificates are passed in IKE packets.  It MUST be possible for
     policies to be configured so that these messages can be received while
     the IKE negotiations are still ongoing. Different security policy con¡
     figurations MUST be supported, including trusting  cleartext  messages
     or  protecting  the  messages from intermediate nodes using other, new
     dynamic SA negotiations.
     
     (4) These messages MAY be treated using regular IPsec and/or IKE  pro¡
     cessing.
     
     (5)  This  message SHOULD NOT use IKE in order to make their treatment
     equal with the rest of the link local messages, but in theory Redirect
     MAY be handled differently, e.g. using dynamic SAs.
     
     (6) These messages MUST NOT use dynamic SAs.
     
     These  policy  rules  may be expressed in various ways on a particular
     host or a router. It is necessary to use the ICMPv6 type in making the
     policy  decisions.  As  [4] states, "This is consistent with, although
     not mentioned by, the Security Architecture specification".  Only  the
     following requirement for all implementations is stated here. Products
     that provide hardcoded security policies for  ICMPv6  messages  SHOULD
     enable  user  specified  policies to be expressed at a higher priority
     level so that a possibility is still retained for modifying the  rules
     due to e.g. interoperability problems.
     
     
     
     J. Arkko                                                     [Page 10]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     8.  Further Work
     
     This  draft discusses the use of IPsec on ICMPv6 messages on a princi¡
     ple level. It does not take a stand on how the policies are expressed,
     for  instance  whether IPsec products need to have hardcoded rules for
     handling these messages, or  whether  the  Security  Policy  Databases
     should  be  general enough to make it possible to express the policies
     in them even for the ICMPv6 messages.
     
     This draft does not address stateful address autoconfiguration aspects
     of IPv6.
     
     This  draft  does not address the use of dynamic security associations
     in the context of multicast traffic. Now that the multicast  key  man¡
     agement working group has been founded in the IETF, a question eventu¡
     ally arises whether or not the results of that work  can  be  used  to
     protect the infrastructure multicast messages.
     
     9.  Acknowledgements
     
     The  author  would  like  to  thank Pekka Nikander, Markku Rossi, Tero
     Kivinen, and Michael Richardson for interesting  discussions  in  this
     problem space.
     
     10.  References
     
     [1] T. Narten, E. Nordmark, W. Simpson "Neighbor Discovery for IP Ver¡
     sion 6 (IPv6)" RFC 2461, IBM, Sun Microsystems,  Daydreamer,  December
     1998.
     
     [2]  S.  Thomson, T. Narten "IPv6 Stateless Address Autoconfiguration"
     RFC 2462, Bellcore, IBM, December 1998.
     
     [3] A. Conta, S. Deering "Internet Control Message  Protocol  (ICMPv6)
     for  the  Internet  Protocol Version 6 (IPv6) Specification" RFC 2463,
     Lucent, Cisco Systems, December 1998.
     
     [4] M. Crawford "Router Renumbering  for  IPv6"  RFC  2894,  Fermilab,
     August 2000.
     
     [5] J. McCann, S. Deering, J. Mogul "Path MTU Discovery for IP version
     6" RFC 1981, Digital Equipment Corporation, Xerox PARC, August 1996.
     
     [6]  S. Kent, R. Atkinson "Security Architecture for the Internet Pro¡
     tocol" RFC 2401, BBN Corp, @Home Network, November 1998.
     
     [7]   D.  Harkins and D. Carrel "The Internet Key Exchange", RFC 2409,
     Cisco Systems, November 1998.
     
     [8]  J. Arkko, P. Nikander, T. Kivinen, M. Rossi "Manual SA Configura¡
     tion    for    IPv6    Link   Local   Messages",   draft-arkko-manual-
     icmpv6-sas-00.txt, Work In Progress, IETF, February 2001.
     
     
     
     
     
     J. Arkko                                                     [Page 11]


     INTERNET-DRAFT              ICMPv6 and IKE                23 June 2002
     
     
     11.  Author's Address
     
     Jari Arkko
     Oy LM Ericsson Ab
     02420 Jorvas
     Finland
     
     Phone: +358 40 5079256 (hand)
            +358 9 2992480 (desk)
     EMail: Jari.Arkko@ericsson.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     J. Arkko                                                     [Page 12]
     

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/