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

Versions: 00 01 02

INTERNET-DRAFT                                             Erik Nordmark
July 7, 2004                                            Sun Microsystems

                    Multihoming without IP Identifiers

                    <draft-nordmark-multi6-noid-02.txt>

   Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet Draft expires January 7, 2005.


   Abstract

   This document outlines a potential solution to IPv6 multihoming in
   order to stimulate discussion.

   This proposed solution relies on verification using the existing DNS
   to prevent redirection attacks, while allowing locator rewriting by
   (border) routers, with no per-packet overhead.  The solution does not
   introduce a "stack name" type of identifier, instead it ensures that
   all upper layer protocols can operate unmodified in a multihomed
   setting while still seeing a stable IPv6 address.







draft-nordmark-multi6-noid-02.txt                               [Page 1]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Contents

      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.  DNS Usage and Dependencies..........................   11
         3.2.  Host-Pair Context...................................   12
         3.3.  Message Formats.....................................   13
            3.3.1.  Context Initiator (INIT) Message Format........   14
            3.3.2.  Context Check (CC) Message Format..............   15
            3.3.3.  Context Check Reply (CCR) Message Format.......   16
            3.3.4.  Context Confirm (CONF) Message Format..........   16
            3.3.5.  Update Request (UR) Message Format.............   16
            3.3.6.  Update Acknowledgement (UA) Message Format.....   17
            3.3.7.  Unknown Context (UC) Message Format............   17

      4.  PROTOCOL WALKTHROUGH.....................................   18
         4.1.  Initial Context Establishment.......................   18
         4.2.  Locator Change......................................   21
         4.3.  Concurrent Context Establishment....................   22
            4.3.1.  Crossing INIT messages.........................   22
            4.3.2.  Sending INIT after sending CC..................   23
         4.4.  Handling Locator Failures...........................   23
         4.5.  Locator Set Changes.................................   24
         4.6.  Preventing Premeditated Redirection Attacks.........   26

      5.  HANDLING STATE LOSS......................................   26
         5.1.  State Loss and Packets from the Peer................   27
         5.2.  State Loss and Packets from the ULP.................   28

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

      7.  PROTOCOL PROCESSING......................................   30
         7.1.  State Machine.......................................   30
         7.2.  Sending INIT messages...............................   30
         7.3.  Receiving INIT messages.............................   31
         7.4.  Receiving CC messages...............................   32
         7.5.  Receiving CCR messages..............................   33
         7.6.  Receiving CONF messages.............................   34
         7.7.  Sending Update Request messages.....................   35
         7.8.  Receiving Update Request messages...................   35
         7.9.  Receiving Update Acknowledgement messages...........   36
         7.10.  Retransmission.....................................   36



draft-nordmark-multi6-noid-02.txt                               [Page 2]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


         7.11.  Receiving Data Packets.............................   36
         7.12.  Receiving Unknown Context messages.................   37
         7.13.  DNS Verification and Hosts without a FQDN..........   38
         7.14.  Birthday Counter...................................   40

      8.  COMPATIBILITY WITH STANDARD IPv6.........................   40

      9.  APPLICATION USAGE OF IDENTIFIERS.........................   41

      10.  CHECKSUM ISSUES.........................................   42

      11.  IMPLICATIONS FOR PACKET FILTERING.......................   43

      12.  IPSEC INTERACTIONS......................................   43

      13.  SECURITY CONSIDERATIONS.................................   44

      14.  PRIVACY CONSIDERATIONS..................................   45

      15.  DESIGN ALTERNATIVES.....................................   45
         15.1.  Avoid introduction of M6 DNS Resource Record type..   45
         15.2.  Extension header instead of using flow label.......   46
         15.3.  Explicit close exchange............................   47

      16.  OPEN ISSUES.............................................   47
         16.1.  Renumbering Considerations.........................   48
         16.2.  Initiator Confusion vs. "Virtual Hosting"..........   48

      17.  ACKNOWLEDGEMENTS........................................   49

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

      19.  CHANGE LOG..............................................   51

      APPENDIX A: CONTEXT CLOSE PROTOCOL...........................   52

      AUTHORS' ADDRESSES...........................................   56












draft-nordmark-multi6-noid-02.txt                               [Page 3]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


1.  INTRODUCTION

   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 existing DNS mechanisms to perform enough
   validation to prevent redirection attacks.

   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 [M6THREATS].

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

    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
   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.  Even
   though such a concept 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, such a name space isn't necessary (and
   furthermore doesn't seem to help) when using the DNS to verify the
   locator relationships.



draft-nordmark-multi6-noid-02.txt                               [Page 4]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


1.2.  Assumptions

   The main technical assumptions this proposal makes is that the DNS
   infrastructure can be used for verification of the relationship
   between locators on both the initiator of communication and the
   responding peer.  In particular, it assumes that getting DNS reverse
   tree (ip6.arpa) populated for the hosts that wish to take advantage
   of multihoming, will not be a significant problem.

   This version of the document further relaxes this constraint so that
   if two communication hosts are in separate multihomed sites, if only
   one of them has correct information in the forward plus reverse DNS,
   the communication between them can benefit from the multiple locators
   of that host.  However, without loss of security it isn't possible to
   benefit from the multiple locators of a host with no DNS information
   (or incorrect/missing forward and reverse DNS information).

2.  TERMINOLOGY

      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
                    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]).  The transport endpoint is a
                    function of the transport protocol and would
                    typically include the IP identifier plus a port
                    number.  NOTE: This proposal does not contain any IP
                    layer identifiers.

      Application identifier (AID)
                  - an IP locator which has been selected for
                    communication with a peer to be used by the upper



draft-nordmark-multi6-noid-02.txt                               [Page 5]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


                    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.

      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
                    locators.

      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.

   Lsl(A) is the "local" locator set for A, that is, the set of locators
   that A itself knows it has.  This set expresses which locators should
   be acceptable to receive packets sent by A.

   Lsr(A) is the "remote" locator set for A, that is, the set of
   locators of A that its peer found in the DNS.  Normally Lsl(A) and
   Lsr(A) are the same, but due to DNS updates, DNS load balancing, or
   misconfiguration they might differ.

   Ls(A) is the locator set for A, which consists of L1(A), L2(A), ...
   Ln(A).  For robustness Ls(A) is computed as the intersection of
   Lsl(A) and Lsr(A) by both A and its peer.

   Lsv(A) is the verified locator set for A.  This is the subset of
   Ls(A) which has been verified with both forward and reverse DNS
   lookups to be a set corresponding to a single FQDN.  This set
   expresses which locators are safe to use as destinations when sending
   packets to A.

   AID(A) is an application ID for A.  In this proposal, AID(A) is
   always one member of A's locator set.






draft-nordmark-multi6-noid-02.txt                               [Page 6]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


3.  PROTOCOL OVERVIEW

   In order to prevent redirection attacks this protocol relies on the
   DNS (for the hosts which want to take advantage of themselves having
   multiple locators) being maintained with consistent forward and
   reverse information.  This allows any host, given one locator, to
   determine the corresponding FQDN and the set of locators for the
   host.  Once those lookups have been performed, and the original
   locator is indeed part of the set, the host can happily allow any of
   those locators to be used without being subject to redirection
   attacks.  Keeping the FQDN around allows the solution to handle
   graceful renumbering by being able to redo the DNS lookups (e.g.,
   based on the TTL on the resource records).

   DNS is also used to provide an indication of multihoming capability
   of a host.  The details of this is TBD but a simple example would be
   to introduce a new M6 Resource Record 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.  See Section 15.1 for an
   alternative approach that doesn't need a new RR type.

                            -----------------------
                            | 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 associated with 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



draft-nordmark-multi6-noid-02.txt                               [Page 7]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   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 packets").

   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
   fragments.  Thus, effectively the M6 shim layer is placed between the
   IP endpoint sublayer, which handles fragmentation, reassembly, and
   IPsec, and the IP routing sublayer, which on a host selects which
   default router to use etc.

   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-noid-02.txt                               [Page 8]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


      ----------------------           ----------------------
      | 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 are 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 flow label
   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 flow
   label serves as a convenient "compression tag" without increasing the
   packet size, and this usage doesn't conflict with other flow label
   usage.

   In addition to the zero overhead data messages, there are seven
   different M6 message types introduced (which are defined as new
   ICMPv6 messages).  Four types are used to perform a 4-way handshake
   to create state at both endpoints without creating state on the first
   received packet (which would introduce a memory consumption DoS
   attack), and two types are used to update the set of locators used
   for the context, and finally a single message type to signal that



draft-nordmark-multi6-noid-02.txt                               [Page 9]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   state has been lost.  The seven message types are called:

    o Context Initiator message (INIT); first message of the 4-way
      context establishment.  Sent by the initiator when there is a
      desire to create a host-pair context for future locator agility.
      Normally sent when a data packet is passed down to IP from the ULP
      when there is no context state.  An ULP packet can be piggybacked
      on this message.

    o Context Check message (CC); second message of the 4-way context
      establishment.  Sent in response to a INIT message.  An ULP packet
      can be piggybacked on this message.

    o Context Check Reply message (CCR); third message of the 4-way
      context establishment.  Sent in response to a CC message.  An ULP
      packet can be piggybacked on this message.

    o Context Confirm message (CONF); Last message in the context
      establishment exchange; can be sent in response to a CCR or an
      INIT message.  Carries the responders flow label as well as any
      initial reductions in the locator set to the initiator.

    o Update Request message (UR); sent to update the local and remote
      locator sets.  An ULP packet can be piggybacked on this message.

    o Update Acknowledgement message (UA); sent to acknowledge an Update
      Request message.  An ULP packet can be piggybacked on this
      message.

    o Unknown Context message (UC); error which is sent when no state is
      found.

   Similar to MAST [MAST] the above 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 4-way state creation exchange has completed there is host-
   pair context state at both hosts, and both ends know a set of
   locators for the peer that are acceptable as the source in received
   packets.  At that point in time the responder (which didn't use DNS
   before the setup) can asynchronously start verifying additional
   locators using the DNS.  Once a peer locator has been verified it
   will be a candidate destination locator including the ability to
   dynamically switch to using the last received source locator (that is
   already verified) as the destination locator for return traffic.




draft-nordmark-multi6-noid-02.txt                              [Page 10]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


3.1.  DNS Usage and Dependencies

   For the protocol to be beneficial at least one of the communicating
   peers need to have a FQDN with consistent information in the forward
   and reverse trees.  The protocol uses the DNS at the end of the
   communication which normally does the DNS lookup, to not only find
   all the locators (as AAAA records) but also verify that these
   locators have reverse tree entries which point back at the FQDN.  The
   locators which do not point back to the FQDN will not be used as part
   of the locator set.  At the end of the communication which isn't
   required to do a DNS lookup today (the responder or server), this
   protocol, at some point after the context has been created message is
   received, will use the AID (normally the source address of the CCR
   packet) to first find the peer's FQDN, and them perform a forward
   lookup plus a reverse lookup of all the IPv6 locators, in order to
   verify that these locators are bound to the same FQDN.  As in the
   initiator case, the locators which do not verify using this method
   will be excluded from the locator set.  If no locators verify, then
   only the AID will be viewed as part of the locator set i.e., the
   protocol falls back to not providing any address agility.

   For the protocol to work well, both ends have to agree on each
   other's locator sets.  There are several reasons why a host's notion
   of its locators (or IPv4 addresses today) might be different than the
   set of locators present in the DNS for the host's FQDN
   (misconfiguration, DNS load balancing, in-progress DNS update, etc.)
   In order to cope with this, the two communicating hosts exchange each
   other's notion of each other's locators and form the intersection
   about what they know (about themselves as well as the peer) and what
   the peer knows (about themselves as well as the peer).  A property of
   this approach is that the locator set can never be larger than what
   is contained in the DNS, that is, a host can not use this to fool its
   peer to include additional locators as destinations, for instance for
   3rd party DoS attacks [M6THREATS].  This intersection should never be
   empty; an empty intersection is an indication that only the AID
   should be used.

   The hosts' locators might change over time due to renumbering.  At
   some point in time such a change will need to be reflected in the DNS
   in order for this protocol to be able to take advantage of any added
   locators.  The protocol uses the Update Request from the peer in
   combination with the DNS TTL as an indication when it makes sense to
   redo the DNS lookup of the peer's FQDN to detect changes in the
   locator set.







draft-nordmark-multi6-noid-02.txt                              [Page 11]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


3.2.  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 4-way handshake and later verify the peer's locators using
   the DNS.

   The context state contains the following information:

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

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

    - the set of peer locators determined from the DNS; Lsr(peer)

    - the set of peer locators communicated from the peer; Lsl(peer)

    - the set of peer locators; Ls(peer); intersection of the two above

    - for each peer locator, a bit whether it has been verified with the
      DNS (by doing reverse + forward lookup).  This can be viewed as
      forming a subset of Ls(peer) which we call Lsv(peer).

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

    - the set of local locators from local information; Lsl(local)

    - the set of local locators communicated from the peer, that is,
      which the peer found in the DNS; Lsr(local)

    - the set of local locators; Ls(local); intersection of the two
      above

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

    - the flow label allocated by the peer that is used to transmit
      packets; F(peer)

    - the flow label allocated by the host to expect in received
      packets; F(local)

    - the fully qualified domain name for the peer; FQDN(peer)

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




draft-nordmark-multi6-noid-02.txt                              [Page 12]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


    - Peer's birthday counter (a counter which increments by one each
      time the host reboots)

   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(local) flow label, which was allocated by the host itself, to
   uniquely identify a host-pair context.

   This limits a single host to maintaining about 1 Million host-pair
   contexts at a time; limited by the 20 bits of flow label.  A host
   that needs to support more than this limit, can do so by acting as
   multiple hosts from the perspective of this protocol.  This would
   entail having multiple FQDNs and each FQDN being associated with a
   different set of locators.  For instance, these different locators
   might use different interface identifiers.

   Note that the flow labels could be selected to be finer grain than
   above; for instance having a different flow label for each
   connection.  Doing so requires some efficient data structure
   organization at the receiver to map multiple F(local) to the same
   context and it might make the host run out of flow labels more
   easily.  However, the use of finer grain flow labels might be
   necessary when the flow labels are also used for QoS purposes in the
   routers. [RFC3697].


3.3.  Message Formats

   The set of messages and message sequences are similar to those in
   [HIP] and [WIMP] but the content is quite different, due to the
   different approach to security.

   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:

      Type
                     TBD [IANA]



draft-nordmark-multi6-noid-02.txt                              [Page 13]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


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

                      o Context Initiator message (INIT)

                      o Context Check message (CC)

                      o Context Check Reply message (CCR)

                      o Context Confirm message (CONF)

                      o Update Request message (UR)

                      o Update Acknowledgement message (UA)

                      o Unknown Context message (UC)

      Checksum       The ICMPv6 checksum.


   Future versions of this protocol may define new message codes.
   Receivers MUST silently ignore any message code they do not
   recognize.

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


3.3.1.  Context Initiator (INIT) Message Format

   The Context Initiator (INIT) message contains:

    - Initiator Nonce (used to match the CC message with the INIT
      message)

    - Initiator's AID

    - Responder's AID

    - Initiator's locally determined locators - Lsl(initiator)

    - Responder's remotely determined locators - Lsr(responder)

    - Initiator's flow label (20 bits)

    - Initiator's birthday counter (a counter which increments by one



draft-nordmark-multi6-noid-02.txt                              [Page 14]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


      each time the host reboots)



3.3.2.  Context Check (CC) Message Format

   When the responder receives an INIT message it does not allocate any
   state to prevent a class of DoS attacks.  Instead it sends a CC
   message, which effectively contains the state it would have
   allocated, and gets that information echoed back from the initiator
   in a CCR message.

   This context state consists of:

    - the two AIDs

    - the initiator's flow label (The responder's flow label is
      allocated when the CCR message is received.)

    - the initiator's locator set from the INIT message; Lsl(initiator)

    - the responder's locator set from the INIT message; Lsr(responder)

    - the responder's locator set as know to the responder itself;
      Lsl(responder).  The encoding [TBD] for the responder's locator
      set can use two bits per locator to indicate whether a locator is
      in Lsr(responder), Lsl(responder), or both.

    - The two birthday counters

    - The "ULP packet discarded" bit indicating that the ULP packet
      piggybacked on an INIT message was not delivered to the ULP.

   The Context Check (CC) message contains:

    - Initiator's Nonce (copied from the INIT message)

    - Context state as above

    - A timestamp or nonce (for the benefit of the responder matching
      the CCR message with the CC, as well as finding the per-host key
      which was used with the hash below)

    - A hash over the context state and timestamp/nonce (to prevent
      modification of the context state between sending it in the CC and
      receiving it back in the CCR message)





draft-nordmark-multi6-noid-02.txt                              [Page 15]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


3.3.3.  Context Check Reply (CCR) Message Format

   The Context Check Reply (CCR) message contains:

    - Initiator's nonce (to match the CONF message with the CCR)

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



3.3.4.  Context Confirm (CONF) Message Format

   In case the responder performs some verification of the peer's
   locator before it sends the CONF message, it can include the
   Lsr(initiator) in the CONF message.  If this verification is
   deferred, then a Update Request message will need to be sent later if
   the DNS verification indicates that some of the peer's locators
   should not be used because they are not in the DNS.

   The Context Confirm (CONF) message contains:

    - Initiator's AID

    - Responder's AID

    - Initiator's Nonce (copied from the INIT or CCR message which
      triggered sending the CONF message)

    - The responder's flow label

    - Responder's birthday counter. (Needed when the CONF is in response
      to an INIT message).

    - Optionally the initiator's remotely determined locators -
      Lsr(initiator)

    - Optionally the responder's locally determined locators -
      Lsl(responder).  (Needed when the CONF is in response to an INIT
      message).



3.3.5.  Update Request (UR) Message Format

   Either end of the communication can send an update request to inform
   the peer of a change in the locator sets.  This change could be any
   combination of additions to the sender's local locators, deletions to



draft-nordmark-multi6-noid-02.txt                              [Page 16]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   the sender's local locators, or changes to the peers locators that
   have been determined from the DNS.  The Update request message
   contains:

    - Request nonce/timestamp (used to match the UA with the UR)

    - Sender's and receiver's AID

    - Sender's and receiver's flow label for the context.

    - Sender's locally determined locators - Lsl(sender)

    - Receiver's remotely determined locators - Lsr(receiver)



3.3.6.  Update Acknowledgement (UA) Message Format

   The Update Acknowledgement message signals the receipt of the Update
   Request message and contains:

    - Nonce/timestamp copied from the UR message

    - Sender's and receiver's AID

    - Sender's and receiver's flow label for the context.

   If both ends need to update each other, each end has to send an
   Update Request message.


3.3.7.  Unknown Context (UC) Message Format

   The Unknown Context message contains:

    - The 20-bit flow label from the triggering packet.

    - The birthday counter (a counter which increments by one each time
      the host reboots)

    - The triggering packet starting with the IPv6 header (as much of
      the packet as fits in the MTU)









draft-nordmark-multi6-noid-02.txt                              [Page 17]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


4.  PROTOCOL WALKTHROUGH


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 Lsr(B) plus "B is M6
        capable".  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 it appears that one needs to do a reverse lookup of
        AID(B) to get the FQDN and check that the result is indeed
        FQDN(B).  Whether this check can be deferred until two entities
        try to use the same AID(B) for a different Ls is for further
        study.  Always doing the reverse lookup would be more
        predictable in any case.  See section 16.2 for some more
        discussion.

    2.  The ULP creates "connection" state between AID(A)=L1(A) and
        AID(B) and sends the first packet down to the IP/M6 shim layer
        on A.  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 Lsr(B).  The existence of that state
        means that it is possible to establish a host-pair context.
        Host A can decide when to establish the context; it can defer
        this and use regular IPv6 with the locators being the AIDs for
        some time.

        In this example A decides to immediately establish the host-pair
        context.  Thus it sends an INIT message with the ULP packet as
        part of the payload (if the MTU allows it to fit).

        Before sending the INIT message A selects a unique flow label
        F(local) for the new context and a nonce to match the CC with
        the INIT.

    4.  The packet (TCP SYN or whatever) is sent to the peer with
        locators L1(A) to L1(B) i.e., the same as the AIDs, piggybacked
        on the INIT message.  It is possible to set the "rewrite ok" bit
        in the header for the INIT header, but if the locators are
        rewritten the piggybacked packet can not be passed to the ULP.




draft-nordmark-multi6-noid-02.txt                              [Page 18]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


    5.  Host B receives the INIT message and passes the packet to the M6
        shim layer.  The M6 layer can't create state on the first
        packet, but if the packet was not rewritten in transit (that is,
        the AIDs are in the IP address fields) it can pass a piggybacked
        packet to the ULP.  The ULP sees a packet identified by AID(A),
        AID(B).  If the source address field is different than AID(A),
        then it is not safe to pass a piggybacked packet to the ULP
        since it could have been a case of spoofed AIDs.  In this case
        the CC message would indicate that the ULP packet was dropped so
        that the initiator can retransmit the ULP packet once the
        context has been established.

        The CC message is sent to the source locator of the INIT, even
        if the peer AID is different.

        The same technique as in [MIPv6] is used to securely do the
        CC/CCR exchange without any local state; use a local per-host
        key which is never shared with anybody and pass the context
        state, a timestamp, and the keyed hash of the state+timestamp in
        the CC message.  When the state, timestamp, and keyed hash value
        is returned in the CCR message, the hash is used to verify that
        the state hasn't been modified by the initiator.

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

        Should ULP packets be passed down to the M6 layer on B before
        the CCR 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 4-way
        exchange packets can flow in both directions using the original
        locators=AIDs.

    6.  Host A receives the CC message.  It verifies that the message is
        sent in response to the INIT by comparing the nonce.

        If a ULP packet was piggybacked A will pass that to the ULP.
        This can be done even if the locators where rewritten as long as
        the locators are part of the locator sets known to A.

        A forms the peer's locator set by taking the intersection of the
        Lsr it found in the DNS and the Lsl returned in the CC message.
        If the AID(peer) is not part of the Lsl(peer) it is an error and
        the AID is added to the locator set.  [The fact that the peer
        forgot to include the AID could be an indication that it is
        seriously confused.  The sender should ensure that the AID is



draft-nordmark-multi6-noid-02.txt                              [Page 19]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


        always included in the locator set when sending a locator set to
        a peer.]

        Then A sends a CCR message which has the same information as the
        CC message.  The message is sent to the source locator for the
        CC message.

    7.  Host B receives the CCR message.  It verifies that the hash of
        the state is correct using its per-host key and verifies that
        the timestamp is recent.  At this point in time it knows that A
        is at least not just blasting out INIT messages as a DoS - A is
        also responding to CC messages.  Thus B goes ahead and allocates
        state at this point in time using the state that is in the CCR
        message, and allocates a unique F(local) for this context.

        At this point in time B has enough information to handle M6
        packets from A, even though it hasn't yet verified the peer's
        locators in the DNS.

        If a ULP packet was piggybacked on the CCR message, B will pass
        that to the ULP.  This is done even if the IP address fields do
        not contain the AIDs, since having created the context state
        when the CCR was received, any "response" packets from the ULP
        will only be sent out to the verified peer locators for the
        context.  Hence there is no risk that this can be used for
        reflection attacks that bypass any deployed ingress filtering.

        In response to the CCR message, B sends a CONF message which
        includes the allocated F(B).  Also, if B has performed some DNS
        verification of the initiator's locators prior to sending the
        CONF message, and not all locators in Lsl(A) verified, then B
        includes the Lsr(A) in the CONF message.  If B later discovers
        that not all locators in Lsl(A) verified it will need to send an
        Update Request message.

        At this point in time B can start asynchronously and
        incrementally extracting and verifying Lsr(A) from the DNS.  The
        first lookup consists of finding L1(A)=AID(A) in ip6.arpa to get
        the FQDN and record it, and lookup the AAAA RR set for that FQDN
        to get Lsr(A).  Based on Lsr(A) and the Lsl(A) received in the
        CCR, B can form the intersection Ls(A).  If this intersection
        does not contain AID(A) it is an error and the AID is added to
        the locator set.

        Once Ls(A) is known, B can verify (also incrementally) that each
        member of Ls(A) is indeed assigned to A by doing a reverse
        lookup of each one (except L1(A) which was already looked up
        above).  Only when the reverse lookup of a given peer locator



draft-nordmark-multi6-noid-02.txt                              [Page 20]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


        has completed is that locator marked as verified.  This reverse
        lookup of each locator prevents 3rd party DoS attacks as
        described in [M6THREATS].

        At this point in time B knows that A has context state and it
        knows the flow label to use, thus it can start sending packets
        using the context.

    8.  Host A receives the CONF message, records F(peer) from the
        packet, and if present, extracts the Lsr(A) and forms the
        intersection Lsl(A) and Lsr(A) and uses this to update Ls(A).
        If the resulting Ls(A) does not contain AID(A) this is an error
        and the AID is added to the locator set.

        If a ULP packet was piggybacked on the CONF message, A will pass
        that to the ULP as long as the source locator of the CONF
        message was one of as part of the verified Ls(peer) locators.

        At this point in time A knows that B has context state and it
        knows the flow label to use, thus it can start sending packets
        using the context.


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).

   Host B receives M6 packet with source L2(A) and destination L1(B).
   Looks up context state using the flow label.  If this lookup succeeds
   and the source address field contains a locator which is in Lsl(B),
   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 L2(A) has not been verified then it would make sense for B to put
   that locator first in the list of asynchronous DNS verifications that
   are needed.  If/once L2(A) has been verified B can make it the
   preferred peer locator to use when sending packets to AID(A).

   The verification needs to complete before using the locator as a
   destination in order to prevent 3rd party DoS attacks [M6THREATS].

   If a host receives a packet with a known flow label but where the
   locators (source and/or destination) are not part of the locator
   sets, the packet is silently dropped as specified in more detail in
   Section 7.11.



draft-nordmark-multi6-noid-02.txt                              [Page 21]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


4.3.  Concurrent Context Establishment

   Should both A and B attempt to contact each other at about the same
   time using the same AIDs for each other, the message flow is
   different than above.  However, if different AIDs are used this would
   result in two completely independent contexts between the two hosts
   following the basic content establishment above.

   If B tries to contact A after B has received the CCR message, then B
   will discover the context state for AID(A) and not trigger creating a
   new context.  But since B does not create any state when receiving
   the INIT, it is possible for B to send a INIT after it has received
   an INIT (and sent a CC), as well as the case of two crossing INIT
   messages.


4.3.1.  Crossing INIT messages

   Here is the sequence of events when A starts talking to B at the same
   time as B starts talking to A:

    1.  A sends an INIT message to B.  As part of this A creates proto-
        state for the context and allocates its flow label.  It has
        Lsr(B) from the DNS lookup.

    2.  B sends an INIT message to A.  As part of this B creates proto-
        state for the context and allocates its flow label.  It has
        Lsr(A) from the DNS lookup.

    3.  B receives the INIT message from A.  It discovers the context it
        created in step 2 since it matches the AIDs.  Thus it can
        immediately send a CONF message containing its flow label and
        Lsr(A).

    4.  A receives the INIT message from B.  It discovers the context it
        created in step 1 since it matches the AIDs.  Thus it can
        immediately send a CONF message containing its flow label and
        Lsr(B).

    5.  A receives the CONF message from B and can complete the context
        state creation.

    6.  B receives the CONF message from A and can complete the context
        state creation.







draft-nordmark-multi6-noid-02.txt                              [Page 22]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


4.3.2.  Sending INIT after sending CC

   Here is the sequence of events when A starts talking to B, and after
   B has received the INIT but before B has received the CCR, B starts
   establishing a context with A:

    1.  A sends an INIT message to B.  As part of this A creates proto-
        state for the context and allocates its flow label.  It has
        Lsr(B) from the DNS lookup.

    2.  B receives the INIT message from A.  It finds no matching
        context thus it proceeds in the normal context establishment and
        sends a CC message to A.

    3.  A ULP on B wants to send a packet to AID(A) which triggers B to
        send an INIT message to A.  As part of this B creates proto-
        state for the context and allocates its flow label.  B has
        Lsr(A) from the DNS lookup.

    4.  A receives the CC message from B and responds with a CCR message
        as in the normal context establishment.

    5.  A receives the INIT message from B.  It discovers the context it
        created in step 1 since it matches the AIDs.  Since A has sent
        the CCR it knows that the B will soon complete the context
        establishment and respond with a CONF message.  Thus the INIT
        can be silently ignored.

    6.  B receives the CCR message from A.  At this point in time it
        discovers that it is a bidirectional setup because it has
        context state indicating that it has sent an INIT message.  B
        needs to inform A of the flow label it selected in step 3, which
        is does in the CONF message.



4.4.  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 defer the context
   establishment, but instead it needs to be performed before ULP
   packets can be successfully exchanged.  If the destination locator
   isn't reachable, the M6 layer needs to retry the INIT message with
   different destination locators until a working one is found.  If the
   source locator isn't reachable for return traffic, routers which
   rewrite the source locator at site exit can be helpful to convey to



draft-nordmark-multi6-noid-02.txt                              [Page 23]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   the peer which locator to use.  When the initiator's AID is not
   working as a locator, it isn't possible to piggyback ULP packets on
   the INIT message, to prevent using packets with a source locator
   different than the source AID being used for reflection attacks that
   would bypass any deployed ingress filtering.

   After context setup the sender can use retransmit hints from the ULP
   to get the M6 layer to try a different verified locator.  This is the
   only possibility when only one end is (re)transmitting ULP packets
   and the destination locator is no longer working.  Some heuristics
   are needed in the M6 layer to determine which alternative destination
   locator to try, and how often to try a different one when there are
   persistent failures.

   If one outbound path from the site fails and the border routers
   rewrite source locators then the peer will see packets with the
   working source locators.  Once that locator has been verified by the
   peer, 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, it would be beneficial to add some
   notification e.g., by defining a new bit in the router advertisement
   prefixes to indicate that the prefix is problematic to use for due to
   failures at the site border (IMHO this is semantically different than
   the preferred vs. deprecated semantics), but we would also need some
   mechanism to carry this information from the border routers to the
   routers on each subnet.  Perhaps the router renumbering protocol
   [RFC2894] could be extended to carry this information.


4.5.  Locator Set Changes

   Due to events like site renumbering, the set of locators assigned to
   a host might change at a slow rate.  Since this proposal uses the
   locators in the DNS as the credible source for which locators are
   assigned, there is some coordination necessary to ensure that before
   a host, or the border routers for a site doing rewriting, start using
   a new source locator, the peer has been informed about the new
   locator.  The Update Request message is sufficient to inform the peer
   that a new locator should be acceptable as the source of packets from
   the host, while DNS verification needs to be involved to make that
   locator usable as a destination.

   Due to concerns about having packets with unknown, hence potentially
   bogus, source locators triggering DNS lookups this proposal instead
   uses the DNS TTL in combination with the locator sets in the Update



draft-nordmark-multi6-noid-02.txt                              [Page 24]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Request message, as an indication that the set of locators need to be
   refreshed.

   Each host determines when its own notion of its locators change, and
   uses the Update Request message to inform the peer of these changes.
   If a locator is removed from the set this will make the peer
   immediately stop considering that locator as part of the locator set.
   However, if an additional local locator is communicated to the peer
   in an Update Request, it can not be added to the verified locator set
   at the peer until it has also been seen in the DNS.  Thus, when a
   host observes that it has a new locator, the host might want to
   verify that this locator has been added to the DNS for itself, before
   announcing it to the peer in an Update Request message.

   When a host receives an Update Request with an additional locator for
   the peer and the DNS TTL for the FQDN->Ls lookup has expired, the
   peer will redo this DNS lookup to find the, perhaps updated, set of
   locators in the DNS.  (Presumably failures to redo the lookup
   shouldn't have a negative effect.)

   TBD: Even if there is no Update Request, should the DNS verification
   be redone periodically based on the DNS TTL?  If so, what should the
   minimum time be to avoid DNS storms for FQDNs which have a very low
   TTL?

   When the DNS lookup for the peer's FQDN returns a different locator
   set than previously, the host will inform the peer of the new Lsr
   locator set in an Update Request.  However, since this change to
   Lsv(peer) doesn't effect which source locators are acceptable in
   received packets, it is not time critical to send the Update Request
   message.

   If a host wants to modify the set of locators from which the peer
   accepts packets for the context, the host can send an Update Request
   message with a different Lsl(sender).

   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
   stop using the deprecated locator(s) as the source locator 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.

   TBD: Is there is a need to explicitly signal to the peer "this
   locator is deprecated - please verify another locator and use that as
   Lp(peer)"




draft-nordmark-multi6-noid-02.txt                              [Page 25]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


4.6.  Preventing Premeditated Redirection Attacks

   The threats document [M6THREATS] talks of premeditated redirection
   attacks, that is, where an attacker claims to be a host before the
   real host appears.  The absence of an actual IP layer identifier in
   this proposal makes that a non-issue; the attacker could only claim
   to be host A if the attacker is reachable at one of A's locators.
   Thus by definition the attacker would have to be on the path between
   the communicating peers and such attackers can already perform
   redirection attacks in today's Internet.



5.  HANDLING STATE LOSS

   The protocol needs to handle two forms of state loss:

    - a host loosing the M6 layer state followed by packets arriving
      from a peer which hasn't lost the state.  This could be due to the
      host crashing and rebooting, or due to the M6 layer discarding the
      state too early.

    - the M6 layer garbage collecting state too early due to not being
      aware of what all ULPs do, resulting in the ULP passing down
      packets when there is no context state any more.

   Part of 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 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 and has two facets.  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



draft-nordmark-multi6-noid-02.txt                              [Page 26]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   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 shouldn't.

   Knowing whether the ULP depends on the M6 layer state is not
   sufficient; even if the ULP doesn't, the peer host might still keep
   the context state.  Thus the peer might send a packet using the
   context at some future time.  To the host this looks similar to the
   reboot state loss, in the sense that it receives packets from the
   peer and has no matching context.  The host doesn't know whether this
   is due to a legitimate peer which has retained the context state, or
   whether it is a DoS attack using random flow labels.  However, if the
   ULP on the host passes down a packet to transmit it would turn into
   the second case.


5.1.  State Loss and Packets from the Peer

   If B crashes and reboots and A retransmits a packet with flow label,
   L3(B), L2(A) then what is needed on B 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 to try to help A discover the state loss.

   Another case is when B decides that the context has not been used for
   a long time and as a result discards the context state, and then a
   packet (perhaps a TCP SYN for a new connection) arrives from the peer
   using the context i.e., an M6 packet with a flow label.  In this
   case, B has no choice but send an Unknown Context error back to A.
   (But see Appendix A for a method to remove the need for this error
   ever arising.)

   However, if A blindly trusts the Unknown Context message and uses it
   to restart a context establishment, that is, discarding its current
   context state and sending a INIT, then this could be used by
   attackers to force extra work, but also it would allow an attacker
   that arrives on the path after a context has been established to
   destroy the existing context and insert itself as a Man-in-The-Middle
   for the new context establishment.

   Given that the locators might be rewritten by routers, the main thing
   A has to identify the context is the flow label in the packet that
   caused the Unknown Context error at B.  While this uniquely
   identifies the context on host B, it does not do so on A.  Thus if A
   maintains some number of contexts with different peers, it might not
   be able to uniquely tell to which context the Unknown Context error
   should be applied.  The use of the source address field in the



draft-nordmark-multi6-noid-02.txt                              [Page 27]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Unknown Context message should help disambiguate things, but it isn't
   clear to what extent this helps.  This ambiguity is an opportunity
   that an attacker can take advantage of.  The introduction of the
   birthday counter (an idea from [HIP]), with a relatively small window
   (e.g., 900) of acceptable birthday counter values can substantially
   reduce the probability of off-path attackers being able to use the
   Unknown Context error to kill a context by sending bogus Unknown
   Context errors.

   If we in addition introduce the close exchange, as suggested in
   Appendix A, we also remove most of the ability of an attacker to
   cause extra work by having a host respond to packets with random flow
   labels with Unknown Context errors.  This combination of the birthday
   counter and the CLOSE/CLOSEACK messages, means that the Unknown
   Context error only needs to be when packets with an unknown flow
   label are received during the first X minutes after the reboot.


5.2.  State Loss and Packets from the ULP

   If host B only lost (for instance, by garbage collecting too early)
   the M6 context state, things are a bit more complicated for packets
   passed down from the ULP.  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 to a host which supports
   multihoming.  At a minimum the host needs to try to determine this,
   and if it somehow determines that the peer supports multihoming, then
   it should try to determine the peer's locators and reestablish a
   host-pair context.

   B can determine whether A is M6 capable by doing a reverse lookup of
   AID(A)->FQDN(A) followed by a FQDN(A) lookup to see of there is an M6
   record (and get the locator set of A as well).  Or, if DNS reverse
   lookups are undesirable or do not work, perhaps a packet could be
   exchanged with A to ask it whether it supports multihoming.  Simply
   sending an INIT message to the AID(A) will not only tell it whether A
   supports multihoming, but also let B know the flow label and Lsl(A)
   locators to use.  But as this protocol is currently specified, using
   a new ICMP type, an INIT message sent to a host which doesn't support
   multihoming will be silently dropped.  TBD: Would it make sense to
   instead use a new payload type for the M6 messages to at least
   receive an ICMP payload type unknow error from hosts which do not
   support multihoming?

   If B is communicating with both standard IPv6 hosts and hosts which
   support multihoming, then for performance reasons it should avoid
   doing these DNS lookups or peer queries for every packet sent to a
   standard IPv6 host.  Implementation tricks (such as "has this socket



draft-nordmark-multi6-noid-02.txt                              [Page 28]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   ever used M6" flag at the socket layer, "negative caching" of peers
   that do not support M6) can be useful to avoid performance overhead,
   and caching of the peers that do support M6 can all be used to
   address this performance concern.

   If, as part of this, B determines that A is M6 capable, it has the
   same information as the initiator during the initial context
   establishment thus it can follow that procedure starting by sending
   an INIT message.  If A didn't garbage collect its end of the state
   this will result in receiving a CONF message from A which includes
   the flow label etc.



6.  ENCODING BITS IN THE IPv6 HEADER?

   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?




draft-nordmark-multi6-noid-02.txt                              [Page 29]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Thus a router would check if the protocol is in the P1 range and 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:

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

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



7.  PROTOCOL PROCESSING

   A more detail description of the protocol is presented in this
   section.


7.1.  State Machine

   The protocol can be described using the following states:

    o IDLE: no state for the context at all.

    o INIT-SENT: an INIT message has been sent.

    o CCR-SENT: a CCR message has been sent.

    o ESTABLISHED: a CCR or CONF message has been received thus the
      context is fully established with data packets being carried using
      the flow labels and Section 6 encoding.

    o UR-SENT: Established but awaiting an Update Acknowledgement.



7.2.  Sending INIT messages

   When a host needs a host-pair context it first checks if there
   already is a context which matches the pair of AIDs.  If not, it will
   establish such a context by sending an INIT message.  The sender of
   the INIT message is a called the "initiator" and the peer is called
   the "responder" even if this terminology is inexact when both ends
   send INIT messages at about the same time.

   The initiator must verify that the AIDs are part of the locator sets;



draft-nordmark-multi6-noid-02.txt                              [Page 30]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   if this is not the case it is most likely due to some local confusion
   on the initiator since the AIDs were selected (see Section 4.1) from
   the locator sets.

   If the initiator knows that it doesn't have a FQDN or that a
   verification using forward and reverse lookups would fail, for
   instance due to the reverse tree not being populated, it might as
   well only include the AID in Lsl(initiator) since this saves the
   responder the effort to try to verify things in the DNS.

   The initiator creates a proto-context state and allocates a unique
   flow label; F(local).

   Then it picks a random [RANDOM] nonce to include in the INIT message,
   sends the INIT message, and sets the state to INIT-SENT.

   The first INIT message is sent to the destination locator which is
   the AID.  Should the INIT message be retransmitted, a different
   destination locator should be used.  The INIT messages, as all other
   M6 control messages, can be sent with the "rewrite ok" bit set.  If
   the routers do not rewrite the source locators it might be necessary
   for the initiator to try different source locators as well as
   destination locators as it is retransmitting the INIT message.


7.3.  Receiving INIT messages

   When a host receives an INIT message it first checks whether it has
   an existing context for the AID pair.

   If such a context is found, the following additional checks are
   applied:

    o The state is INIT-SENT or ESTABLISHED

    o The IP source address field in the INIT contains a locator which
      is part of Lsl(peer)

    o The IP destination address field in the INIT contains a locator
      which is part of Lsl(host)

   If any of the above checks fail the INIT message is silently dropped.
   If all the checks succeed, the host can update the existing context
   from the INIT message (the peer's birthday counter, locator set, and
   flow label) and respond with a CONF message.  The CONF message should
   include the nonce from the INIT message, the local flow label, the
   local birthday counter, Lsr(peer) and Lsl(responder) from the
   existing context.  If the INIT message matching an existing context



draft-nordmark-multi6-noid-02.txt                              [Page 31]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   has piggybacked a ULP packet, this packet is passed to the ULP.

   In there is no state matching the AID pair, the host verifies that
   the AID(responder) is in fact one of its locators.  Should this fail
   the INIT message is silently dropped.

   Then the responder forms a CC message using a per-host key and a
   timestamp or serial number to produce a keyed hash to protect the
   state information carried in the CC message and returned in the CCR
   message.

   If the responder knows that it doesn't have a FQDN or that a
   verification using forward and reverse lookups would fail, for
   instance due to the reverse tree not being populated, it might as
   well only include the AID in Lsl(responder) in the CC message since
   this might save the initiator the effort to try to verify things in
   the DNS.

   If the INIT packet has a piggybacked ULP packet, that is, the nexthdr
   value is something different than NONXTHDR, this packet can
   potentially be passed to the ULP.  It is safe to pass it to the ULP
   when the source and destination address fields in the INIT packet are
   the AIDs, and it is also safe to accept such packets when the
   destination address field contain a locator different than the AID.
   But if either the INIT packet was sent with a different source
   locator or the source locator was rewritten in transit, it is not
   safe to pass the piggybacked packet to the ULP.  (This is because
   until the context state is created, any "response" packet from the
   ULP would be sent as a regular IPv6 packet to the peer AID.  The need
   to prevent reflection attacks which can bypass any deployed ingress
   filtering means that we need to avoid this when the INIT packet was
   not sourced by the AID.)  In this case the responder sets the "ULP
   packet discarded" bit in the CC message.


7.4.  Receiving CC messages

   The host looks for a matching context based on the AID pair.  If no
   context is found, or if the context is not in state INIT-SENT, or if
   the nonce doesn't match what was sent in the INIT, the CC message is
   silently dropped.

   Otherwise the host records the Lsl(peer) from the CC message, changes
   the state to CCR-SENT, and sends a CCR message.  The CCR message can
   either reuse the nonce used with the INIT message, or a new random
   nonce can be selected.

   The host forms Ls(peer) as the intersection between Lsr(peer) and



draft-nordmark-multi6-noid-02.txt                              [Page 32]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Lsl(peer).  If this intersection does not contain AID(peer) it is an
   error and the AID is added to the set.

   If the CC packet has a piggybacked ULP packet, this packet can
   potentially be passed to the ULP.  It is clearly safe to pass it to
   the ULP when the source and destination address fields in the CC
   packet are the AIDs.  But it seems to also be safe when the address
   field contents fall in the locators sets as known to the initiator.
   If this is not the case, then the piggybacked ULP packet is silently
   ignored.


7.5.  Receiving CCR messages

   The timestamp/serial is verified to be recent, and then the
   timestamp/serial is used to determine which per-host key was used for
   the keyed hash in the CC message.  Using this key, the keyed hash is
   verified.  If it does not verify, or if the timestamp/serial is too
   old, the CCR message is silently dropped.

   Then the host looks for a matching context based on the AID pair.  If
   a context is found this could be the second form of concurrent
   context establishment.  The host performs the following checks:

    o The state is INIT-SENT

    o The IP source address field in the CCR contains a locator which is
      part of Lsl(peer)

    o The IP destination address field in the CCR contains a locator
      which is part of Lsl(host)

   If any of the above checks fail the CCR message is silently dropped.

   If the checks all succeed, the host can update the existing context
   from the CCR message (the peer's birthday counter, locator set, and
   flow label) and respond with a CONF message.  If this update results
   in Ls(local) or Ls(peer) not including the corresponding AID, this is
   an error and the AID is added to the set.

   The CONF message should include the nonce from the CCR message, the
   local flow label, the local birthday counter, the Lsr(peer), and
   Lsl(responder) from the existing context.

   If a context is not found, then one is created based on the
   information in the CCR message.  The host allocates a flow label for
   the context.  The host MAY perform a reverse plus forward DNS lookup
   starting with AID(peer), and if so it includes the resulting



draft-nordmark-multi6-noid-02.txt                              [Page 33]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Lsr(initiator) in the CONF message.  Otherwise, the CONF message only
   contains the nonce, flow label and birthday counter.

   If the CCR packet has a piggybacked ULP packet, it will be passed to
   the ULP independently of the IP address fields in the CCR message.
   This is possible because even if the CCR contains spoofed locators
   and/or AIDs, any "response" packet from the ULP will only be sent to
   the verified peer locators now that the context state has been
   created.


7.6.  Receiving CONF messages

   The host looks for a matching context based on the AID pair.

   If no matching context is found the CONF message is silently
   discarded.

   If the state is INIT-SENT and the nonce does not match the nonce sent
   in the INIT, the CONF message is silently discarded.  If the state is
   CCR-SENT and the nonce does not match the nonce sent in the CCR, the
   CONF message is silently discarded.

   In any other state the CONF message is silently discarded.

   Then the CONF message is used to record the peer's flow label.  If
   the CONF message contains the Lsr(initiator) this is used to update
   the context.  As part of this Ls(initiator) is updated to be the
   intersection of Lsr(initiator) and Lsl(initiator).  If this
   intersection does not contain AID(initiator) this is an error and the
   AID is added to the set.

   If the CONF message contains the Lsl(responder), which is the case
   during bidirectional establishment i.e., the CONF was sent in
   response to an INIT message, then this is used to update the context
   and Ls(responder) is updated to be the intersection of Lsr(responder)
   and the received Lsl(responder).  If this intersection does not
   contain AID(responder) this is an error and the AID is added to the
   set.

   Finally the state is changed to be ESTABLISHED.

   If the CONF packet has a piggybacked ULP packet, this packet can
   potentially be passed to the ULP.  It is clearly safe to pass it to
   the ULP when the source and destination address fields in the CONF
   packet are the AIDs.  But it seems to also be safe when the address
   field contents fall in the locators sets as known to the initiator.
   [Given that the CONF is know to be the result of a INIT/CCR packet,



draft-nordmark-multi6-noid-02.txt                              [Page 34]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   it can be assumed that the locators fall in the sets?]

   If this is not the case, then the piggybacked ULP packet is silently
   ignored.


7.7.  Sending Update Request messages

   When a hosts sees that either its own locator set has changed, or
   that the DNS verification (initial, or redone after DNS TTL expiry)
   of the peers locators show a reduction in the locator set, the host
   should send an Update Request.

   The sender of the Update Request should verify that the AIDs are part
   of the locator sets as part of sending the Update Request.

   The sender picks a random nonce to include in the message, sends the
   message to Lp(peer), and sets the state to UR-SENT.


7.8.  Receiving Update Request messages

   The host looks for a matching context based on the AID pair and the
   flow label pair in the Update Request message.

   If no context is found, the Update Request is silently dropped.

   If a context is found, it is verified that the locators that are in
   the IP address fields are part of the Lsl locator sets.  If not, the
   update request is silently dropped.  Then the locators in the Update
   Request are used to update the context state.  As part of this the
   intersections of the local and remote locator sets are maintained.
   Should either of the intersections not include the corresponding AID
   this is an error and the AID in question is added to the set.

   The receipt of a reduced Lsl(sender) should result in immediately no
   longer using the removed locators as destination locators for
   transmitted packets.  The receipt of an increased Lsl(sender) should,
   if the remaining DNS TTL for the FQDN has reached zero, trigger a a
   DNS verification (forward and reverse lookup) of the new locators.
   Should this verification complete successfully, the locator(s) will
   be added to the verified set of peer locators hence be valid for
   transmitting packets.

   The receipt of changes to Lsr(receiver) is less critical since the
   peer will accept as source locators any of the locators that are part
   of the Lsl(receiver) that was communicated to the peer during context
   establishment or in the most recent Update Request.



draft-nordmark-multi6-noid-02.txt                              [Page 35]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   The host responds to the Update Request by sending an Update
   Acknowledgement back to the sender of the request copying the
   nonce/timestamp, AIDs and flow labels from the request.


7.9.  Receiving Update Acknowledgement messages

   The host looks for a matching context based on the AID pair and the
   flow label pair in the Update Acknowledgement message.

   If no context is found, the Update Acknowledgement is silently
   dropped.

   If a context is found, it is verified that the context state is in
   UR-SENT and that the nonce in the acknowledgement matches the nonce
   that was sent in the request.  If either of those checks fail, the
   message is silently dropped.

   Otherwise, the state for the context is changed back to ESTABLISHED.


7.10.  Retransmission

   The INIT messages are retransmitted by the initiator until a CC or a
   CONF message with a matching nonce is received.

   The CC messages are not retransmitted; if they are lost the initiator
   will retransmit the INIT message.

   The CCR messages are retransmitted by the initiator until a CONF
   message with a matching nonce is received.

   The Update Request messages are retransmitted until an Update
   Acknowledgement with a matching nonce is received.

   These retransmissions continue with binary exponential backoff until
   CONTEXT_IDLE_TIME (suggested 5 or 15 minutes) have passed.  The
   initial retransmit timer is 4 seconds.  It is suggested that some
   randomness be applied to the retransmit timer to avoid
   synchronization should lots of hosts in a site follow the same
   pattern of retransmissions.


7.11.  Receiving Data Packets

   Received M6 control packets (INIT) etc are dispatched based on the
   ICMP code and processed as indicated in the sections above.




draft-nordmark-multi6-noid-02.txt                              [Page 36]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Received M6 data packets (as indicated by the payload types in
   section 6) are processed as follows:

    1.  Lookup the context based on the flow label

         1a.  If no context found, drop the packet and send a Unknown
              Context message to the sender.

    2.  Compare the destination address field with Lsl(local)

         2a.  If destination is not in Lsl(local), silently drop the
              packet.

         2b.  If destination is Lp(local), no action is needed.

         2c.  If destination is not Lp(local), should we change
              Lp(local) so that the source locator for transmitted
              packets is changed? [TBD]

    3.  Compare the source address field with Lsl(peer), Lsv(peer)

         3a.  If source is not in Lsl(peer), silently drop the packet.

         3b.  If source is in Lsl(peer) but not in Lsv(peer), trigger
              verifying that locator (and accept the packet).

         3b.  If source is Lp(peer), no action is needed.

         3c.  If source is not Lp(peer) and is in Lsv(peer), change
              Lp(peer) so that the destination locator for transmitted
              packets is changed.

   In the cases where the packet wasn't dropped above, the packet is
   rewritten to contain the AIDs from the context state and passed to
   the ULP.


7.12.  Receiving Unknown Context messages

   Look for matching contexts (there might be multiple) that have the
   same peer flow label as the one in the UC message, and where
   Lsl(peer) in the context includes the source address field of the UC
   message.

   If no such context is found, silently discard the UC message.

   If the birthday counter in the UC message is the same as the recorded
   birthday counter for the peer, the UC message was due to the context



draft-nordmark-multi6-noid-02.txt                              [Page 37]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   state being garbage collected without the peer rebooting.

   If the birthday counter in the UC message is greater than (using
   serial number arithmetic) the recorded birthday counter, but is not
   more than MAX_BIRTHDAY_INCR than this number, then the UC message is
   assumed to be due to a reboot of the peer.

   In both of the above cases the context can be discarded and a new
   context be initiated by sending an INIT message. [TBD: discard vs.
   update the existing context based on the CC and CONF messages?]

   If the birthday counter doesn't match either criteria, then UC
   message is silently dropped.

   In both above cases of acceptable UC messages it is RECOMMENDED that
   the host also verify whether the included packet is consistent with a
   packet that the host might have sent recently; for instance that in
   the case of UDP, TCP, or SCTP, the port numbers match port numbers
   that are currently in use and that the TCP and SCTP sequence numbers
   are reasonable for the matched connections.  [The utility of these
   checks is limited, because for some ULPs such as ICMP echo messages,
   the host might not have any way to check things hence it is required
   to accept the UC message.]

7.13.  DNS Verification and Hosts without a FQDN

   A host without a FQDN, or a host which knows that the forward and
   reverse DNS information for it is missing or inconsistent, can remove
   the need for the peer to detect this by passing a Lsl in INIT and CC
   messages which consists of only the AID for the context.  When doing
   so, the "rewrite ok" bit should not be set for those messages.

   This approach is possible even if the host has multiple locators; it
   implies that such a host can take advantage of any multihoming of the
   peer even though it can't take full advantage of itself being
   multihomed.  Thus the peer's locators can change for the context, but
   the host itself can only use its AID for the context.

   When a host verifies the locator relationship it treats the peer's
   AID as being implicitly verified by the context establishment
   handshake as long as the AID was used as the locator for this
   exchange.  This is basically relying on the return routability
   property for the AID being a locator.  Thus is Lsl(peer) contains the
   AID as a single member, and that AID is used as the locator during
   the context establishment, there is no need to perform any DNS
   verification.

   Since the host might not itself know that it doesn't have a FQDN or



draft-nordmark-multi6-noid-02.txt                              [Page 38]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   that the reverse plus forward lookups would fail to verify, the peer
   also needs to take this into account in the verification.  When an
   initiator verifies things using the reverse lookup and it discovers
   that the lookup for one or more of the peer's locators fail with a
   permanent DNS error, it should exclude those locator(s) from the set.
   And if all of them fail, it should still include the peer's AID as
   the only member in the peer's locator set.

   When a responder tries to verify the peer by performing DNS lookups
   (reverse and forward), if it fails to perform a reverse lookup on the
   peer AID due to a permanent DNS error, which is needed to find the
   FQDN, then it will assume that the peer has no FQDN.  In this case
   the Lsr(peer) will contain only the AID(peer) i.e., the peer's
   locator can not change.  However, it will still accept data packets
   with any of the Lsl(peer) locators in the source address fields; it
   will not send packets to any locator but the AID.

   If the reverse lookup of the peer's AID fails with a transient DNS
   error, it is recommended that the DNS lookup is redone (using binary
   exponential backoff until it either succeeds or fails with a
   permanent error).

   If the DNS lookups fail with a permanent error it is recommended that
   the locator set with the failed locators removed is signaled to be
   the peer as Lsr(peer) in an Update Request message.

   This will make the peer stop using those locators as source locators
   even though the host sending the Update Request will continue to
   accept packets from any of the locators in Lsl(peer).

   The initiator starts off with Lsr(responder) being based on what the
   forward DNS lookup returned.  As successful reverse lookups, that is
   reverse lookups that point at the same FQDN, are completed on these
   locators, the locators are added to Lsv(responder) i.e. become
   candidate destination locators.  The initial Lsv(responder) is the
   AID even without a reverse lookup.  But should the INIT message be
   (re)transmitted to different destination locators, the AID will not
   be considered verified unless there has been a successful reverse
   lookup.

   The responder starts off with Lsv(initiator) containing only the AID,
   if and only if the AID was used as a locator during the context
   establishment.  If the AID was not used as a locator during the
   establishment, the Lsv(initiator) will initially be empty.  This
   implies that data packets can not be sent until at least one locator
   has been verified using the DNS.  [TBD: Is this too strict?  Can we
   allow the locator that was used during establishment to be in Lsv
   even though it is not the AID?]



draft-nordmark-multi6-noid-02.txt                              [Page 39]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   When the host receives messages (CC, CONF, Update Request) which
   shrinks Lsl(peer), it will remove the deleted locators from Ls(peer)
   and as a result from Lsv(peer) as well.

   TBD: Need to know whether there is a strict definition of temporary
   vs. permanent DNS errors.  Things like NXDOMAIN should be a permanent
   error.

7.14.  Birthday Counter

   Each host needs to maintain a birthday counter in stable storage to
   help with safe resynchronization when one of the ends have lost its
   state.

   When a host is first initialized it allocates a random initial value
   for the birthday counter [RANDOM].  Each time the host looses all
   state, that is, crashes or powers off and reboots, it increments the
   birthday counter by one and saves the result in stable storage.

   The protocol needs a constant, MAX_BIRTHDAY_INCR, which should be
   chosen so that during the lifetime of a context after the peer has
   stopped sending (Appendix A uses X minutes for this), no host should
   reboot and increment its birthday counter more than this number of
   times.

   It might be reasonable to assume that no host can reboot more
   frequently than once a second.  This implies that if the context is
   discarded 15 minutes after the last packet was received, the peer
   could have rebooted at most 900 times after it sent the last packet
   using the context.  As a result the probability of an off-path
   attacker hitting this window of 900 in a 32-bit birthday counter is
   about 1 in a million.  A 64-bit birthday counter might be overkill.



8.  COMPATIBILITY WITH STANDARD IPv6

   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.2)




draft-nordmark-multi6-noid-02.txt                              [Page 40]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   The receive side handles both standard IPv6 and M6 since it
   demultiplexes on whether a packet is an M6 packet, that is, based on
   the payload types in Section 6.



9.  APPLICATION USAGE OF IDENTIFIERS

   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.  But this is a renumbering issue and not
   an effect of the multihoming support.

   Applications, which 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.

   Applications which today either retain a peer's IPv6 address for
   future use, such as connecting back to that peer ("callbacks"), or
   pass a peer's IPv6 address to a third party ("referrals") will not
   break with this multihoming support; they will end up retaining
   and/or passing the AID instead of an IPv6 address.  Since the AID is
   a locator things will still work as long as that locator is
   reachable.

   However, the AID doesn't contain information whether the host is M6
   capable, thus the callbacks and referrals would use IPv6 without
   multihoming support unless something special is done.  To be able to
   take advantage of the multihoming support the application or host
   would need to detect whether the AID is M6 capable, for instance, by
   doing a reverse lookup on the AID to get the FQDN and the a forward
   lookup on the FQDN to look for the "M6 capable" DNS RR.  An
   alternative would be to use the suggestion in Section 5.2 to send an
   INIT message to the peer to discover if it is M6 capable.

   Also, should the locator which is the AID not be reachable, the
   application/host will fail to communicate with the peer.  A reverse
   plus forward lookup of the AID, or the INIT suggestion, can be
   performed to discover all the locators.




draft-nordmark-multi6-noid-02.txt                              [Page 41]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Whether these lookups can be hidden from the application, or whether
   the applications need to be modified to make the callbacks and
   referrals take full advantage of the multihoming is for further
   study.



10.  CHECKSUM ISSUES

   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 flow label 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.  In this proposal such packets are silently
   ignored.

   Except for the obscure case when Ls(A) contains multiple 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 when the peer receives any resulting Unknown
   Context error message, it will not contain a source locator which is
   in the peer's locator set, hence it will be silently 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 flow label in a data message could
   have two possible effects: not finding any context state, or finding
   the incorrect context state.  In the first case any Unknown Context
   error message would be dropped by the peer since the flow label
   included in the error message doesn't match the flow label that was



draft-nordmark-multi6-noid-02.txt                              [Page 42]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   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.



11.  IMPLICATIONS FOR PACKET FILTERING

   Ingress filtering should be replaced by locator rewriting 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 locators thus a stateful firewall would
   need to be aware of the context state to let the correct packets
   through as locators might change during some
   communication/connections.  Such firewalls could optionally perform
   their own verification by issuing DNS lookups the same way as the
   endpoint.  However, the firewalls probably has to be more careful not
   exposing themselves to DoS attacks by doing too much DNS lookups.



12.  IPSEC INTERACTIONS

   As specified, all of ESP, AH, and key management is layered above the
   M6 layer.  Thus they benefit from the stable AIDs 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
   headers.

   A result of layering M6 above IPsec is that the M6 protocol can
   potentially be used to redirect IPsec protected traffic as a
   selective DoS mechanism.  If we somehow could require IPsec for the
   M6 protocol packets when the ULP packets between the same hosts use
   IPsec, then we could prevent such attacks.

   However, due to the richness in IPsec policy, this would be a bit
   tricky.  If only some protocols or port numbers/selectors are to be
   protected by IPsec per a host's IPsec policy, then how would one



draft-nordmark-multi6-noid-02.txt                              [Page 43]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   determine whether M6 traffic needs to be protected?  Should one take
   the conservative approach that if any packets between the hosts/AIDs
   need to be protected, then the M6 traffic should also be protected?

   For this to be useful both communicating hosts would need to make the
   same policy decisions, so if we are to take this path there would
   need to some standardization in this area.



13.  SECURITY CONSIDERATIONS

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

   Just as in today's Internet hosts on the path can inject bogus
   packets; in this proposal they need to extract the flow labels 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 flow label together with locators that are in the
   locator sets.  If ingress filtering is deployed the attacker might
   not be able to freely choose the source locator, thus just as in
   today's Internet ingress filtering further limits attackers ability
   to inject packets with spoofed source addresses.

   An attacker can inject bogus Update Request messages by picking
   random flow labels and locators, in an attempt to make the
   communication break or make it use less locators.  Worst case this
   can cause the communication to drop down to only using the AIDs and
   no other locators.  Such an attacker needs to know the AID pair and
   guess the flow label pair for the attack to be successful.  Guessing
   a total of 40 bits of flow labels would be hard for an off-path
   attacker.  One could make this even harder by, in addition to the
   flow labels, have the context establishment exchange some larger
   random numbers between the peers, and using those numbers to compute
   a HMAC on the Update Request.  This would still be subject to Man-
   in-The-Middle attacks for on-path attackers, but it would make it a
   lot harder for off-path attackers to hit something with random
   packets.

   An attacker can inject bogus Unknown Context messages.  The
   protection against this is a locator and flow label match as well as
   hitting the relatively small window of acceptable Birthday Counters.
   In addition, the receiver will reject Unknown Context messages if the
   included payload packet was not a packet that it might have recently
   sent.

   DNS verification implications TBD.



draft-nordmark-multi6-noid-02.txt                              [Page 44]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


14.  PRIVACY CONSIDERATIONS

   The existence of mappings in the DNS from any locator to a FQDN and
   from the FQDN to all the locators of a host can potentially make it
   harder than in today's Internet for a host that is part of a
   multihomed site to be anonymous.

   This is especially true if the host wants to take advantage of RFC
   3401 temporary addresses, or if the host is moving between different
   subnets since the forward and reverse information would need to be
   updated.

   Thus a host which is in a multihomed site which desires to have
   multiple pseudonyms and use the M6 protocol would need to, not only
   have multiple locators per prefix (as in RFC 3041), but also have
   multiple FQDNs each FQDN corresponding to a separate set of locators.

   Note that hosts that communicate with peers that are multihomed are
   not required to have a FQDN to take advantage of the multiple
   locators of the peer, hence they can retain the same amount of
   pseudonyms as with RFC 3041.



15.  DESIGN ALTERNATIVES

   Several aspects of the protocol can be tweaked while following the
   original idea of using a set of locators as an equivalence set and
   using the DNS to verify the set membership.

   A few to consider are listed in this section.

15.1.  Avoid introduction of M6 DNS Resource Record type

   It is possible to avoid introducing a new resource record type to
   indicate whether a peer is M6 capable.

   Instead one of the M6 packets can be used.  For instance, a host can
   send an INIT message to the peer and if the host receives a response
   it knows the peer is M6 capable.

   This potentially has some performance implications, hence it would be
   desirable to structure the use of the protocol slightly differently.
   For instance, if the peer is not M6 capable it is useful if the INIT
   message would result in an ICMP error being returned.  As currently
   specified, with the M6 messages being an informational ICMP type, no
   such error message will be returned.  Thus it would be better if the
   M6 messages were instead defined to be a separate new payload type so



draft-nordmark-multi6-noid-02.txt                              [Page 45]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   that hosts which do not implement the protocol respond with an ICMPv6
   "payload type unknown" error.

   If the initiator doesn't know whether the peer supports M6 or not, it
   would seem better to not piggyback a ULP packet on the INIT message
   but instead send any ULP packet separately.  Since this might be
   suboptimal when the peer does support M6, it would be useful for the
   host to cache which AIDs/FQDNs support M6 so it can use piggybacking
   in that case.

   And since sending the INIT message over and over to a host which
   doesn't support M6, it would also be useful for the host to cache
   which AIDs/FQDNs do not support M6 so that it can skip trying an INIT
   message when it has already tried once.

15.2.  Extension header instead of using flow label

   Use an actual extension header for M6 and use a context tag in that
   header instead of using the flow label.  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.

   With an 8 byte extension header one could fit

    - 8 bits of next header value

    - 16 bits of checksum (over the extension header only) [TBD: is this
      useful?]

    - 1 bit to indicate that it is a M6 data packets (other M6 packets
      would have e.g. a 8 bit message type instead)

    - 39 bits of context tag

   As a result one would only need to allocate 2 protocol values instead
   of the 16 suggested in Section 6:  One protocol value for "M6 -
   rewrite ok" and one value for "M6 - no rewrite".

   The data messages could look like this:

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Checksum           |    Nexthdr    |0| Context Tag |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  Context Tag (continued)                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




draft-nordmark-multi6-noid-02.txt                              [Page 46]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   M6 control messages could look like:

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Checksum           |    Nexthdr    |1| Message Type|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  <type specific fields>                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


15.3.  Explicit close exchange

   Instead of relying on the Unknown Context error to try to synchronize
   when one has garbage collected the context state and the other end
   has not, we could define an explicit close exchange.  An early
   attempt at this is specified in Appendix A.  This approach would
   remove any DoS concerns related to responding to Unknown Context
   errors.



16.  OPEN ISSUES

   Either we need to specify an upper lifetime of a context after no
   packets have been received on the context, or we need to adopt a
   close handshake akin to the example in Appendix A.  This need arises
   because the logic for the birthday counter needs to know how many
   times a peer can reboot while the host maintains an old context with
   that peer; this number determines the window of allowed birthday
   counter values for the Unknown Context error.

   Which DNS errors should be treated as temporary vs. permanent?

   Does it make sense to establish a larger context tag for each
   direction in addition to the flow label, so that Update Request
   messages and Close messages can be less subject to random packet
   injection?

   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?

   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?



draft-nordmark-multi6-noid-02.txt                              [Page 47]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   Understanding the performance of DNS verification with and without
   DNSsec.  With DNSsec how many public key signature verifications are
   likely to be needed for the reverse lookup of each locator?

   How does the use of the last verified source locator as a destination
   locator for subsequent return traffic interact with ingress
   filtering?  It would be nice if the protocol could operate with
   uncoordinated ingress filtering between the different exits/ISPs, but
   it is unclear whether this is feasible.

16.1.  Renumbering Considerations

   Need to write down any special coordination needed when a locator is
   added to a locator set or when one is removed; this can happen when a
   site is renumbered.

16.2.  Initiator Confusion vs. "Virtual Hosting"

   When A wants to communicate with host B and host X at the same time
   there can be some confusion since the DNS could return partially
   overlapping locator sets for the two remote hosts.  For example,

   The lookup of FQDN(B) returns Ls(B) which contains L1(B), L2(B), ...
   Ln(B).

   The lookup of FQDN(X) returns L1(B), L1(X)

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

   In Section 4.1 this is resolved by the initiator performing a reverse
   lookup on the AID.  Thus looking up L1(B) in the ip6.arpa tree in the
   above example.  That works because it would return FQDN(B) thus X
   could be safely declared as being bogus.  As a result communication
   with X would not be possible.

   However, in many (IPv4) hosting setups today multiple domain names
   (www.foo.com, www.bar.com) are served by a single IP address.  In
   this case the reverse lookup can't point back at both names unless
   the PTR resource record contains multiple records with different
   names.  Per [RFC2181] section 10.2 this is allowed but it doesn't
   appear to be commonly used.

   Can we depend on this little used feature of the PTR usage?  If not
   it would seems to mean that each locator can only be used with one



draft-nordmark-multi6-noid-02.txt                              [Page 48]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   FQDN which would be more restrictive than we have with IPv4 today.



17.  ACKNOWLEDGEMENTS

   The first version of this document was 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].  The idea to use a
   set of locators and not inventing a new identifier name space, as
   well as using the DNS for verification of the locators, was first
   brought up by Tony Li.

   Later versions of the document have benefited from the comments of
   many participants in the Multi6 WG.



18.  REFERENCES

18.1.  Normative References

     [M6THREATS] Nordmark, E., and T. Li, "Threats relating to IPv6
             multihoming solutions", draft-ietf-multi6-multihoming-
             threats-00.txt, July 2004.

     [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.

     [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
             Recommendations for Security", RFC 1750, December 1994.

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



draft-nordmark-multi6-noid-02.txt                              [Page 49]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


             IPv6", RFC 3775, June 2004.

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

     [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E.
             Nordmark, "Mobile IP version 6 Route Optimization Security
             Design Background", draft-nikander-mobileip-v6-ro-sec-02
             (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] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST):
             AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt,
             October, 2003.

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

     [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.

     [RFC2181] R. Elz, and R. Bush, "Clarifications to the DNS
             Specification", RFC 2181, July 1997.

     [RFC3697] J. Rajahalme, A. Conta, B.  Carpenter, S. Deering, "IPv6
             Flow Label Specification",  RFC 3697, March 2004.

     [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894,
             August 2000.

     [RFC3041]  T. Narten, R. Draves, "Privacy Extensions for Stateless
             Address Autoconfiguration in IPv6", RFC 3041, January 2001.

     [HIP] Robert Moskowitz, "Host Identity Protocol", 11-Jun-04,
             <draft-ietf-hip-base-00.txt>

     [WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol
             (WIMP)", July 2004,  <draft-ylitalo-multi6-wimp-01.txt>



draft-nordmark-multi6-noid-02.txt                              [Page 50]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


19.  CHANGE LOG


Changes since version -01:

 o Made the protocol allow for locator rewriting of all the M6 control
   messages.

 o Allow for hosts without a FQDN or without a correct forward+reverse
   relationship benefit from the peer being multihomed.

 o Handle inconsistencies between the DNS and host configuration, e.g.
   due to two-faced DNS or DNS-based load balancing, by having the host
   tell its peer what it received from the DNS and use the intersection
   of the DNS info and the info known by the host itself.

 o Removed the probability of DNS inconsistencies resulting in packets
   being dropped due to having an unknown source locator; a host informs
   its peer which locators should be acceptable as source addresses
   while the destination locators continue to be verified in the DNS.

 o Changed the context establishment to start with an INIT message from
   the Initiator instead of having the establishment be driven by a
   message with an unknown flow label arriving at a host.  This allows
   the Initiator to decide when to establish the context; before the
   context is established "regular" packets can be exchanged as long as
   the locators used are the AIDs.

 o Renamed the messages to have the same names as in WIMP;
   INIT/CC/CCR/CONF

 o Simplified the uniqueness requirements for the flow label to be
   "unique per receiving host" in order to handle dynamic changes
   (driven from the DNS) of the set of locators assigned to a host.
   Without this change it was impossible to make the flow label plus
   locators uniquely identify a context at the receiver when the set of
   locators changes over time (e.g., due to renumbering).  This limits
   each (virtual) host to about 1 Million contexts at any given time.
   Removing this limitation would imply carrying a larger context tag in
   an extension header, which is a possible tweak to this protocol.

 o The simplified uniqueness requirement resulted in needing receiver
   instead of sender allocation of the flow label, which in turn
   resulted in the initiator sending the first message (the INIT) in the
   context establishment exchange.

 o Made it possible to allow locator rewriting on the context
   establishment messages, while allowing piggybacking of ULP packets.



draft-nordmark-multi6-noid-02.txt                              [Page 51]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   However, in some cases when locators are being rewritten, ULP packets
   can not be piggybacked until the context is established, to avoid
   security exposure.

 o Added details of how the host-pair context is established when both
   ends initiate the setup at the same time.

 o Worked out the details for how messages are retransmitted.  As a
   result, the 4th message in the establishment exchange needs to be
   mandatory to ensure that the initiator always knows the correct flow
   label to use in transmitted packets.  Thus the 3-way context
   establishment exchange becomes a 4-way exchange as in [HIP] and
   [WIMP], with the ability to piggyback ULP packets on all those
   messages.

 o As a result of needing a 4-way exchange there is no longer any
   benefit in attempting a provisional allocation of a flow label when
   receiving the INIT.  Hence the responders flow label allocation is
   now done when receiving the CCR message.

 o Added details about how the host-pair context state could be removed
   in a coordinated fashion in Appendix A.

 o Added details on state recovery when one end has lost the peer's
   host-pair context state, using a birthday counter as in [HIP]

 o Added a suggestion on how one can avoid introducing a new M6 DNS
   Resource Record type.

 o Renamed "flowid" to correctly be "flow label"



APPENDIX A: CONTEXT CLOSE PROTOCOL


   This scheme is robust against arbitrary network partitioning and
   loss, whether in both directions or in one direction, through the use
   of timers plus new CLOSE and CLOSEACK messages.  It introduces one
   additional state in the state machine:

    o CLOSING: about to go away but the state is retained to be able to
      reliably inform the peer that the state is being removed.  No data
      packets can be sent using the context when in closing state, but
      otherwise it is the same as ESTABLISHED state.

   The underlying observation is that the network doesn't spontaneously
   generate packets, thus for a packet to be received it must have been



draft-nordmark-multi6-noid-02.txt                              [Page 52]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   sent by the peer, and if the host does not send a packet no packet
   will be received by the peer.  (But packets might be sent and never
   received.)

   In the basic analysis we assume that the network delay (propagation
   and queuing) is zero, that is, a packet is received by the peer
   either immediately when sent, or never (in the case of loss).

   The mechanism uses a time constant: X minutes.

   The mechanism works as follows:

    1.  When no packet has been received on the context for X minutes
        the context transitions to CLOSING state.  A CLOSE message is
        transmitted to the peer.

        When in CLOSING state the host must not send any data packets
        using the context.  If there is a need to send a data packet a
        new context must be created by starting by sending an INIT.

    2.  When the host receives a CLOSE message it discards the context
        state and responds with a CLOSEACK message.  (The authenticity
        of the CLOSE message can be verified the same way data messages
        are verified, that is, the flow label needs to match and the
        locators be in the locator sets.)  This processing applies
        whether or not the state is CLOSING in order to handle CLOSE
        messages from both ends crossing in flight.

        Once the context state has been discarded any need to send data
        packets will trigger establishing a new context, starting with
        sending an INIT.

    3.  A CLOSE message which is received when there is no context state
        can not be verified but will result in a CLOSEACK response to
        speed up the peer discarding the state in the presence of packet
        loss.

    4.  The CLOSE message is retransmitted until either a CLOSEACK
        message is received, or it has been retransmitted for a total of
        X minutes.  When either occurs the context state is discarded.

    5.  When a host receives a CLOSEACK message it verifies that it is
        in CLOSING state and that the CLOSEACK was in response to the
        CLOSE (using e.g., a nonce in the CLOSE message).

        It is possible to use stronger verification of the CLOSEACK
        based on secrets tied to the context state, but only for the
        first CLOSE message since the state is discarded on its



draft-nordmark-multi6-noid-02.txt                              [Page 53]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


        reception.  Thus if the CLOSEACK response to the first CLOSE is
        lost, the host would need to wait for the full X minutes until
        discarding its state.

   Due to packet loss the two sides can have different views of when the
   last packet might have been sent, but because no received packets in
   X minutes causes a state transition, this difference can not be
   larger than X.  Since the CLOSE messages are retransmitted for X
   minutes (during which the peer can not possibly receive any data
   packets) the peer will transition to CLOSING and stop sending data
   packets before the host will discard its state.  Example 2 shows a
   case when this happens.

   Example 1: working communication in both directions

   Time T: A sends a packet to B.  While A doesn't know it yet, this is
   the last packet A will send using the context.  B continues to send
   packets to A.

   Time T+X: B has not received any packets from A for X seconds.  B
   marks the context as CLOSING, that is, it will not use the state to
   transmit any more.  B sends a CLOSE message to A.

   Time T+X: A receives a CLOSE message from A.  Discards the context
   state and responds with a CLOSEACK message.

   Time T+X: B receives the CLOSEACK message and discards the context
   state.


   Example 2: Unidirectional failure; A->B packets are all dropped.

   Time T: A sends a packet to B.  While A doesn't know it, this is the
   last packet B will receive from A.

   Time T+1 etc: A sends a packet to B which is lost.

   Time T+X: B has not received any packets from A for X seconds.  B
   marks the context as CLOSING, that is, it will not use the state to
   transmit any more.  B sends a CLOSE message to A.

   Time T+X: A receives a CLOSE message from A.  Discards the context
   state and responds with a CLOSEACK message.  The CLOSEACK message is
   lost.

   Time T+X+1 etc: B retransmits the CLOSE message.

   Time T+X+1 etc: A receives the CLOSE message, has no context state,



draft-nordmark-multi6-noid-02.txt                              [Page 54]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   and responds with a CLOSEACK message.  The CLOSEACK message is lost.

   Time T+2X: B stops retransmitting the CLOSE message and discards the
   session state.


   Example 3: Bidirectional failure; all packets are dropped.

   Time T1: A sends a packet to B.  While A doesn't know it, this is the
   last packet B will receive from A.

   Time T2: B sends a packet to A.  While B doesn't know it, this is the
   last packet A will receive from B.

   Time T1+1 etc: A sends a packet to B which is lost.  Time T2+1 etc: B
   sends a packet to A which is lost.

   Time T1+X: B has not received any packets from A for X seconds.  B
   marks the association as CLOSING, that is, it will not use the state
   to transmit any more.  B sends a CLOSE message to A.  The CLOSE
   message is lost.

   Time T2+X: A has not received any packets from B for X seconds.  A
   marks the association as CLOSING, that is, it will not use the state
   to transmit any more.  A sends a CLOSE message to B.  The CLOSE
   message is lost.

   Time T1+X+1 etc: B retransmits the CLOSE message, which is lost.
   Time T2+X+1 etc: A retransmits the CLOSE message, which is lost.

   Time T1+2X: B stops retransmitting the CLOSE message and discards the
   session state.

   Time T2+2X: A stops retransmitting the CLOSE message and discards the
   session state.

   Since the difference between T1 and T2 can't be more than X, we know
   that the session state can not be discarded before the other end has
   transitioned to CLOSING.

   The above examples generalize to arbitrary packet loss; in no case
   will a data packet be received when there is no association state.
   Hence data packet that are received and have no matching session
   state can be silently dropped; no need to send an Unknown Context
   error or an INIT message.

   Intuitively it seems like network delays can be handled to make the
   period for the retransmission of the CLOSE message be X+MSL (Maximum



draft-nordmark-multi6-noid-02.txt                              [Page 55]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   segment lifetime) instead of X, but this needs to be verified.

   The introduction of the close mechanism adds some considerations to
   the state machine.  For instance, if an INIT arrives when in CLOSING
   state, the INIT would need to create a separate, new context, which
   has different flow labels at both ends.  That way the context in
   CLOSING state is allowed to expire based on timeout or receiving a
   Close Acknowledgement message, in parallel with the new context being
   created.

   This means that there might be more than one context for the same AID
   pair.  This has the following implications:

    o When handling packets passed down from the ULP, the M6 layer
      should not match any contexts in CLOSING state, but instead behave
      as if there was no context even when there is a context in CLOSING
      state. [TBD: It might be useful to copy certain information from
      the context in CLOSING state to the new context.]

    o The context establishment packets (INIT, CC, CCR, and CONF) should
      also ignore any context in CLOSING state.

    o Data packets received from the wire identify which context to use
      with the flow label field.

    o M6 control packets that are sent after the context is established
      needs to be able to indicate which of possibly multiple contexts
      are intended.  As a result, the Update Request, Update
      Acknowledgement, Close and Close Acknowledgement messages carry
      both flow labels which are used to identify the state.

AUTHORS' ADDRESSES

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

     phone: +1 650 786 2921
     fax:   +1 650 786 5896
     email: erik.nordmark@sun.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in



draft-nordmark-multi6-noid-02.txt                              [Page 56]

INTERNET-DRAFT          Multihoming without IDs             July 7, 2004


   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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









draft-nordmark-multi6-noid-02.txt                              [Page 57]


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