INTERNET-DRAFT                           Erik Nordmark, Sun Microsystems
Nov 14, 2001

                    MIPv6: from hindsight to foresight?


   Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

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

   This Internet Draft expires May 14, 2002.


   This document captures the authors personal opinions and is intended
   to serve as input to the discussion in the Mobile IP Working Group.
   It proposes several, in may cases completely independent, things
   which might be deemed radical changes to Mobile IPv6 based on
   watching Mobile IPv6 evolve over the last 5 years.

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 1]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001


      1.  INTRODUCTION.............................................    2
         1.1.  Goals and Requirements..............................    3
         1.2.  Proposed Changes....................................    4

      2.  GENERIC END-TO-END PIGGYBACKING..........................    5
         2.1.  Piggybacking Packet Format..........................    5
         2.2.  Sending Payload Headers.............................    6
         2.3.  Processing Received Payload Headers.................    6

      3.  NO MORE DESTINATION OPTIONS IN MOBILE IPv6...............    7


         5.1.  Three Address Tunneling Packet Format...............    7
         5.2.  Sending Rules.......................................    8
         5.3.  Receiving Rules.....................................    9
         5.4.  When to Accept Tunneled Packets.....................    9

      6.  EXPLICIT MOVEMENT DETECTION..............................   11
         6.1.  Location Indication Option Format...................   11

      7.  SECURITY CONSIDERATIONS..................................   12

      8.  ACKNOWLEDGEMENTS.........................................   13

      REFERENCES...................................................   13

      AUTHORS' ADDRESSES...........................................   14


   The Mobile IPv6 specification has evolved incrementally over at least
   5 years.  During that time several things have changed that could be
   used to provide additional benefits for mobile IPv6.

   An example is IP tunneling which was first specified for Mobile IPv4.
   Since then the understanding of IP tunneling has increased
   significantly over the years due to being used for both IPsec and
   IPv6 transition.  This has lead to a greater understanding of e.g.,
   the security issues in decapsulating packets.

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 2]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

   This document proposes a set of largely independent changes to Mobile
   IPv6 that are on the author's "wish list".  Many of the changes can
   be viewed as just using a different packet format to encode the same
   information thus the impact on implementations might not be that
   large as one would otherwise think.  But it is the author's opinion
   that these changes make the protocol fit better with other IP
   protocol hence easier to understand.  The hope is that this will
   reduce the probability of implementation problems relating to
   robustness, security, etc.

   If the working group thinks these simplifications are worth-while it
   would make sense to apply them before Mobile IPv6 becomes a proposed
   standard.  Delaying this type of "cleanup" until after there is a
   mobile IPv6 standard is not likely to be beneficial since then one
   would have to be concerned with compatibility between the old and the
   new scheme, carry around the code for the old scheme, etc.  Thus it
   makes sense for the WG to look carefully at these suggestions and
   make a conscious decision whether to reject them or accept them, and
   not try to postpone this discussion until later.

   These ideas are not mine alone - most of them have been suggested by
   others on the Mobile IPv6 or IPNG mailing lists over the years but
   have not resulted in much of discussion.

   With one notable exception the suggested changes do not change the
   set of features available in Mobile IPv6.  The exception is the
   suggestion to remove the "update of previous default router" which,
   in the author's opinion, is a pre-mature optimization.  Given the
   "securing binding updates in the absence of a global PKI" discussion
   that the working group is having it less clear than ever whether the
   use of the previous default router as a temporary Home Agent for the
   previous Care of Address will reduce the packet loss due to handoffs
   - securely updating the previous default router is likely to take at
   least one round-trip time and which point the number of packets in
   transit between the CNs and MN's old CoA is likely to be very small.
   In any case, there are separate efforts to make handoffs smoother.

1.1.  Goals and Requirements

   The goals for the proposed changes are:

    o Simplify things to the extend possible without loosing

    o Use existing protocol mechanisms such as tunneling.  In general
      make Mobile IPv6 less different than other existing protocol

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 3]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

    o Allow IPsec to be used to authenticate control traffic in the
      cases when a trust relationship exists e.g. between the MN and its

    o Address the concerns about the use of routing headers and home
      address options expressed in [RH-HA].

1.2.  Proposed Changes

   Replace the binding update specific piggybacking in [MIPv6] with
   generic end-to-end piggybacking i.e. the ability to send two IP
   packet payloads in a single IP packet.

   Make the Mobile IPv6 control packets (Binding Request, Update,
   Acknowledgement, etc) use either a UDP port, new ICMP types, or a new
   payload type.

   Replace the use of the Routing Header in Mobile IPv6 with IPinIP
   tunneling.  Specify a new tunneling header which omits the source
   address since, in this case, the conceptual outer source address and
   inner source address are identical.  The resulting header adds 24
   bytes to the packet which is the same as a the size of the routing
   header and it allows sites and hosts to have separate security policy
   for processing these headers than processing routing headers as [RH-
   HA] suggests they need.

   Replace the use of the Home Address option conceptually with
   tunneling.  Avoid an increase in packet size by specifying a new
   tunneling header which omits the destination address, since in this
   case the inner and outer destination addresses would be identical.

   For mobile to mobile communication, where both a routing header and a
   home address option is used today this conceptual use of tunneling
   just becomes regular IPinIP tunneling since in that case all four
   IPv6 need to be carried; two care of addresses and two home addresses
   in each packet.

   There is also one idea that could be added to Mobile IPv6 at a later
   stage, which is to make the movement detection more explicit.  The
   idea is to configure the routers on each link to advertise a single
   global IPv6 address as the "identity" of the link in each Router
   Advertisement.  This can be done by defining a new Neighbor Discovery
   option.  Thus a Mobile Node when it receives a Router Advertisement
   can immediately tell whether it has moved - the global identity will
   be different for each link.

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 4]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001


   This is based on the work in [PAYLOAD].

   The idea is to define a new extension header that is capable of
   carrying multiple IP packet payloads between a pair of IP addresses,
   that is defined such that IPsec can be used independently on the
   different payloads.  Thus it would be possible to have a mobile IPv6
   control packet protected by ESP and a TCP SYN packet without any
   IPsec protection in the same IP packet.

2.1.  Piggybacking Packet Format

   Extracted from [PAYLOAD].

        0              7 8            15 16                           31
        |               |               |                               |
        |    Nxt Hdr    |  Int Nxt Hdr  |            Length             |
        |               |               |                               |
        |                                                               |
        |    Data  (Length octets) ...                                  |
        |                                                               |
        |                          /------------------------------------|
        |                         /       Trailing Padding              |

   IP Fields:

      Nxt Hdr
                     The payload type for the header that follows the
                     trailing padding.

      Int Nxt Hdr
                     The payload type for the Data field.

                     The length of the Data field in octets.

                     Some payload of type "Int Nxt Hdr".

      Trailing Padding
                     If the length of the whole extension header is not

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 5]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

                     a multiple of 8 octets this field will be present
                     so that the total length of the extension header
                     becomes a multiple of 8 octets.

   Note that [PAYLOAD] defines the above format as the `General Payload
   Header'' (GPH) and also defines the ``Aligned Payload Header'' with
   32 bits of reserved field between the length field and the data
   field.  The reason for this is to provide different alignment with
   respect to the beginning of the Data field.

2.2.  Sending Payload Headers

   When a sender sees a benefit of using piggybacking it can include
   multiple payloads in the packet independent whether the payloads use
   IPsec or not.

   However, some firewalls might drop any packet containing the payload
   header and other firewalls will drop such a packet if any of the
   contained payloads violate the security policy.  Hence this form of
   piggybacking SHOULD NOT be used when retransmitting packets since
   that could result in repeated retransmissions all being dropped by a
   firewall when individual packets would make it through.

   The payload header, when sent, SHOULD be placed after any
   fragmentation header but before any IPsec headers.

2.3.  Processing Received Payload Headers

   Conceptually the processing of a payload header can be described as
   using the payload header to create two separate IP packets and
   processing those packets independently.

   This can be described as forming two IPv6 headers (and other headers
   like HopByHop options that precede the payload header) and appending
   the payload from the Data field in the payload header to one of the
   headers and the appending rest of the packet to the other header.
   Finally adjusting the IPv6 payload length for the two headers.

   Note that in general there can be more than one payload header per
   packet in which case this simple way of describing the processing
   needs to be recursive.

   Once the two packets have been generated they are processed as they
   had just been received from the link-layer i.e., any IPsec processing
   takes place on the individual packets.

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 6]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001


   The use of Destination options for Binding Update and other MIPv6
   control messages allowed the use of Binding Update specific
   piggybacking.  With the introduction of the generic end-to-end
   piggybacking above there is no longer such a need.  Thus it makes
   sense to make the Mobile IPv6 control messages use a protocol that
   allows them both to be treated separately by IPsec [IPSEC-SA]
   implementations, and make it easier to implement this processing
   separately from the main "ip_input" code path.

   This can be accomplished by using UDP or by using one or more new
   ICMP types (assuming IPsec implementations support selecting on ICMP
   types; it is not required according to [IPSEC-SA]), or by defining a
   new payload/protocol type for this purpose.


   Currently when two mobile nodes are communicating using route
   optimization the packet ends up containing a destination options
   extension header with a home address option, which gets padded out to
   24 bytes, and a routing header which is also 24 bytes.  The
   suggestion to conceptually use tunneling instead means that for this
   mobile to mobile communication an extra IPv6 header is all that is
   needed.  In addition to the conceptual simplifications of using
   tunneling there is an added bonus in this case; saving of 8 bytes per


   When IPinIP tunneling is used [TUNNEL] the packet ends up containing
   four IP addresses.  However, when sending packets between a non-
   mobile CN and a MN there is only need for three IP addresses; for
   packets from the CN to the MN there needs to be a source address, the
   CoA of the MN, and the Home Address (HoA) of the MN.  Similarly, from
   packets from the MN to the CN the same set of addresses are needed
   but the source and destination sense of them is inverted.

5.1.  Three Address Tunneling Packet Format

   The message format is the same for the two cases.  Which one is used
   is identified by the Next Header value in the previous extension
   header.  The two values are:

      IPinIPnoSRC     TBD [Assigned by IANA]

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 7]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

      IPinIPnoDST     TBD [Assigned by IANA]

         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
        |  Next Header  |   Length = 3  |          Reserved             |
        |                            Reserved                           |
        |                                                               |
        +                                                               +
        |                                                               |
        +                              Address                          +
        |                                                               |
        +                                                               +
        |                                                               |

   TBD: Does it make sense to include transport class and flowid in the
   reserved fields above?

5.2.  Sending Rules

   A possible sending rule is that based on the assumption that the
   sender somehow knows that the receiver supports both [TUNNEL] and the
   above two new payload types.  For Mobile IPv6 once could just require
   that all nodes participating in Mobile IP (i.e. the same set of nodes
   that support the Home Address Option and Route Optimization today)
   also support encapsulation including the two new extension headers.
   Presumably Mobile IPv6 needs a mechanism, such as an ICMP error, to
   detect when a receiver does not support the home address option.  A
   similar mechanism could be used to detect that a receiver doesn't
   support these headers.  When the headers are not supported then in
   the case of sending packets from a MN, the only choice would be to
   reverse tunnel the packet through the HA.  When sending packets to a
   MN after establishing a Binding Cache Entry it would be a more or
   less fatal error if the MN did not support the IPinIPnoSRC payload

   When sending a packet through a conceptual tunnel as described in
   [TUNNEL], and the sender has reason to believe that the receiver, it
   would compare the inner source with the inner destination as well as
   the outer source and outer destination addresses.  If the source
   addresses match it would use a IPinIPnoSRC extension header with the
   "Address" field in the extension header being the inner destination
   address (the Home Address when sending to a MN).  If the destination

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 8]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

   addresses match the sender would use a IPinIPnoDST extension header
   with the "Address" field being the inner source address (the Home
   Address when sending a packet from a MN).  If neither addresses match
   then a regular [TUNNEL] packet would be sent.

5.3.  Receiving Rules

   A conceptual way of describing the receive side behavior is to expand
   the above extension headers to a regular IPinIP header and then
   process that IPinIP header by the usual rules.  Such a scheme allows
   the sending implementation to use IPinIP in all cases and the use of
   IPinIPnoSRC and IPinIPnoDST are optimizations that the sender can use
   to save bytes on the wire.

   For IPinIPnoSRC this step involves replacing the IPinIPnoSRC header
   with an IPinIP header and copying the source address from the outer
   IP header into that new header while copying the Address field in the
   IPinIPnoSRC to the destination field in the new header and updating
   the payload length etc.

   The same step for IPinIPnoDST just copies the outer IP destination
   into the new inner header and takes the new inner header source from
   the above Address field.

5.4.  When to Accept Tunneled Packets

   When Mobile IPv6 is using tunneling a conservative approach
   security-wise would be to only accept the tunneled packets, unless
   the node has other policies that are more permissive, based on the
   content of the Binding Cache and Binding Update List [MIPv6].

   Packets where the inner and outer source match and the inner and
   outer destinations differ, whether or not IPinIPnoSRC or IPinIP was
   used to deliver the packet, SHOULD only be accepted if all of these
   are true:

    o The <outer destination, inner destination> is the CoA and HoA for
      an entry that is in the Binding Update list.  Thus only nodes that
      have been sent an unexpired binding update should be tunneling
      such entries towards the node.

    o The outer destination and inner destination belong to the same
      zone [SCOPED-ARCH].  The reasons for this is in [RH-HA].

    o If the receiver is a security gateway i.e. treats some network
      interfaces as being on the "inside" and others as the "outside"

draft-nordmark-mobileip-mipv6-hindsight-00.txt                  [Page 9]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

      (or perhaps has more that two such "domains") it SHOULD also
      verify that the inner and outer destinations are in the same such

   Packets where the inner and outer destinations match and the inner
   and outer sources differ, whether or not IPinIPnoDST or IPinIP was
   used to deliver the packet, SHOULD only be accepted if all of these
   are true:

    o The <outer source, inner source> matches a <CoA, HoA> in the
      Binding Cache.  This restriction says that only nodes that have
      managed to securely create a Binding Cache entry in the
      correspondent can send packets directly to it using this form of
      tunneling.  If this is not the case an MN needs to tunnel packets
      through the home agent so the packets will delivered to the CN
      without any tunneling header.

   Packets where both the inner and outer source and destinations are
   different SHOULD only be accepted if all of these are true:

    o The above rules in the case of matching destinations are

    o The above rules in the case of matching source addresses are

   When a packet is dropped because it does not satisfy the above
   requirements an ICMP error (type and code TBD) should be sent back to
   the outer source address.  This message is then used by the sender to
   detect e.g. when a CN has garbage collected a Binding Cache entry.
   [TBD: This makes packet delivery depend on ICMP errors not being
   discarded by firewalls! If this is an issue an option is to not allow
   CNs to garbage collect binding cache entries until the lifetime

   Packets where both the inner and outer source and destinations are
   the same SHOULD be dropped.

draft-nordmark-mobileip-mipv6-hindsight-00.txt                 [Page 10]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001


   Note that unlike the other ideas presented in this document this
   particular one can presumably be done at a later point in time.  But
   it would simplify the Mobile Nodes if they could use this movement
   detection scheme instead of relying on a combination of the IPv6
   addresses of the individual routers and the on-link prefixes that the
   routers advertise as specified in [MIPv6].

6.1.  Location Indication Option Format

   This specification defines a new Location Indication option for
   Neighbor Discovery [ND].  This option is used in Router Advertisement
   messages to help mobile nodes quickly detect when they appear in a
   different link without resorting to ``guessing'' based on the
   advertised prefixes in the router advertisements and Neighbor
   Unreachability Detection specified in [MIPv6].

         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      |    Length     | Location Type   |  Reserved   |
        |                           Reserved                            |
        |                                                               |
        +                                                               +
        |                                                               |
        +                     Identifying Address                       +
        |                                                               |
        +                                                               +
        |                                                               |


      Type           8-bit identifier of the type of option.  Value TBD.

      Length         8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets.  Always 5 for this option.

      Location Type
                     8-bit field specifying what level type of location
                     (granularity etc) that is captured in the

draft-nordmark-mobileip-mipv6-hindsight-00.txt                 [Page 11]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

                     Identifying Address.  The following types are
                     defined in this document:

                        Link Location                                1
                        AAA domain indication                        2

      Identifying Address
                     128-bit IPv6 address.  An IPv6 address which
                     together with the location type uniquely identifies
                     the location.

   A mobile node would track the last received Identifying Address of
   type "link location".  When it receives a Location Indication of that
   type with a different Identifying Address it should as quickly as
   possible form a new care of address.  If the Router Advertisement
   contains Prefix options with the A-bit set it can immediately so
   this.  Otherwise it needs to send one or more Router Solicitations in
   order to receive one or more such Prefix options.  Once the mobile
   node has a new care of address it can discard the old care of address
   and the old default router list (the default routers which have not
   been heard from after it received the new link location) and proceed
   to send binding updates to the home agent and correspondents in the
   Binding Update list as specified in [MIPv6].

   Routers that are configured to send Location Indication options
   should verify, in addition to what is specified in the Section on
   Router Advertisement Consistency in [ND], that other routers on the
   same link use the same Identifying Address for the same Location
   Type.  If these is a mismatch this should be reported to system


   The generic end-to-end piggybacking allows arbitrary IP payloads to
   be included in the same packet.  Thus firewalls that care about IP
   payloads need to inspect all of them.  If the firewall is not capable
   of doing this it is likely to drop the whole packet, and if the
   firewall has the capability to inspect the multiple payloads it is
   likely to drop the whole packet if any payload needs to be rejected.
   Thus any use of this multiple payload header needs to be able to have
   retransmission policies that avoid repeatedly trying to use the
   header for retransmitted packets.

   As pointed out in [RH-HA] the issues of processing Routing Headers as
   used by Mobile IP and Home Address Options seem rather similar to the

draft-nordmark-mobileip-mipv6-hindsight-00.txt                 [Page 12]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

   concerns that exist for decapsulating and optionally forwarded
   packets when using tunneling.

   Using the framework that exists for tunneling to express this makes
   Mobile IPv6 be able to leverage security mechanisms.  However, the
   specific policies for when to decapsulate packets are quite different
   for the Mobile IP use of tunneling as outlined in Section 5.4.

   The suggestion do to explicit movement detection allows any node on
   the link, in the absence of authenticated and authorized Router
   Advertisements, to send Location Indication options which would make
   a Mobile Node think it has moved and attempt to form new Care of
   Addresses.  However, similar attacks can be launched against the
   movement detection mechanisms in [MIPv6].  None of these attacks are
   possible for off-link senders.


   This document is mostly a collection of ideas that others have
   suggested that I've tried to capture or this virtual paper.

   Robert Elz wrote [PAYLOAD] many years back and Francis Dupont found a
   copy of the old draft.

   Bill Sommerfeld suggested using encapsulation instead of Routing
   Headers and Home Address options on the mobileip mailing list.

   TBD: List more names.


  [RH-HA] P. Savola, "Security of IPv6 Routing Header and Home Address
          Options", draft-savola-ipv6-rh-ha-security-00.txt

  [TUNNEL] A. Conta, and S. Deering, "Generic Packet Tunneling in IPv6
          Specification", RFC 2473, December 1998.

  [PAYLOAD] R. Elz, "The IPv6 Payload Header", Expired Internet Draft,
          draft-kre-ipv6-payload-01.txt, October 1995.

  [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol
          (ICMPv6) for the Internet Protocol Version 6 (IPv6)
          Specification", draft-ietf-ipngwg-icmp-v3-01.txt.

  [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6

draft-nordmark-mobileip-mipv6-hindsight-00.txt                 [Page 13]

INTERNET-DRAFT              MIPv6 Hindsights                Nov 14, 2001

          (IPv6) Specification", RFC 2460, December 1998.

  [MIPv6] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft-

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

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

  [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
          Requirement Levels", RFC 2119, March 1997.

  [INGRESS] P. Ferguson, D. Senie, "Network Ingress Filtering:
          Defeating Denial of Service Attacks which employ IP Source
          Address Spoofing.", RFC 2827, May 2000.


     Erik Nordmark
     Sun Microsystems Laboratories, Europe
     29 Chemin du Vieux Chene
     38240 Meylan, France

     phone: +33 (0)4 76 18 88 03
     fax:   +33 (0)4 76 18 88 88

draft-nordmark-mobileip-mipv6-hindsight-00.txt                 [Page 14]