INTERNET-DRAFT                                             Erik Nordmark
Oct 27, 2003                                            Sun Microsystems

                 Multihoming using 64-bit Crypto-based IDs


   Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted 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 can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet Draft expires April 27, 2004.


   This document outlines a potential solution to IPv6 multihoming in
   order to stimulate discussion.  This proposal is a middle ground
   between the NOID and CB128 proposals.

   This proposed solution relies on verification the crypto-based
   identifier properties (using public-key crypto during uncommon
   operations), while allowing locator rewriting by (border) routers,
   with no per-packet overhead.  The solution does have something which
   could be viewed as a "stack name" type of identifier, but this isn't
   exposed to upper layer protocols.  Instead it ensures that all upper
   layer protocols can operate unmodified in a multihomed setting while
   still seeing a stable IPv6 address, even though the address

draft-nordmark-multi6-cb64-00.txt                               [Page 1]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

   internally consists of 64-bits worth of subnet locator plus 64-bits
   of crypto-based identifier.

   This solution (and this draft) is remarkably similar to draft-
   nordmark-multi6-noid-00.txt; only issues related to prevention of
   redirection attacks differ.

   DISCLAIMER: This work has been discussed in a design team.  The
   design team is still exploring multiple approaches and this is an
   attempt to capture one such approach on paper.  Because of this and
   due to lack of time to review the document one can not say that this
   is a product of the DT; errors and confusions should be attributed to
   the scribe and not to the DT.

draft-nordmark-multi6-cb64-00.txt                               [Page 2]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


      1.  INTRODUCTION.............................................    4
         1.1.  Non-Goals...........................................    4
         1.2.  Assumptions.........................................    5

      2.  TERMINOLOGY..............................................    5
         2.1.  Notational Conventions..............................    6

      3.  PROTOCOL OVERVIEW........................................    7
         3.1.  Host-Pair Context...................................   10
         3.2.  Message Formats.....................................   12

      4.  PROTOCOL WALKTHROUGH.....................................   14
         4.1.  Initial Context Establishment.......................   14
         4.2.  Locator Change......................................   17
         4.3.  Handling Locator Failures...........................   18
         4.4.  Locator Set Changes.................................   18
         4.5.  Preventing Premeditated Redirection Attacks.........   19

      5.  HANDLING STATE LOSS......................................   20

      6.  ENCODING BITS IN THE IPv6 HEADER?........................   22

      7.  COMPATIBILITY WITH STANDARD IPv6.........................   23

      8.  APPLICATION USAGE OF IDENTIFIERS.........................   24

      9.  CHECKSUM ISSUES..........................................   24

      10.  IMPLICATIONS FOR PACKET FILTERING.......................   25

      11.  IPSEC INTERACTIONS......................................   26

      12.  SECURITY CONSIDERATIONS.................................   26

      13.  DESIGN ALTERNATIVES.....................................   27

      14.  OPEN ISSUES.............................................   28
         14.1.  Initiator Confusion vs. "Virtual Hosting"..........   28
         14.2.  Using larger context tags..........................   29

      15.  COMPARISON WITH NOID AND CB128..........................   30

      16.  ACKNOWLEDGEMENTS........................................   30

      17.  IPR CONSIDERATIONS......................................   31

draft-nordmark-multi6-cb64-00.txt                               [Page 3]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      18.  REFERENCES..............................................   31
         18.1.  Normative References...............................   31
         18.2.  Informative References.............................   31


   The goal of the IPv6 multihoming work is to allow a site to take
   advantage of multiple attachments to the global Internet without
   having a specific entry for the site visible in the global routing
   table.  Specifically, a solution should allow users to use multiple
   attachments in parallel, or to switch between these attachment points
   dynamically in the case of failures, without an impact on the upper
   layer protocols.

   This proposed solution uses crypto-based identifiers [CBID]
   properties to perform enough validation to prevent redirection

   The goals for this proposed solution is to:

    o Have no impact on upper layer protocols in general and on
      transport protocols in particular.

    o Address the security threats in [M6SEC].

    o Allow routers rewriting the (source) locators as a means of
      quickly detecting which locator is likely to work for return

    o No per-packet overhead.

    o No extra roundtrip for setup.

    o Take advantage of multiple locators/addresses for load spreading.

1.1.  Non-Goals

   The assumption is that the problem we are trying to solve is site
   multihoming, with the ability to have the set of site locator
   prefixes change over time due to site renumbering.  Further, we
   assume that such changes to the set of locator prefixes can be

draft-nordmark-multi6-cb64-00.txt                               [Page 4]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

   relatively slow and managed; slow enough to allow updates to the DNS
   to propagate.  This proposal does not attempt to solve, perhaps
   related, problems such as host multihoming or host mobility.

   This proposal also does not try to provide an IP identifier to the
   upper layer protocols - even though it uses a 64-bit CBID internally
   to prevent redirection attacks.  An IP identifier name space would be
   useful to ULPs and applications, especially if the management burden
   for such a name space was zero and there was an efficient yet secure
   mechanism to map from identifiers to locators, but exposing such a
   name space isn't necessary to solve the problem at hand.

1.2.  Assumptions

   The main technical assumptions this proposal makes is that using
   public key signatures during the more uncommon operations would
   provide acceptable performance.  The proposal doesn't require such
   operations during normal communication; only when a locator changes
   for a host will it need to be verified before return traffic will be
   sent to that locator, or when two hosts claim to use the same

   Another assumption is that where DNS is already used (normally at the
   initiating end of communication) it is acceptable to lookup a
   multihoming capability "flag" in the DNS in addition to the current
   AAAA lookup (of the addresses/locators).


      upper layer protocol (ULP)
                  - a protocol layer immediately above IP.  Examples are
                    transport protocols such as TCP and UDP, control
                    protocols such as ICMP, routing protocols such as
                    OSPF, and internet or lower-layer protocols being
                    "tunneled" over (i.e., encapsulated in) IP such as
                    IPX, AppleTalk, or IP itself.

      interface   - a node's attachment to a link.

      address     - an IP layer name that contains both topological
                    significance and acts as a unique identifier for an
                    interface.  128 bits.

      locator     - an IP layer topological name for an interface or a
                    set of interfaces.  128 bits.  The locators are

draft-nordmark-multi6-cb64-00.txt                               [Page 5]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

                    carried in the IP address fields as the packets
                    traverse the network.

      identifier  - an IP layer identifier for an IP layer endpoint
                    (stack name in [NSRG]).  In this proposal a 64-bit
                    CBID i.e. a hash of a public key.

      Application identifier (AID)
                  - an IP locator which has been selected for
                    communication with a peer to be used by the upper
                    layer protocol.  128 bits.  This is used for
                    pseudo-header checksum computation and connection
                    identification in the ULP.  Different sets of
                    communication to a host (e.g., different
                    connections) might use different AIDs in order to
                    enable load spreading.  The AIDs contain a 64-bit
                    CBID in the low-order bits.

      address field
                  - the source and destination address fields in the
                    IPv6 header.  As IPv6 is currently specified this
                    fields carry "addresses".  If identifiers and
                    locators are separated these fields will contain

      FQDN        - Fully Qualified Domain Name

2.1.  Notational Conventions

   A, B, and C are hosts.  X is a potentially malicious host.

   FQDN(A) is the domain name for A.

   ID(A) is the 64 bit CBID for A.

   Ls(A) is the locator set for A, which consists of L1(A), L2(A), ...
   Ln(A).  Each Lk(A) contains ID(A) in the low-order bits.  The high-
   order 64 bits of a locator are sometimes referred to as the "subnet
   locator".  (The protocol doesn't prevent a single host having
   multiple identities, but that can be viewed multiple entities A, B,
   etc existing on the same host.)

   AID(A) is an application ID for A.  In this proposal, AID(A) is
   always one member of Ls(A).

draft-nordmark-multi6-cb64-00.txt                               [Page 6]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


   In order to prevent redirection attacks this protocol relies on the
   ability to verify (using public key crypto as in [CBID]) that the
   entity requesting redirection indeed holds the private key where the
   hash of the corresponding public key hashes to the ID itself.

   DNS is used to lookup an indication of the multihoming capability of
   a host, in addition to being used to lookup the AAAA records
   containing the locators.  The details of this is TBD but a simple
   example would be to introduce a new M6 RR type in the DNS which has
   no RDATA; thus the mere existence of such a record at a FQDN would
   imply that the host supports the M6 protocol.

   In essence this proposal is the same as [NOID] except that the CBID
   property is used instead of DNS for verification.

                            | Transport Protocols |

             ------ ------- -------------- -------------
             | AH | | ESP | | Frag/reass | | Dest opts |
             ------ ------- -------------- -------------

                            | M6 shim layer |

                                | IP |

   Figure 1: Protocol stack

   The proposal uses an M6 shim layer between IP and the ULPs as shown
   in figure 1, in order to provide ULP independence.  Conceptually the
   M6 shim layer behaves as if it is an extension header, which would be
   ordered immediately after any hop-by-hop options in the packet.
   However, the amount of data that needs to be carried in an actual M6
   extension header is close to zero.  By using some encoding of the
   nexthdr value it is possible to carry the common protocols/extension
   headers without making the packets larger.  The nexthdr encodings are
   discussed later in this document.  We refer to packets that use this
   encoding to indicate to the receiver that M6 processing should be
   applied as "M6 packets" (analogous to "ESP packets" or "TCP

draft-nordmark-multi6-cb64-00.txt                               [Page 7]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

   Layering AH and ESP above the M6 shim means that IPsec can be made to
   be unaware of locator changes the same way that transport protocols
   can be unaware.  Thus the IPsec security associations remain stable
   even though the locators are changing.  Layering the fragmentation
   header above the M6 shim makes reassembly robust in the case that
   there is broken multi-path routing which results in using different
   paths, hence potentially different source locators, for different

   The proposal uses router rewriting of (source) locators as one way to
   determine which is the preferred (or only working) locator to use for
   return traffic.  But not all packets can have their locators
   rewritten.  In addition to existing IPv6 packets, the packets
   exchanged before M6 host-pair context state is established at the
   receiver can not have their locators rewritten.  Thus a simple
   mechanism is needed to indicate to the routers on the path whether or
   not it is ok to rewrite the locators in the packet.  Conceptually
   this is a single bit in the IPv6 header (we call it the "rewrite ok"
   bit) but there is no spare bit available.  Later in the document we
   show how we solve this by allocating a range of next header values to
   denote this semantic bit.

   Applications and upper layer protocols use AIDs which the M6 layer
   will map to/from different locators.  The M6 layer maintains state,
   called host-pair context, in order to perform this mapping.  The
   mapping is performed consistently at the sender and the receiver,
   thus from the perspective of the upper layer protocols packets appear
   to be sent using AIDs from end to end, even though the packets travel
   through the network containing locators in the IP address fields, and
   even though those locators might be rewritten in flight.

draft-nordmark-multi6-cb64-00.txt                               [Page 8]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      ----------------------           ----------------------
      | Sender A           |           | Receiver B         |
      |                    |           |                    |
      |      ULP           |           |      ULP           |
      |       | src AID(A) |           |       ^            |
      |       | dst AID(B) |           |       | src AID(A) |
      |       v            |           |       | dst AID(B) |
      |       M6           |           |       M6           |
      |       | src L1(A)  |           |       ^            |
      |       | dst L1(B)  |           |       | src L2(A)  |
      |       v            |           |       | dst L1(B)  |
      |       IP           |           |       IP           |
      ----------------------           ----------------------
              |                                ^
              -- cloud with some routers -------
                                          src L2(A) [Rewritten]
                                          dst L1(B)
   Figure 2: Mapping with router rewriting of locators.

   The result of this consistent mapping is that there is no impact on
   the ULPs.  In particular, there is no impact on pseudo-header
   checksums and connection identification.

   Conceptually one could view this approach as if both AIDs and
   locators being present in every packet, but with a header compression
   mechanism applied that removes the need for the AIDs once the state
   has been established.  As we will see below the flowid will be used
   akin to a "compression tag" i.e., to indicate the correct context to
   use for decompression.

   The need for some "compression tag" is because the desire to allow
   load spreading and handle site renumbering.  Without those desires it
   could have been possible to e.g. designate one fixed locator as the
   AID for a host and storing that in the DNS.  But instead different
   connections between two hosts are allowed to use different AIDs and
   on reception of a M6 packet the correct AIDs must be inserted into
   the IP address fields before passing the packet to the ULP.  The
   flowid serves as a convenient "compression tag" without increasing
   the packet size, and this usage doesn't conflict with other flowid

   In addition to the zero overhead data messages, there are six
   different M6 message types introduced (which could be defined as new
   ICMPv6 messages).  Three types are used to perform a 3-way handshake
   to create state at both endpoints without creating state on the first
   received packet (which would introduce a memory consumption DoS
   attack), 2 are used to do a challenge request/response exchange when
   a new locator is introduced, and finally a single message type to

draft-nordmark-multi6-cb64-00.txt                               [Page 9]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

   signal that state has been lost.  The six message types are called:

    o Context request message; first message of the 3-way context
      establishment.  Sent by the responder when a data packet arrives
      with no context state.  An ULP packet can be piggybacked on this

    o Context response message; second message of the 3-way context
      establishment.  Sent in response to a context request.  An ULP
      packet can be piggybacked on this message.

    o Context confirm message; third message of the 3-way context
      establishment.  Sent in response to a context response.  An ULP
      packet can be piggybacked on this message.

    o Challenge request message; first message of the 2-way challenge.

    o Challenge response message; second message of the 2-way challenge.

    o Unknown context message; error which is sent when no state is

   Similar to MAST [MAST] the 3-way state creation exchange can be
   performed asynchronously with data packets flowing between the two
   hosts; until context state has been established at both ends the
   packets would flow without allowing router rewriting of locators and
   without the ability for the hosts to switch locators.

   Once the 3-way state creation exchange has completed there is host-
   pair context state at both hosts.  At that point in time the hosts
   will use the challenge/response mechanism each time a new and
   unverified peer locator appears.

3.1.  Host-Pair Context

   The host-pair context is established on the initiator of
   communication based on information learned from the DNS (either by
   starting with a FQDN or with an IP address -> FQDN lookup).  The
   responder will establish some initial state using the context
   creation 3-way handshake.  Both hosts later update the peer locators
   based on the source locator in received packets after having verified
   the new locator using a challenge exchange.

   The context state contains the following information:

    - the peer locator which the ULP uses as ID; AID(peer)

draft-nordmark-multi6-cb64-00.txt                              [Page 10]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

    - the local locator which the ULP uses as ID; AID(local)

    - the set of peer locators; Ls(peer).  Each locator contains the
      same 64-bit ID.

    - for each peer locator, a bit whether it has been verified (by
      performing a challenge/response.  TBD: do this even for the
      original locators that where learned from the DNS?)

    - the preferred peer locator - used as destination; Lp(peer)

    - the set of local locators; Ls(local).  Each locator contains the
      same 64-bit ID.

    - the preferred local locator - used as source; Lp(local)

    - the flowid used to transmit packets; F(local)

    - the flowid to expect in receive packets; F(peer)

    - State about peer locators that are in the process of being

   This state is accessed differently in the transmit and receive paths.
   In the transmit path when the ULP passes down a packet the key to the
   context state is the tuple <AID(local), AID(peer)>; this key must
   identify at most one state record.  In the receive path it is the
   F(peer) plus the 64-bit peer and local IDs that are used to identify
   at most one state record.  Thus the sender allocated flowid is part
   of the key for looking up the context state at the receiver.

   These uniqueness requirements imposed by those lookup keys uniquely
   identifying one state record means that one can not create multiple
   records (e.g. with different locator sets) that have the same AID
   pair, and the peer must pick a flowid so that host-pair contexts
   which have the same 64-bit ID pair but a different AID pair gets a
   different F(local).

   Note that the flowids could be selected to be finer grain than above;
   for instance having a different flowid for each connection.  Doing so
   requires some efficient data structure organization at the receiver
   to map multiple F(peer) to the same context.

draft-nordmark-multi6-cb64-00.txt                              [Page 11]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

3.2.  Message Formats

   These message formats are largely the same as in [CB128] but the
   context request, response, and confirm are sent in the opposite

   The base M6 header is an ICMPv6 header as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        |      Type     |    Code       |          Checksum             |
        |                  <code specific fields>                       |

   ICMPv6 Fields:

                     TBD [IANA]

                     8-bit field.  The type of M6 message.  The M6
                     header carries 6 different types of messages:

                      o Context request message; first message of the
                        3-way context establishment.  An ULP packet can
                        be piggybacked on this message.

                      o Context response message; second message of the
                        3-way context establishment.  An ULP packet can
                        be piggybacked on this message.

                      o Context confirm message; third message of the
                        3-way context establishment.  An ULP packet can
                        be piggybacked on this message.

                      o Challenge request message; first message of the
                        2-way challenge.

                      o Challenge response message; second message of
                        the 2-way challenge.

                      o Unknown context message; error which is sent
                        when no context state found.

      Checksum       The ICMPv6 checksum.

draft-nordmark-multi6-cb64-00.txt                              [Page 12]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      Future versions of this protocol may define message codes.
      Receivers MUST silently ignore?  Reject?  [TBD] any message code
      they do not recognize.

      This drafts doesn't contain actual message layout for code
      specific part.  However, the content of these messages is
      specified below.

      The Context request message contains:

       - Sender Nonce

       - Sender AID

       - Receiver AID

       - Sender flowid (20 bits)

      The Context response message contains:

       - Receiver Nonce (copied from Sender Nonce in request)

       - Context state consisting of: the two AIDs, the two flowids, and
         the initial locators

       - A timestamp or nonce (for sender's benefit)

       - A hash over the context state and timestamp (to prevent

      The Context confirm message contains:

       - The context state, timestamp/nonce, and hash copied from the
         context response.

      The Challenge request message contains:

       - Sender generated nonce/timestamp

       - The two AIDs

       - The 20-bit flowid from the received data message

       - The source locator from the received data message

      The Challenge response message contains:

       - The nonce/timestamp from the challenge request

draft-nordmark-multi6-cb64-00.txt                              [Page 13]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

       - The 20-bit flowid (from the challenge request)

       - The above locator

       - A hash value (H2) which proves that the sender knows the both
         flowids.  This allows the receiver of the response to avoid
         verifying the PK signature generated by a host which can't be
         the original peer.

       - The public key of the sender.

       - The public key signature of all of the above fields.

      The Unknown context message contains:

       - The 20-bit flowid from the triggering packet.


4.1.  Initial Context Establishment

      Here is the sequence of events when A starts talking to B:

       1.  A looks up FQDN(B) in the DNS which returns Ls(B) plus "B is
           M6 capable".  The host verifies that all the locators contain
           the same 64-bit ID.  One locator is selected to be returned
           to the application: AID(B) = L1(B).  The others are installed
           in the M6 layer on the host with AID(B) being the key to find
           that state.  To make sure that the lookup from AID(B) returns
           a single state record one has to catch the case when an
           attempt is to create different context state for the same
           AID; different locators sets.

           To make sure that the lookup from AID(B) returns a single
           state record in the M6 layer there has to be a check if there
           is already a record for that 64-bit ID with a different Ls.
           One could envision sending a PK challenge to the locators to
           resolve such a conflict, or doing a reverse lookup of AID(B)
           to get and verify the FQDN.  See section 14.1 for more

draft-nordmark-multi6-cb64-00.txt                              [Page 14]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

       2.  The ULP creates "connection" state between AID(A)=L1(A) and
           AID(B) and sends the first packet.  L1(A) was picked using
           regular source address selection mechanisms.

       3.  The M6 layer matches on AID(B) and finds the proto-context
           state (setup in step #1) with Ls(B).  The existence of that
           state will make the M6 layer send a M6 packet.  The M6 layer
           selects a flowid F(A) consistent with the uniqueness
           requirements in section 3.1 (which ensure that the receiver
           will map to the correct AID pair).

       4.  The packet (TCP SYN or whatever) is sent to peer with
           locators L1(A) to L1(B) i.e., the same as the AIDs.  Since B
           doesn't have any context state yet, A will not set the
           "rewrite ok" bit in the header.

       5.  Host B receives packet and sees it is a "M6 packet".  Passes
           the packet to the M6 shim layer.  The M6 layer tries to match
           a context state using the flowid and the bottom 64 bits of
           the address fields.  Since this is the first packet in the
           communication between A and B no such state is found.  The M6
           layer can't create state on the first packet, but since the
           rewrite bit is not set in the packet it can pass the packet
           unmodified to the ULP.  The ULP sees a packet identified by
           AID(A), AID(B).

           The M6 layer initiates a state creation 3-way exchange by
           forming a context request message.  The same technique as in
           [MIPv6] can be used to securely do this exchange without any
           local state; use a local key which is never shared with
           anybody and pass the context state, a timestamp, and the
           keyed hash of the state+timestamp in the context request
           packet.  When the state, timestamp, and keyed hash value is
           returned in the context response message, the hash is used to
           verify that the state hasn't been modified.

           The 3-way exchange is done asynchronously with ULP packets,
           but it is possible (assuming the MTU allows) to piggyback ULP
           packets on this exchange.

           Should ULP packets be passed down to the M6 layer on B before
           the context response message has been received there will be
           no context state and no state installed as a result of a DNS
           lookup (unlike on A).  This will indicate that the ULP
           message should be passed as-is (not as an M6 message) to the
           peer.  Thus during the 3-way exchange packets can flow in
           both directions using the original locators=AIDs.  (However,
           this has some interactions with the suggestions in section

draft-nordmark-multi6-cb64-00.txt                              [Page 15]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


       6.  Host A receives the context request message.  It verifies
           that the message is related to something it sent by looking
           at the locators (should match the AIDs) and the flowid it
           sent (which is in the state in the context request message).

           If a ULP packet was piggybacked A will pass that to the ULP.

           Then A sends a content response which has the same
           information as the context request plus a nonce/timestamp
           that A selected.

       7.  Host B receives the context response message.  It verifies
           that the hash of the state is correct using its per-host key.
           At this point in time it knows that A is at least not just
           blasting out packets as a DoS - A is also responding to
           context request messages.  Thus B goes ahead and allocates
           state at this point in time using the state that is in the
           context response message.

           The M6 layer selects a flowid F(B) consistent with the
           uniqueness requirements in section 3.1 (which ensure that the
           receiver will map to the correct AID pair).  At this point in
           time B has enough information to handle M6 packets from A.
           It has also the state (F(B) mainly) necessary send data
           packets to A with "rewrite ok" set.  Thus B sends a context
           confirm message to A which contains A's nonce/timestamp from
           the context response and F(B).

           If a ULP packet was piggybacked on the context response B
           will pass that to the ULP.

           Note that B doesn't perform a public key challenge/response
           for the original AIDs since ULPs and applications don't seem
           assume that level of strength in the peer address/identity.
           If there will be such applications the applications could
           perhaps trigger such additional verification.

       8.  Host A receives the context confirm message, verifies the
           nonce/timestamp, and records F(peer) from the packet.

           If a ULP packet was piggybacked on the context confirm A will
           pass that to the ULP.

           At this point in time A knows that B has context state, thus
           it can start sending packets with "rewrite ok" set.

draft-nordmark-multi6-cb64-00.txt                              [Page 16]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

4.2.  Locator Change

      This is the sequence of events when B receives a packet with a
      previously unused source locator for A, for instance L2(A).

       1.  Host B receives M6 packet with source L2(A) and destination
           L1(B).  Looks up context state using the flowid and the
           bottom 64-bits of the locators.  If this lookup succeeds then
           the locator is acceptable for incoming packets (even though
           it might not have been verified for use as return traffic)
           and the packet is rewritten to contain the AIDs from the
           context state and passed to the ULP.

           If the source locator is in Ls(peer) and already verified
           then the preferred return locator (Lp(peer)) is updated to
           use it for return packets.

           If the source locator is previously unknown then it is added
           to the context state as a Ls(peer) awaiting verification and
           a Challenge Request packet is generated.  The challenge
           request includes a nonce generated by B, F(A) (that was
           received in the packet from the unknown locator), the
           identifiers and the previously unknown peer locator.

           The challenge response needs to complete before using the
           locator as a destination in order to prevent redirection
           attacks and 3rd party DoS attacks.

       2.  Host A receives the challenge request packet.  Verifies that
           it has state for those AIDs with the F(A) it received on the
           request.  It computes the hash H2 to show to B that it knows
           the flowids for both directions by computing
           H2 = SHA1(nonce from request, F(A), F(B), AID(A), AID(B))

           It includes its public key (the one whose hash is ID(A)) and
           signs the whole challenge response using its private key.

       3.  Host B receives the challenge response packet.  It finds the
           context state using F(A).  It verifies the nonce against what
           it used for sending the challenge request.  It verifies H2.
           (Only devices on the path between A and B during the context
           establishment knows both F(A) and F(B), thus this check
           limits DoS attacks based on forcing PK signature verification
           to attackers on the path.)  Then it verifies that the hash of
           the public key equals ID(A), and finally the public key
           signature using that public key.

draft-nordmark-multi6-cb64-00.txt                              [Page 17]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

4.3.  Handling Locator Failures

      Should not all locators be working when the communication is
      initiated some extra complexity arises, because the ULP has
      already been told which AIDs to use.  If the locators that where
      selected to be AIDs are not working it isn't possible to send a
      zero-overhead initial packet from A to B.  Instead both the AIDs
      and the working locators need to be conveyed.  This could be done
      by either reusing IP-in-IP encapsulating or defining another M6
      message type which carries both.  Details TBD.

      After context setup the sender can use retransmit hints from the
      ULP to get the M6 layer to try a different verified locator.

      If one outbound path from the site fails and the border routers
      rewrite source locators then the peer in another site will see
      packets with the working source locators.  Once that has locator
      been verified, the return path will switch to use the working
      locator.  As long as both ends are transmitting packets this will
      relatively quickly switch to working locators except when both
      hosts experience a failing locator at the same time.

      Without locator rewriting one would need to add some notification
      e.g., by defining a new bit in the router advertisement prefixes
      (IMHO this is semantically different than the preferred vs.
      deprecated stuff), but we also need some mechanism to carry this
      info from the border routers to the routers on each subnet.

4.4.  Locator Set Changes

      Should the set of locators change after the context has been
      established the ability to learn and verify new peer locators will
      handle this fine.

      The DNS only needs to be updated with new locators in order to
      allow new communication to be established.

      When a host sees (based on router advertisements [DISCOVERY]) that
      one of its locators has become deprecated and it has additional
      locators that are still preferred, it is recommended that the host
      start using the preferred locator(s) with the contexts that have
      already been established.  This ensures that should the deprecated
      locator become invalid the peers have already verified other
      locator(s) for the host.

draft-nordmark-multi6-cb64-00.txt                              [Page 18]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

4.5.  Preventing Premeditated Redirection Attacks

      The threats document [M6SEC] talks of premeditated redirection
      attacks that is where an attacker claims to be a host before the
      real host appears.  While an attacker can only use a given AID if
      it is on the path (so that return packets arrive at the attacker),
      an attacker can use a 64-bit ID combined with any 64-bit subnet
      locator.  This is of concern since on the receive side the context
      state is identified by the 64-bit ID pair.

      Thus this proposal is potentially subject to this threat because
      for performance reasons there is no public-key challenge when the
      context state is initially established.

      The following sequence shows how such a redirection attack is
      detected when X pretends to be ID(A):

       1.  Host X with creates locator L1(X) using its "own" subnet
           locator and ID(A) as the bottom 64 bits.  X selects F(X) to
           communicate with B and sends a M6 data message to B.

       2.  The context request, response and confirm messages are
           exchanged between B and X resulting on B selecting F(B) for
           communicating with X (which B believes has identifier ID(A)).

       3.  X and B happily communicate without B performing any higher-
           level, such as IKE/IPsec, identity check on its peer.

       4.  Host A tries to communicate with B.  It sends an M6 packet
           with ID(A) and F(A) to B.

    5.  Host B receives this M6 packet and discovers it already has
           context state for ID(A).  B doesn't do anything different
           than if there was no context state - the difference in
           processing happens when the context confirm is received -
           except that any piggybacked ULP packet is not passed to the
           ULP.  Thus, as in section 4.1, a flowid is selected and the
           context request is sent, which makes A send back a context

       6.  Host B receives the context response and verifies it the same
           way as in section 4.1.  Then it looks if there is already a
           context for ID(A) and finds the context which contains F(X)
           and L1(X).

           The existence of this "old" context could be due to multiple

draft-nordmark-multi6-cb64-00.txt                              [Page 19]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

            - The peer lost state while B retained the context state.
              In this case one would expect that the old context has not
              been used to receive packets for some time. (Having a
              protocol constant denoting the minimum time after sending
              a packet that state can be lost and later recreated would
              be helpful here.)  In this case it would also be common
              that the source address of the packet would fall in the
              locator set for the old context.  But it isn't impossible
              that a peer state loss and using a different locator
              happens at the same time.

            - The old host was performing a premediated redirection

            - The new host is attempting a redirection attack.

           In all cases the approach consists of finishing the state
           setup by sending a context confirm message to A, and then
           sending a challenge to both the "new" A and the "old" A.  But
           depending on the time since packets where last received from
           the "old" A the order can be different.  The first peer
           locator which responds with a valid challenge response will
           "win" and the other context state will be deleted.

      TBD: The above has DoS concerns in terms of verifying the
      challenge response.  Having both ends remove the context state at
      about the same time would be beneficial since it would reduce the
      frequency of this happening in the absence of attacks, thus it
      would be more realistic to apply resource limits for this type of


      The protocol needs to handle two forms of state loss:

       - a peer loosing all state,

       - the M6 layer garbage collecting state too early due to not
         being aware of what all ULPs do.

      The first case is the already existing case of a host crashing and
      "rebooting" and as a result loosing transport and application
      state.  In this case there are some added complications from the

draft-nordmark-multi6-cb64-00.txt                              [Page 20]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      M6 layer since a peer will continue to send packets assuming the
      context still exists and due to the loss of state on the receiver
      it isn't even able to pass the correct packet up to the ULP (e.g.,
      to be able to get TCP to generate a reset packet) since it doesn't
      know what AIDs to use when replacing the locators.

      The second case is a bit more subtle.  Ideally an implementation
      shouldn't discard the context state when there is some ULP that
      still depends on this state.  While this might be possible for
      some implementations with a fixed set of applications, it doesn't
      appear to be possible for implementations which provide the socket
      API; there can be things like user-level "connections" on top of
      UDP as well as application layer "session" above TCP which retain
      the identifiers from some previous communication and expect to use
      those identifiers at a later date.  But the M6 layer has no
      ability to be aware of this.

      Thus an implementation shouldn't discard context state when it
      knows it has ULP connection state (which can be checked in e.g.,
      Unix for TCP), or when there is active communication (UDP packets
      being sent to AID(A) recently), but when there is an infrequently
      communicating user-level "connection" over UDP or "session" over
      TCP the context state might be garbage collected even though it

      For instance, if B crashes and rebooted and A retransmits a packet
      with flowid, L3(B), L2(A) then what is needed is a packet to L1(B)
      from L1(A) passed to the ULP so that the ULP can send an error
      (such as a TCP reset).  But B has no matching state thus it needs
      to send an Unknown context error back.  (Should the packet not
      have "rewrite ok" set host B can pass it to the ULP since it knows
      that such packets contain locators that are AIDs.  But once the
      context has been established the peer is likely to send all
      packets with "rewrite ok" set.)

      If host B instead only lost (garbage collected too early) the M6
      context state things are a bit more complicated for packets passed
      down from the ULP.  Without without any context state the M6 layer
      on B can not determine whether packets to AID(A) coming from the
      ULP are destinated to a standard IPv6 host or a host which
      supports multihoming.  B can determine this by performing some
      packet exchange with A to ask it whether it supports multihoming.

      If B is communicating with both standard IPv6 hosts and hosts
      which support multihoming then it has to avoid doing these peer
      queries for every packet sent to a standard IPv6 host.
      Implementation tricks (such as "has this socket ever used M6" flag
      at the socket layer, and "negative caching" of peers that do not

draft-nordmark-multi6-cb64-00.txt                              [Page 21]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      support M6) can be useful to avoid performance overhead.

      Potentially this state recovery can result in A having two
      contexts for B; one with the old flowid and one with a new flowid.
      This must be avoided so that packets to B only use the flowid that
      is known to B.  Specifying this is for further study.


      The idea is to pick extra IP protocol values for common
      combinations, and have a designated protocol value to capture the
      uncommon IP protocols which might use M6.  The uncommon IP
      protocol values would require an additional extension header when
      used over M6.

      We pick two unused ranges of IP protocol values with 8 numbers
      each (assuming we will not need more than 7 common transport
      protocols).  The ranges start at P1 and P2, respectively:
      P1      TCP over M6 - rewrite ok
      P1+1    UDP over M6 - rewrite ok
      P1+2    SCTP over M6 - rewrite ok
      P1+3    RDDP over M6 - rewrite ok
      P1+4    ESP over M6 - rewrite ok
      P1+7    escape - any protocol over M6 - rewrite ok
              In this case we spend another 8 bytes (minimum IPv6
              extension header size due to alignment rule) to carry the
              actual IP protocol.  This causes some mtu concerns for those
              protocols, but they aren't very likely to be used with M6?

      P2      TCP over M6 - no rewrite
      P2+1    UDP over M6 - no rewrite
      P2+2    SCTP over M6 - no rewrite
      P2+3    RDDP over M6 - no rewrite
      P2+4    ESP over M6 - no rewrite
      P2+7    escape - any protocol over M6 - no rewrite
              In this case we spend another 8 bytes (minimum IPv6
              extension header size due to alignment rule) to carry the
              actual IP protocol.  This causes some mtu concerns for those
              protocols, but they aren't very likely to be used with M6?

      Thus a router would check if the protocol is in the P1 range and

draft-nordmark-multi6-cb64-00.txt                              [Page 22]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      if so, it can rewrite the locator(s).  A host would check a
      received packet against both P1 and P2 ranges and if so pass it to
      the M6 shim layer.

      Some possible alternatives to the above encoding is to:

       - use some combination of the universal/local and group bit in
         the interface id of the source address to indicate "rewrite

       - steal the ECN bits from the traffic class before ECN becomes a
         proposed standard?  Don't think this will be popular!

       - always have a shim header - adds 8 bytes overhead per packet.


      A host can easily implement M6 in a way that interoperates with
      current IPv6 as follows.

      When the DNS lookup routines do not find an M6 record for the peer
      they will return the AAAA resource record set to the application;
      those would be the IPv6 addresses.  When the ULP passes down these
      addresses the M6 layer will not have any state generated by the
      DNS lookup code, thus no M6 processing will take place on the
      sender.  (Note that this relates to the M6 layer state recovery in
      section 5.)

      The receive side handles both standard IPv6 and M6 since it
      demultiplexing on whether a packet is an M6 packet.

draft-nordmark-multi6-cb64-00.txt                              [Page 23]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


      The upper level protocols will operate on AIDs which are mere
      locators.  Thus as long as a site hasn't renumbered the AID can be
      used to either send packets to the host, or (e.g. if that locator
      isn't working), it is possible for an application to do a reverse
      lookup plus forward lookup of the AID to get the set of locators
      for the peer.

      Once a site has been renumbered the AIDs which contain the old
      prefix will no longer be useful.  Hence applications must try to
      honor the DNS TTL somehow.

      Applications which use to map the peer's IP address to a domain
      name today perform a reverse lookup in the DNS (e.g., using the
      getnameinfo() API).  This proposal doesn't add or subtract to the
      benefits of performing such reverse lookups.


      The IPv6 header does not have a checksum field; the IPv6 address
      fields are assumed to be protected by the ULP pseudo-header
      checksum.  The general approach of an M6 shim which replaces
      locators with identifiers (where only the identifiers are covered
      by the ULP checksum) raises the potential issue of robustly
      handling bit errors in the address fields.

      With the definition of the M6 shim there can be undetectable bit
      errors in the flowid field or the nexthdr field which might
      adversely affect the operation of the protocol.  And since the
      AIDs are what's covered by the ULP's pseudo-header checksum the
      locators in the address fields are without checksum protection.
      An undetected bit error in the source locator would look like an
      unverified source locator to the receiver.  Thus the packet would
      (after replacing locators with identifiers based on the context)
      be passed to the ULP and a challenge response exchange be
      triggered.  In the case of a bit error in the locator this
      challenge isn't likely to receive a response; and if there is a
      response by someone it wouldn't be from the actual peer thus the
      verification would fail.  Thus such an undetected bit error is

      Except for the obscure case when Ls(A) contains multiple verified

draft-nordmark-multi6-cb64-00.txt                              [Page 24]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      locators, one or more of those are not working, and the bit error
      causes L1(A) to be replaced by L2(A).  That would make the return
      traffic go to L2(A), but that might be a non-functioning locator.
      In this case the mistake will be corrected when a subsequent
      packet is received from A.

      An undetected bit error in the destination address field is also
      harmless; it might cause misdelivery of the packet to a host which
      has no context but the reception of the resulting Unknown context
      error message will show that it arrives from the incorrect locator
      thus it will be ignored.

      An undetected bit error in the IPv6 next header field can
      potentially make a M6 packet appear as a non-M6 packet and vice
      versa.  This isn't any different than undetected bit errors in
      IPv6 next header field without multihoming support.

      An undetected bit error in the flowid in a data message could have
      two possible effects: not finding any context state, or finding
      the incorrect context state.  In the first case the Unknown
      context error message would be dropped by the peer since the
      flowid included in the error message doesn't match the flowid that
      was originally sent.  In the second case this will result in a
      packet with incorrect identifiers being delivered to the ULP which
      most like will drop it due to ULP checksums not matching.


      Ingress filtering should be replaced by locator rewrite when the
      "rewrite ok" bit is set.

      Locator rewriting (when the bit is set) can be applied at places
      where ingress filtering isn't currently performed (e.g., due to
      multihoming issues).

      Firewall filtering potentially require modifications to be aware
      of M6.  All the packets contain locator thus a firewall would need
      to be aware of the context state to let the correct packets
      through.  Such firewalls could optionally perform their own
      verification by issuing challenge request messages (the protocol
      doesn't explicitly allow for this; they would have to pretend
      being the actual endpoint sending the challenge).

draft-nordmark-multi6-cb64-00.txt                              [Page 25]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


      As specified all of ESP, AH, and key management is layered above
      the M6 layer.  Thus they benefit from the stable identifiers
      provided above the M6 layer.  This means the IPsec security
      associations are unaffected by switching locators.

      The alternative would be to layer M6 above IPsec, but that doesn't
      seem to provide any benefits.  Since we want to allow routers
      performing locator rewriting it wouldn't be possible to take
      advantage of for instance AH to protect the integrity of the IP


      This analysis is far from complete.  Early analysis indicates this
      addresses the issues in [M6SEC].

      Just as in today's Internet hosts on the path can inject bogus
      packets; in this proposal they need to extract the flowids from
      the packets in order to do this which wouldn't be hard.  Packet
      injection from off-path places becomes harder since it requires
      guessing the 20 bit flowid together with the 64-bit ID pair.

      Hosts on the path can also launch PK signature verification DoS
      attacks against either end since they can observe the flowids from
      the establishment and therefor compute the H2 hash in the
      challenge response packet.  This would force the endpoint to run
      the signature verification algorithm which is expensive.  If we
      don't expect the locator sets to be very dynamic one could
      restrict the rate at which such verification takes place, at least
      after the first few locators have been verified for a peer.

      The initial setup of a host-pair context does not perform any
      verification using public key crypto, but this does not seem to
      make the result less secure than today's Internet.  Applications
      which do not perform access control based on it's notion of the
      peer wouldn't care about the strength of the peer's identifier.
      And applications which perform strict access control hopefully do
      this using strong crypto (IPsec, TLS, etc) today and would
      continue to do so.  That leaves applications which perform the
      questionable practise of merely verifying the forward plus reverse
      lookups in the DNS and then using the IP address (or resulting

draft-nordmark-multi6-cb64-00.txt                              [Page 26]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      FQDN) for access control discussions.  As discussed in section 6
      the application's lookup of locator->FQDN->ID and verifying that
      the identifier matches provides about the same strength. [TBD are
      we really sure?]

      The CBIDs are only statistically unique.  But 64 bit identifiers
      seems large enough to make collisions unlikely enough to keep the
      protocol simple.  (If not one could envision complications like
      making the protocol capable of detecting collisions by storing the
      public key in the context state and seeing if a host claims to use
      the same ID but has a different public key.)  While at about 4
      Billion hosts in the Internet there is approximately a 50%
      probability that there exists 2 hosts with the same 64-bit
      identifier this has no effect on the protocol per see.  It is not
      until a single host has that order of magnitude of context state
      records that it could get confused due to collisions.


      Use an actual extension header for M6 and use a context tag in
      that header instead of using the flowid.  This would make the
      packets 8 bytes larger since the minimum extension header size is
      8 bytes due to the alignment rules for extension headers in IPv6.

      Make the flowid allocation be done by the receiver of the flowid
      (as is done for the context tags in [CB128]) instead of by the
      sender as in this proposal.

      It is possible to use these mechanisms together with the
      structured 64/80 bit identifiers suggested in [CRYPTOID].

draft-nordmark-multi6-cb64-00.txt                              [Page 27]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


      Some protocol complexity is added by not performing a mutual
      public-key challenge immediately when a context is created.  At
      the expensive of a performance hit one could simplify the protocol
      to always to these challenges.

      Is it possible to facilitate transition to M6 using some "M6
      proxy" at site boundaries until all important hosts in a site have
      been upgraded to support M6?  Would would be the properties of
      such a proxy?  Would it place any additional requirements on the
      protocol itself?

      One of the issues with FQDNs mapping to AAAA records is that in
      some cases multiple AAAA records mean a multihomed host and in
      other cases it means multiple hosts providing the same service.
      If we need to introduce a new RR type for M6, would it be useful
      to try to make this host/service distinction more clear at the
      same time?  An example solution would be that the M6 record would
      by its existence indicate the M6 capability, and its RDATA would
      contain a list of host names which would be used to resolve the
      AAAA records for each host implementing the service.  Another
      possibility related to this proposal would be to use the fact that
      a given host would have the same 64-bit ID in its locators, thus
      after retrieving the locators for a FQDN it is possible to group
      those into "host sets" by comparing the bottom 64-bits (assuming
      the node is M6 capable).  This grouping could be performed in
      routines like getaddrinfo() transparent to the applications.

      Would destination locator rewriting be a useful way for the
      routing system to pass some information to the host?  Or is source
      locator rewriting sufficient?

      The mechanisms allow adding locators to a locator set but there is
      currently no mechanism for removing a locator (e.g., when a host
      renumbers).  Does it make sense to add such a mechanism?

      The responder only discovers the peer's locators once they are
      used as sources in packets.  Would it make sense to allow the
      initiator to pass a list of its locators to the responder?  (They
      would still need to be verified before use to prevent 3rd party
      DoS attacks [M6SEC]).

14.1.  Initiator Confusion vs. "Virtual Hosting"

      When A wants to communicate with host B and host X at the same

draft-nordmark-multi6-cb64-00.txt                              [Page 28]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      time there can be some confusion since the DNS could return the
      same identifier for B and X while returning different locator
      sets.  For example,

      The lookup of FQDN(B) returns Ls(B) where each locator has a 64-
      bit ID(B)

      The lookup of FQDN(X) returns Ls(X) where each locator has a 64-
      bit ID(B)

      The result is that connections that could be intended to go to B
      and to X would both end up with different AIDs ID at the ULP, but
      the multihoming shim layer would have two separate locator sets
      associated with ID(B).  Thus at a minimum when the second of the
      two communications starts there has to be some way to resolve this

      If multiple FQDNs map to the same host, which is common in virtual
      hosting using IPv4 today, and the locator set is being modified
      for that host then this could be quite normal; looking up would provide the ID of the peer and a perhaps staler
      set of locators for the ID than looking up

      Is it reasonable to assume when there is some overlap between
      Ls(B) and Ls(X) above that this is a normal condition?  Should one
      form the intersection of Ls(B) and Ls(X) and use that for the
      existing context state?  Or at least purge unverified peer
      locators, those from which the host hasn't seen a challenge
      response, that are not in the intersection from the locator set

      Section 4.1 suggests using a challenge request/response exchange
      when the second lookup takes place.  Should the challenge be
      performed with the newer or older locator sets?  What are the DoS
      issues in performing such a challenge?

14.2.  Using larger context tags

      The 128-bit identifier proposal [CB128] uses a larger context tag
      as part of the context setup than is used in the data packets to
      identify the context.  This larger context tag is useful to
      prevent off-path attackers from launching "verify signature" DoS
      attacks; a more inexpensive check can be performed to verify that
      the peer knows the full context tag.

      That approach could easily be adopted to this proposal as well
      with the flowid carrying the low-order 20 bits of e.g. a 64 bit

draft-nordmark-multi6-cb64-00.txt                              [Page 29]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      context tag.  Would this be beneficial?


      This approach represents at some level a middle ground between
      [NOID] and [CB128] in that:

       - Not using DNS for verification as in [NOID] but using the CBID
         property plus public key crypto as in [CB128].  Once DNSsec is
         used there are less public key operations to verify using CBID
         than for all the delegations in the tree for a
         previously unknown peer locator.

       - Like [NOID] there are no extra bytes added to the packets.

       - Like [NOID] the AIDs are useful in referrals.

       - Uses similar messages as in [CB128] but the context
         request/response/confirm is sent in the reverse direction with
         the context request being sent by the responder (in [CB128] the
         context request is sent by the initiator).


      This document is the result of discussions in a MULTI6 design team
      but is not the "product" of that design team.  The scribe wishes
      to acknowledge the contributions of (in alphabetical order):
      Iljitsch van Beijnum, Brian Carpenter, Tony Li, Mike O'Dell, and
      Pekka Savola.

      The idea to allow locator rewriting by routers was first presented
      by Mike O'Dell [ODELL96].  The techniques for avoiding state DoS
      attacks on the first packet are patterned after [MIPv6].

draft-nordmark-multi6-cb64-00.txt                              [Page 30]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003


      When IP addresses that have a hash of a public key in the low
      order 64 bits were discussed in the Mobile IP WG and in the SEND
      WG two vendors asserted IPR.  It is not known to the author
      whether such IPR claims would apply to this specification as well.


18.1.  Normative References

        [M6SEC] Nordmark, E., and T. Li, "Threats relating to IPv6
                multihoming solutions", draft-nordmark-multi6-threats-
                00.txt, October 2003.

        [CBID] G. Montenegro and C. Castelluccia, "Statistically Unique
                and Cryptographically Verifiable Identifiers and
                Addresses", ISOC NDSS02, San Diego, February 2002.

        [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6
                Addressing Architecture", RFC 3513, April 2003.

        [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol,
                Version 6 (IPv6) Specification", RFC 2461.

18.2.  Informative References

        [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from
                the NSRG", draft-irtf-nsrg-report-09.txt (work in
                progress), March 2003.

        [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support
                in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in
                progress), June 2003.

        [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses",
                draft-aura-mipv6-bu-attacks-01 (work in progress), March

        [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and
                E. Nordmark, "Mobile IP version 6 Route Optimization
                Security Design Background", draft-nikander-mobileip-

draft-nordmark-multi6-cb64-00.txt                              [Page 31]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

                v6-ro-sec-01 (work in progress), June 2003.

        [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture
                for IPv6", draft-odell-8+8-00.txt, October 1996,

                (MAST): AN EXTENDED PROPOSAL", draft-crocker-mast-
                protocol-01.txt, October, 2003.

                draft-van-beijnum-multi6-cryptoid-00.txt, (unpublished)

        [CB128] E. Nordmark, "Strong Identity Multihoming using 128 bit
                Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim-
                00.txt, October 2003.

        [NOID] E. Nordmark, "Multihoming without IP Identifiers",
                draft-nordmark-multi6-noid-00.txt, October 2003.

        [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor
                Discovery for IP Version 6 (IPv6)", RFC 2461, December

        [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet
                Protocol".  RFC 2401, November 1998.

        [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 2402,
                November 1998.

        [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload
                (ESP)", RFC 2406, November 1998.


        Erik Nordmark
        Sun Microsystems, Inc.
        17 Network Circle
        Mountain View, CA

        phone: +1 650 786 2921
        fax:   +1 650 786 5896

   Full Copyright Statement

      Copyright (C) The Internet Society (2003).  All Rights Reserved.

draft-nordmark-multi6-cb64-00.txt                              [Page 32]

INTERNET-DRAFT Multihoming using 64-bit Crypto-based IDs    Oct 27, 2003

      This document and translations of it may be copied and furnished to
      others, and derivative works that comment on or otherwise explain it
      or assist in its implementation may be prepared, copied, published
      and distributed, in whole or in part, without restriction of any
      kind, provided that the above copyright notice and this paragraph are
      included on all such copies and derivative works.  However, this
      document itself may not be modified in any way, such as by removing
      the copyright notice or references to the Internet Society or other
      Internet organizations, except as needed for the purpose of
      developing Internet standards in which case the procedures for
      copyrights defined in the Internet Standards process must be
      followed, or as required to translate it into languages other than

      The limited permissions granted above are perpetual and will not be
      revoked by the Internet Society or its successors or assignees.

      This document and the information contained herein is provided on an


      Funding for the RFC Editor function is currently provided by the
      Internet Society.

draft-nordmark-multi6-cb64-00.txt                              [Page 33]